RFC 2298 urn:ietf:rfc:2298 で、 Disposition-Notification-To:領域
とセットで定義されています。 MDN (Message Disposition Notification)
を送るに当たっての要求を書くんですが、 RFC 2298 では実際の
値は定義していません。将来のための予約だけ。
BNF
- Disposition-Notification-Options = "Disposition-Notification-Options" ":" disposition-notification-parameters
- disposition-notification-parameters = parameter *(";" parameter)
- parameter = attribute "=" importance "," 1#value
- importance = "required" / "optional"
このように、ステキで逸般的な構造をしています。
RFC 822 ABNF での定義らしいですが、もしかして 1#value とか ","
の前後に FWS が挿入できたりするんでしょうか。
[3]
RFC 3335 (インターネットEDI, IETF 提案標準) 5.2
は再掲なのかプロファイル的再定義なのかよくわかりませんが、
構文が
parameter = attribute "=" importance ", " 1#value"
とされています。構文の記法についての説明が全然ないので
FWS が自由に挿入できるのかは分かりませんが、
読点の後に1つ SPACE
を入れることを求めているようです。
実際 RFC 3335 に示されている例 (>>4) ではそのようになっています。
パラメーターたち
"required" つきのがあって、それを MUA が理解出来ない場合は、
"failed" disposition-type 以外の MDN を送ってはいけません。
属性名は、 IESG で認可された標準化過程または実験 RFC
で定義されて、 IANA に登録されたものでなければいけません。
または、例によって "X-" 名を実験目的に使うことが出来ます。
[5] RFC 3335 5.2 で2つ引数が定義されています。
(なぜか IANAREG には登録されていません。同じ RFC
で規定されている MDN の Received-content-MIC
欄は登録されているのに。)
signed-receipt-protocol=optional, <protocol symbol>;
<protocol symbol>:
pkcs7-signature | S/MIME | IETF 提案標準 | RFC 3335 |
pgp-signature | PGP/MIME | IETF 提案標準 | RFC 3335 |
署名付き受領証を要求します。
signed-receipt-micalg=optional, <micalg1>, <micalg2>,...;
<micalgn>:
md5 | MD5 | IETF 提案標準 | RFC 3335 |
sha1 | SHA-1 | IETF 提案標準 | RFC 3335 |
rsa-md5 | MD5 | IETF 提案標準 (歴史的) →md5 | RFC 3335 |
rsa-sha1 | SHA-1 | IETF 提案標準 (歴史的) → sha1 | RFC 3335 |
署名付き受領証の MIC 算法を指定します。
最初程優先度が高いものです。署名付き受領証を要求する時は必須です。
なお、 MDN の Received-content-MIC
欄と対応します。が、そちらの可能な値は RFC 1847
に基づく IANAREG を参照しているのに、
こちらはなぜかそうではなく、登録制度もないようです。
- [1] [IANAREG] MDN-Dispostion-notification-option-names http://www.iana.org/assignments/mdn/disp-not-opt/index.html
[2]
名前:
Alternative-available | 代替版が利用可能 | [RFC 3297] |
Alternative-not-available | 代替版が利用可能ではない | RFC 3297 |
[7] RFC 3335 の signed-receipt-protocol と
signed-receipt-micalg は誤って Content-Disposition:
のIANA登録簿に登録されていましたが、現在は削除されており、また >>1
にも登録されているようです。
Content-Disposition: も参照。例
[4]
Disposition-notification-options:
signed-receipt-protocol=optional, pkcs7-signature;
signed-receipt-micalg=optional, sha1, md5
RFC 3335 5.2
その他
message/partial媒体型では、「内側」に入れることになってます。
[6] RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)
( ( 版))
http://tools.ietf.org/html/rfc4130#section-7.3
[8] RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)
( ( 版))
http://tools.ietf.org/html/rfc4130#appendix-A.1
[9] RFC 8098 - Message Disposition Notification
()
https://tools.ietf.org/html/rfc8098#section-2.2