仕様書

RFC 822 における構文

[9] RFC 822 における注釈の構文は、次のように説明できます。

• [15] ( ではじまり、 ) で終わる
• [10] 括弧内には、任意の ASCII文字 (U+0000-U+007F) を使って良い
• [11] ただし ( と ) は対になっていなければならない (\( と \) を除く)
• [12] ( と対になっている ) の直前が \ ではいけない (\\ を除く)
• [13] CRLF が続いた後には U+0020 か U+0009 が必要
• [14] U+0009 は非推奨

RFC 822 における構文

[17] RFC 2822 における注釈の構文は、次のように説明できます >>16。

• [18] ( ではじまり、 ) で終わる
• [22] 括弧内には U+0001-U+007F を使って良い
• [19] ただし ( と ) は対になっていなければならない (\( と \) を除く)
• [20] ( と対になっている ) の直前が \ ではいけない (\\ を除く)
• [21] CRLF が続いた後には U+0020 か U+0009 が必要
• [23] U+0000 は使ってはいけないが、 \ のあと U+0000 は理解できなければならない
• [24] CR は CRLF としてのみ使って良いが、 \ のあと CR も理解できなければならない
• [26] LF は CRLF としてのみ使って良いが、 \ のあと LF も理解できなければならない
• [30] CRLF と CRLF の間には U+0009 と U+0020 以外の文字が1つ以上なければならないが、なくても理解できなければならない

[25] 実装が対応しなければならないものベースで RFC 822 と比較すると、

• [29] \ の後でない U+0000 は使えない
• [27] \ の後でも LF の前でもない CR は使えない
• [28] \ の後でも CR の後でもない LF は使えない

RFC 822 における注釈

[7] 注釈 (comment) は、 メールプロトコルのサーバーに引き渡すなどの目的で列を再生成する際には、 字句間の区切りとして機能している場合、 SPACE 1つと字句的に等しい >>6 3.4.3. とされていました。

[8] RFC 822 はこれ以外に注釈が空白と等価であると明言しているところはありません。 厳密に解釈すると実装は注釈を空白と解釈して構いませんが、著者は注釈を生成してはいけないことになります (BNF に一致しないので)。しかしこれは一般的な解釈とは異なります。

HTTP における注釈

[36] >>35

     comment        = "(" *( ctext / quoted-pair / comment ) ")"
     ctext          = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
     quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )
     obs-text       = %x80-FF

CGI

[3] CGI では次のように定義されています >>4。

      comment         = "(" *( ctext | comment ) ")"
      ctext           = <any TEXT excluding "(" and ")">

message/global

[2] RFC 5335 により、 message/global においては UTF-8 の使用が認められるようになりました (RFC 5335 4.3)。

[31] これは RFC 2822 に、更に U+0080-U+10FFFF を認めるものです。

[32] RFC 6532 (>>33) も同様に U+0080-U+10FFFF を追加するものです。