4. Obsolete Syntax (廃止された構文)
本仕様の以前のバージョンでは、このバージョンで許可されているものとは異なる(通常はより寛容な)構文が許可されていました。また、明示的に文書化されたことのない構文要素がメッセージで使用されてきました。これらの構文形式の一部は、セクション 3 の文法に従って生成してはなりません (MUST NOT) が、準拠する受信者によって受け入れられ、解析されなければなりません (MUST)。このセクションでは、これらの構文要素の多くを文書化します。セクション 3 の文法に、このセクションで提示される定義を追加すると、メッセージの解釈に使用する文法が得られます。
注意: このセクションでは、すべての実装が合理的に解釈しなければならない (MUST) 構文形式を特定します。ただし、このセクションで示される追加の構文にも適合しないインターネットメッセージが確実に存在します。特定の形式がこのドキュメントのどのセクションにも記載されていないという事実は、コンピュータプログラムがクラッシュしたり、実装が不正な形式のデータを取り返しのつかない形で失ったりすることの正当化にはなりません。メッセージを堅牢に処理するのは実装の責任です。
廃止された構文と現在の構文の主な違い:
-
空白の使用: 構造化ヘッダーフィールド本体内(つまり、任意の構造化ヘッダーフィールドのコロンと CRLF の間)では、空白文字(折り返し空白を含む)とコメントを任意の構文トークン間に自由に挿入できます。これにより、一部の実装では解析が困難であることが判明した多くの複雑な形式が可能になります。
-
折り返し空白規則: コメントと折り返し空白の空白のみで構成される行に関するセクション 3.2.2 の規則は適用されません。以下のセクション 4.2 の折り返し空白の説明を参照してください。
-
特殊文字: 許可されなくなった特定の文字が許可されていました。NUL 文字(ASCII 値 0)はかつて許可されていましたが、互換性の理由から許可されなくなりました。同様に、CR、LF、SP、HTAB 以外の US-ASCII 制御文字(ASCII 値 1 ~ 8、11、12、14 ~ 31、127)がヘッダーフィールド本体に出現することが許可されていました。CR と LF は、CRLF 以外としてメッセージに出現することが許可されており、この使用法もここに示されています。
主要概念
廃止された構文の目的
メッセージ生成 メッセージ解析
↓ ↓
セクション 3 の構文 セクション 3 + セクション 4
(厳格なルール) (寛容なルール)
↓ ↓
廃止された形式を 廃止された形式を
生成してはならない 受け入れなければならない
実装要件
| 役割 | 廃止された構文に対する要件 |
|---|---|
| メッセージ生成器 | 廃止された構文を生成してはならない (MUST NOT) |
| メッセージ解析器 | 廃止された構文を受け入れ、解析しなければならない (MUST) |
| すべての実装 | 不正な形式のメッセージを堅牢に処理しなければならない (MUST) |
4.1. Miscellaneous Obsolete Tokens (その他の廃止されたトークン)
これらの構文要素は、廃止された構文またはメイン構文の他の場所で使用されます。裸の CR、裸の LF、NUL が obs-qp、obs-body、obs-unstruct に追加されています。US-ASCII 制御文字が obs-qp、obs-unstruct、obs-ctext、obs-qtext に追加されています。ピリオド文字が obs-phrase に追加されています。obs-phrase-list は、"null" 要素を含む可能性のあるフレーズの(空の可能性がある)カンマ区切りリストを提供します。つまり、そのようなリストでは、2 つ以上のカンマの間に何もない、またはリストの最初または最後にカンマがある可能性があります。
obs-NO-WS-CTL = %d1-8 / ; キャリッジリターン、
%d11 / ; ラインフィード、および
%d12 / ; 空白文字を含まない
%d14-31 / ; US-ASCII 制御文字
%d127
obs-ctext = obs-NO-WS-CTL
obs-qtext = obs-NO-WS-CTL
obs-utext = %d0 / obs-NO-WS-CTL / VCHAR
obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR)
obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
obs-phrase = word *(word / "." / CFWS)
obs-phrase-list = [phrase / CFWS] *("," [phrase / CFWS])
注意: obs-phrase の「ピリオド」(または「終止符」)文字(".")は、本仕様または他の仕様の以前のバージョンで許可されていた形式ではありません。ピリオド(または specials の他の文字)は、phrase と addr-spec の部分を区別する解析の困難を導入するため、phrase では許可されていませんでした(セクション 4.4 を参照)。多くのメッセージのアドレスの display-name 部分、特に名前のイニシャルで現在使用されているため、ここに記載されており、適切に解釈する必要があります。
裸の CR と裸の LF は、2 つの異なる意味でメッセージに出現します:
- 行区切り文字として: 多くの場合、裸の CR または裸の LF が、行の区切りを示すために CRLF の代わりに誤って使用されます
- 制御文字として: 他の場合、裸の CR と裸の LF は、従来の ASCII の意味を持つ US-ASCII 制御文字として単に使用されます
4.2. Obsolete Folding White Space (廃止された折り返し空白)
廃止された構文では、obs-FWS 規則が許可される場所に任意の量の折り返し空白を挿入できます (MAY)。これにより、1 行に 2 つの連続した「折り返し」が存在する可能性が生じ、したがって、展開されるべき行に可視コンテンツがない可能性があります。
obs-FWS = 1*WSP *(CRLF 1*WSP)
例:
廃止された折り返し(許可されていますが推奨されません):
Subject: This
is valid
(中間行には空白のみが含まれます)
現在の標準(セクション 3):
空白のみで構成される行は禁止されています
4.3. Obsolete Date and Time (廃止された日付と時刻)
廃止された日付形式の構文では、date フィールドで 2 桁の年を使用でき、本仕様の以前のバージョンで使用されていたアルファベットのタイムゾーン指定のリストを使用できます。また、多くのトークン間でコメントと折り返し空白を使用できます。
obs-day-of-week = [CFWS] day-name [CFWS]
obs-day = [CFWS] 1*2DIGIT [CFWS]
obs-year = [CFWS] 2*DIGIT [CFWS]
obs-hour = [CFWS] 2DIGIT [CFWS]
obs-minute = [CFWS] 2DIGIT [CFWS]
obs-second = [CFWS] 2DIGIT [CFWS]
obs-zone = "UT" / "GMT" / ; 協定世界時
; 北米の UT オフセット
"EST" / "EDT" / ; 東部: -5/-4
"CST" / "CDT" / ; 中部: -6/-5
"MST" / "MDT" / ; 山岳部: -7/-6
"PST" / "PDT" / ; 太平洋: -8/-7
;
%d65-73 / ; 軍事タイムゾーン - "A"
%d75-90 / ; ~ "I" および "K"
%d97-105 / ; ~ "Z"、大文字と
%d107-122 ; 小文字の両方
2 桁または 3 桁の年の解釈:
- 00-49: 2000 を加算し、2000-2049 を得る
- 50-99: 1900 を加算し、1950-1999 を得る
- 3 桁: 1900 を加算
タイムゾーン略語の解釈:
| 略語 | 意味 | 同等 |
|---|---|---|
| UT、GMT | 協定世界時 | +0000 |
| EST | 東部標準時 | -0500 |
| EDT | 東部夏時間 | -0400 |
| CST | 中部標準時 | -0600 |
| CDT | 中部夏時間 | -0500 |
| MST | 山岳部標準時 | -0700 |
| MDT | 山岳部夏時間 | -0600 |
| PST | 太平洋標準時 | -0800 |
| PDT | 太平洋夏時間 | -0700 |
| 軍事ゾーン(A-Z) | 予測不可能 | -0000 として扱うべき |
注意: 1 文字の軍事タイムゾーンは RFC 822 で非標準的な方法で定義されているため、その意味は予測不可能です。その意味を確認する帯域外情報がない限り、すべて "-0000" と同等と見なすべきです (SHOULD)。
4.4. Obsolete Addressing (廃止されたアドレス指定)
アドレス指定には 4 つの主な違いがあります:
-
ルーティング: メールボックスアドレスは、
<と>で囲まれている場合、addr-spec の前にルーティング部分を持つことが許可されていました。ルートは、それぞれに "@" が前に付けられたドメイン名のカンマ区切りリストであり、リストはコロンで終了します。 -
CFWS の挿入: local-part と domain のピリオド区切り要素間で CFWS を使用できます(つまり、dot-atom を使用しない)。さらに、local-part は atom に加えて quoted-string を含むことが許可されています。
-
null メンバー: mailbox-list と address-list は "null" メンバーを持つことが許可されていました。つまり、そのようなリストでは、2 つ以上のカンマの間に何もない、またはリストの最初または最後にカンマがある可能性があります。
-
ドメインリテラル: US-ASCII 制御文字と quoted-pair がドメインリテラルで許可されており、ここに追加されています。
obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS]
obs-route = obs-domain-list ":"
obs-domain-list = *(CFWS / ",") "@" domain
*("," [CFWS] ["@" domain])
obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS])
obs-addr-list = *([CFWS] ",") address *("," [address / CFWS])
obs-group-list = 1*([CFWS] ",") [CFWS]
obs-local-part = word *("." word)
obs-domain = atom *("." atom)
obs-dtext = obs-NO-WS-CTL / quoted-pair
メッセージを解釈する際、ルート部分は無視すべきです (SHOULD)。
ルーティングアドレスの例:
廃止されたルーティング形式:
<@node1.example,@node2.example:[email protected]>
↑ ↑
└── ルーティング ──────┘
解釈時にはルーティングを無視し、次のみを使用:
[email protected]
4.5. Obsolete Header Fields (廃止されたヘッダーフィールド)
構文的には、廃止されたフィールド構文の主な違いは、任意のフィールドの複数の出現を許可し、任意の順序で出現できることです。また、フィールド名の最後の ":" の前に任意の量の空白が許可されています。
以下のセクションで特に明記されていない限り、他のフィールドの解釈は、セクション 3 の非廃止対応物の解釈と同じです。
廃止されたフィールドの特徴:
- 複数の出現が許可される
- 任意の順序が許可される
- フィールド名の後、コロンの前に空白が許可される
例:
廃止された形式(推奨されません):
From : [email protected]
Date:Mon, 21 Nov 1997 09:55:06 GMT
現在の標準:
From: [email protected]
Date: Mon, 21 Nov 1997 09:55:06 -0600
第 4 章のまとめ
重要なポイント
-
廃止された構文の二重の役割:
- 生成してはならない (MUST NOT)
- 解析しなければならない (MUST)
-
主な違い:
- より寛容な空白規則
- 特殊文字の許可(NUL、制御文字)
- 2 桁の年
- アルファベットのタイムゾーン
- アドレスルーティング
- フィールドの繰り返し
-
実装の責任:
- 不正な形式のメッセージを堅牢に処理する
- クラッシュしない
- データを失わない
互換性戦略
厳格な生成 寛容な解析
↓ ↓
セクション 3 のみを使用 セクション 3+4 を受け入れる
新しい標準形式 新旧両方の形式
テストチェックリスト
パーサー実装では、以下の廃止された形式をテストする必要があります:
- 2 桁の年(例: "21 Nov 97")
- アルファベットのタイムゾーン(例: "EST"、"PST")
- 裸の CR または裸の LF
- ルーティングを含むアドレス
- フィールド名の後の空白
- 空白のみで構成される折り返し行
- ピリオドを含むフレーズ
次へ: 5. Security Considerations (セキュリティに関する考慮事項)
前へ: 3. Syntax (構文)