2019年1月26日土曜日

ふわっとした情報から一次ソースまでたどり着く方法(RFC編)

0. 要旨

「メールアドレスのドットの連続はRFC違反」みたいな ふわっとした情報があって興味をもったとき、 技術屋なら 「どのRFCのどのセクションにどのように記述されているか」 みたいな一次ソースを当然確認したくなるでしょう?
今回、メールアドレスのルールが気になって調べたのでここに記録しておく。

1. 一次ソースまでの道のり

1.1. Wikipedia日本語版「メールアドレス」

ざっと説明を読む。ふむふむ。 RFC 5321とRFC 5322への参照がある。 取り合えずリンクを開く。
(今回は、Wikipedia日本語版に参照先まで書いてあってラッキーなパターン。 日本語版に参照がなくても英語版を眺めると参照先が見つかることもあるし、 さらにインターネットをさすらう場合もある。)

1.2. RFCを眺める

タイトルは
RFC 5321:Simple Mail Transfer Protocol
RFC 5322:Internet Message Format
で、どちらもボリュームがある。
RFC 5321から読むことにする。

1.3. RFC 5321を眺める

まず左上にObsoleted byがないことを確認する。
(もしObsoleteになっているなら、 Obsoleted by: XXXXのXXXXを読むべきだから。)
長いのでさらさらスクロールしてみる。
中程でバッカス・ナウア記法(BNF)的な 表記を見つけて手を止める。その節は 「4.1.2.  Command Argument Syntax」。
読んでみるが、いまいち解決しない。
@の左側はLocal-partと呼び、それはDot-stringであって、、、 と書いてあるが、atext以降が解決していない! そしてこの文書にはatextはこの1個しかない!

1.4. RFC 5322を眺める

気を取り直して、RFC 5322を開き「atext」を検索する。 3個めのatextでBNF的な表記に出くわす。その節は「3.2.3.  Atom」。 atextが定義されている。なんだatextは普通の文字 (アルファベットと数字といくつかの記号)のことか。

1.5. RFC 5321に戻る

ここで、RFC 5321 4.1.2に戻る。
----------------------------------------------
(前略)
   Dot-string     = Atom *("."  Atom)
   Atom           = 1*atext
(後略)
----------------------------------------------
たしかに、Local-partは確かにドットは連続しないわ、と納得する。

<読み方>
読み方は人によるところが大きい。
私はボトムアップが一番理解しやすいので、 最下層(定義に近いもの)から順番に組み立てるように理解する。
「Atomは任意個の普通の文字。
Dot-stringは先頭にAtomあって、その後に任意個の{.(ドット) とAtomの連結}が続く。
ということは.(ドット)は連続で現れないし、先頭にも最後尾(@の直前)にも現れない!」

1.5. RFC 5321とRFC 5322

だけど、RFC 5321の途中からRFC 5322の定義を読むのでよいのか、 と我に返る。
RFC 5321で5322を検索すると 「1.2.  History and Context for This Document」に 「RFC 5322はcompanion documentだよ」と書いてあるので、 よいことにする。

2. おまけ

2.1. ITEFのRFCのページ

ITEFのRFCのページは便利。
https://tools.ietf.org/html/rfc5321
Obsoleteになっているもの、updateがあるものは 最上部で分かるし、 他のRFCへの参照はハイパーテキストリンクになっている。

2.2. バッカス・ナウア記法(Backus-Naur form)

BNFは学部3年のときに情報学科の講義で勉強して、 なるほどすごい、と思った。
でも、いつもギリシャのお酒の好きな神様を思い浮かべてしまう。 (綴りはちょっと違う)

2.3. Request For Comment

RFCに「違反」という言葉は似合わないと思っている。
「法令」ではない、ただの「Standard」なのだから、 「準拠していない」くらいが適切と思う。

以上