[1] RFC 822 インターネットメール のメッセージ形式 を規定するインターネット標準 だった
RFC です。
[2] RFC 822 は出版から十数年を経て改訂され RFC 2822 となりました。その後更に改訂されて
RFC 5322 となっています。
[21] メッセージ形式 に固有の名称がないため、改訂により廃止 された現在もあえて
RFC 822 形式と呼び続けていることがあります。
メッセージ形式 [17] RFC 822 はインターネット の電子メール で使われるメッセージ形式 を規定しています。
この形式は MIME では message/rfc822 message/rfc822
[18] SMTP を使う標準のインターネットメール の他、 USENET (UUCP や NNTP )
や MMS など他のプロトコル でも使われています。
message/rfc822
[19] ヘッダー部 、空行 、本体 で構成され、ヘッダー は名前、:、
本体で構成されるといった本メッセージ形式 は、 HTTP をはじめとする様々なアプリケーションプロトコル の設計に影響を与えました。
名前としての「RFC 822」 [7] RFC 822 が規定するメッセージ形式 は、明確な呼称がありません。
(RFC 2822 は Internet Message Format と呼んでいるようですが...)
RFC 822 により規定されているため、しばしば「RFC 822 (の形式)」や
「822 」などと呼ばれます。 MIME型 も message/rfc822
[8] RFC 822 が廃止 された後も、(他に呼びようがないので) RFC 822
と引き続き呼ばれる場合があります。しかし廃止 された RFC
の番号で呼び続けるのもおかしな話なので、 RFC 2822 や RFC 5322
の形式と呼ぶこともあります (が知名度が低いのが難点です)。
STD 11 [4] RFC 822 はインターネット標準 であり、 STD 11 という番号が割り振られています。
[5] RFC 822 は RFC 2822 は廃止 されましたが、インターネット標準 であった
RFC 822 に対し、全面改訂である RFC 2822 は提案標準 でしかないため、
STD 11 は引き続き RFC 822 を表すという矛盾した状況になっています。
RFC 5322 もインターネット標準 ではありません。
[6] 長い年月を経て実情に則さなくなり改訂された旧版である RFC 822
が「インターネット標準 」と呼ばれ、より実質的な標準に近いはずの RFC 2822
が手続き上の理由で「提案」段階にとどまっているのはおかしな話ですが、
IETF ではそういうものだと扱われているようです。RFC 1123 [14] RFC 822 は RFC 1123 により一部が更新 され、
年号 の扱い (2000年問題 対策) などが改められています。
[15] しかし、これはしばしば (気付かれずに) 無視されていました。
[16] 他の RFC が古い RFC の一部を改訂する場合にはよくあることです。
RFC 2822 による全面改訂までこの状況が続きました。[3] ほとんどの実装は、 RFC 1123 に従っていました。ABNF [9] RFC 822 が構文の定義のために使っていた書式である ABNF
(RFC 822のABNF ) は、電子メール 関連仕様をはじめ多くの IETF
の仕様書で流用されました。
[10] これは後に独立した RFC になっています。 RFC 822 の改訂である
RFC 2822 も、この新しい ABNF の RFC を採用する形になっています。
ABNF
日時形式 [11] RFC 822の日時形式 は、電子メール をはじめ多くの仕様で採用され、
一時はインターネット のアプリケーション層 における日時形式 の事実上の標準 と考えられていました。
[12] その後 RFC 3339 が ISO 8601 ベースの新しい日時形式 を規定したことにより、
それ以後の仕様がそちらを採用するようになりました。もちろんそれ以前から
RFC 822の日時形式 を採用していた仕様は、現在も引き続き RFC 822の日時形式 を使っています。
メモ 電子メール プロトコル
[22]
mparse Files http://users.erols.com/blilly/mparse/index.html
[20] PEP 0345 -- Metadata for Python Software Packages 1.2 | Python.org
(2015-08-08 00:51:38 +09:00 版)
https://www.python.org/dev/peps/pep-0345/ To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe ("|") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [ 2] .