[9] Message-ID: 頭欄は、 RFC 822 およびその派生仕様において、
当該メッセージの固有識別子を記述する頭欄です。また、
その固有識別子をメッセージ IDと呼び、たまに mid と略されます。
[22] 仕様書によって、一部であると言っていたり、ないと言ってたりします。 RFC 2822 はないという見解のようです。
mid:, cid: URL は、角括弧を省いたものを URI の一部として 利用しています。このように外部の構造の部分として使う場合は、 角括弧を取り除いて使うのが良さげです。角括弧は冗長です。
(とはいえ、場合によってはそういう時でも、角括弧つきのものを うけいれるのが良いでしょう。人に優しく原則です。)
Message-ID, Content-ID が例にでてくる RFC のなかに、 間違って角括弧が必要なのに書いてないのが幾つかあります。 例えば、 RFC 1341 [MIME] で Message-ID が角括弧なし の例が幾つも載ってたりします。
実際のメッセージで角括弧が無い MID/CID がどれだけあるのか 分かりませんが、実装は出来れば対応するべきでしょう。 (といっても References: や In-Reply-To: でそれをやられると、 構文解析が少し面倒になるなあ。)
どこだったかの携帯電話から送られてくる電子メイルは、 <hogehoge@foo.example のように、角括弧が片方しかない MID が使われてました。しかもかなり長い時期続いてました。 (現在どうなってるかは分かりません。) ですから、実装は こうしたものも受け入れるべきでしょう。
もちろんどちらの場合も、角括弧を適当に補ったものを MID/CID とすることになるでしょう。 References/In-Reply-To にその MID を入れるときは、補ったものを入れるべきです。 (または、入れないか。そのどちらかでないと、 RFC 822/2822 などに違反します。)
%[23] メッセージ識別子では % を用いることが認められています。
実際生成時の区切子としてよく使われています。
[24] インターネットメールで完結している限りはそれで良かったのですが、
mid: URL やメーリングリストのアーカイブの Webページの
URL などでメッセージIDが URL の一部に使われるとき、
問題となることがあります。 % は URL ではパーセント符号化して
%25 と書かなければなりません。しかし迂闊なソフトウェアはこれを実装するのを忘れているため、
% が含まれるメールを正しく扱えなかったりします。
Message-ID = "Message-ID:" CFWS msg-id [CFWS] / obs-Message-ID Content-ID = "Content-ID" [FWS] ":" [CFWS] 822.msg-id [CFWS] References = "References:" CFWS msg-id-list [CFWS] / obs-References In-Reply-To = "In-Reply-To:" CFWS msg-id-list [CFWS] / obs-In-Reply-To 822.msg-id = msg-id / obs-msg-id msg-id = "<" id-left "@" id-right ">" id-left = dot-atom / no-fold-quote id-right = dot-atom / no-fold-literal msg-id-list = msg-id *( CFWS msg-id ) / obs-msg-id-list
obs-Message-ID = "Message-ID" [FWS] ":" [CFWS] obs-msg-id-content [CFWS]
obs-msg-id-content = mach-host-phrase ;; RFC 724
/ mach-id ;; RFC 733
/ obs-msg-id ;; RFC 2822 obsolete obs-References = "References" [FWS] ":" msg-id-list [CFWS]
obs-References = "In-Reply-To" [FWS] ":" msg-id-list [CFWS]
obs-msg-id-list = [ 724.reference-item-list ;; RFC 724
/ 733.ref-item-list ;; RFC 733
/ *(obs-phrase / msg-id ) ;; RFC [2]822
] mach-host-phrase = "<" [724.CFWS] host-phrase [724.CFWS] ">"
host-phrase = 724.phrase [724.CFWS] host-indicator
host-indicator = at-indicator [724.CFWS] host-name
at-indicator = 724.CFWS "at" 724.CFWS / "@"
host-name = 724.atom / ipv4-address
724.phrase = 724.word *( [724.CFWS] 724.word )
724.word = 724.atom / 724.quoted-string
724.atom = 1*724.atext
724.atext = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'"
/ "*" / "+" / "-" / "." / "/" / "=" / "?" / "["
/ "\" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~"
724.quoted-string = <"> ( (%x00-07 / %x09-%7F) *(%x00-7F) / <""> ) <">
;; <""> は <"> と解される。単一の <"> を除くと書いてない
;; けど、常識的には駄目なのでしょう。
724.CFWS = *([FWS] 724.comment) (([FWS] 724.comment) / FWS)
724.comment = "(" ( (%x00-27 / %x29-7F) / 724.comment ) ")"
;; CRLF が入っちゃ駄目。 mach-id = "<" [CFWS] host-phrase [CFWS] ">"
733.host-phrase = 733.phrase [CFWS] 733.host-indicator
733.host-indicator = 1*( ( CFWS "at" CFWS / "@" ) [CFWS] node )
node = word / 1*DIGIT
733.atom = 1*733.atext
733.atext = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'"
/ "*" / "+" / "-" / "." / "/" / "=" / "?" / "["
/ "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~"obs-msg-id = "<" [CFWS] 822.addr-spec [CFWS] ">" 822.addr-spec = 822.local-part [CFWS] "@" [CFWS] 822.domain 822.local-part = obs-dot-word 822.domain = obs-dot-atom / domain-literal
724.reference-item-list = 724.reference-item
*( [724.CFWS] "," [724.CFWS] 724.reference-item )
724.reference-item = 724.phrase / mach-host-phrase
733.ref-item-list = ( 733.phrase / mach-id )
*( [733.CFWS] "," [733.CFWS] ( 733.phrase / mach-id ) )[29] Mozilla Thunderbird のフィードリーダー機能のメッセージでは
Message-Id: http://host.example/path/to/entry.html@localhost.localdomain[6] MSA は、メッセージに
Message-ID: 欄に含まれない場合や
RFC 2822 に照らして妥当な構文ではない場合、
Message-ID: 欄を追加または置換して構いません。
RFC 4409 8.3
typo スマソ
Message-ID を定義する各仕様にそれぞれいかに固有の識別子を生成するか についての説明があります。
次の Internet-Draft は各方法を紹介したり推奨される方法を 定義したりしています。
The followup agent MUST not delete any message ID whose local part ends with "_-_" (underscore (ASCII 95), hyphen (ASCII 45), underscore); followup agents are urged to use this form to mark subject changes, and to avoid using it otherwise.
返信代理者は地域部分が「_-_」 (下線 (ASCII 95), ハイフン (ASCII 45), 下線) で終わるメッセイジ ID を削除してはいけません。 返信代理者はこの形式を主題 subject が変更された印として使い、 他の用途で使うのを避けることを推奨します。
NOTE: Subject changes are difficult to determine, but they are significant as possible beginnings of new threads. The "_-_" convention is provided so that posting agents (which have more information about subjects) can flag articles containing a subject change in a way that followup agents can detect without access to the articles themselves. The sequence is chosen as one that is fairly unlikely to occur by accident.
参考: 主題変更は決定が難しいですが、新スレッドの始まりの可能性がある 重要なものです。「_-_」慣習があるので (主題についてより情報を持っている) 投稿代理者は返信代理者が記事自身に接続無しに主題が変更されたことが 分かるように記事に印をつけることが出来ます。
NOTE: Is "_-_" really worth having?
参考: 「_-_」は本当に意味があるのでしょうか?
違プロトコル間でのメッセージ交換はそう稀なことでもありませんが、 各プロトコル間で Message-ID またはそれに相当するものの 書式が一致していることは稀なことでしょう:-) そのような場合に、 Message-ID を書き換える必要が出てきます。
もっとも身近なところでは、電子メイルと電子ニュースで メッセージ交換する場合、電子メイルの方が Message-ID の自由度が 高いので、電子メイル→電子ニュース関門では Message-ID を 書き換えなければならないかもしれません。
[10] MMS からインターネット・メールへの変換時には、 Message-ID:
頭欄はそのまま残さなければなりません。元々存在しなかった場合には RFC 2822
にのっとり生成しなければなりません。 >>8
mid: URL[30] mid: は、
メッセージID
によってメッセージを識別する URL scheme です。
[31]
初期には
message-id:,
x-message-id:
も使われました。
[32] message-id: の実利用例 >>34:
<li> Proposal: <a
href="http://www.acl.lanl.gov/HTML/html-archive.messages/7.html"
urn="message-id:9406101615.AA07817@ulua.hal.com">
<code>ISMAP</code> is in the DTD;
needs to be in the prose</a> gvoosten@isous1.estec.esa.nl[28] RFC 2801 - Internet Open Trading Protocol - IOTP Version 1.0, , https://tools.ietf.org/html/rfc2801#section-3.3.1
[11] MMS には Message-ID: の他に X-Mms-Message-Id:
もあります。
[1] [HTTP92] では、値は URI でした。この URI は資源を取り寄せるために使うものではなく、ニュースのメッセージ ID のように意味の無い文字列でした。 (HTTP だから WWW っぽく、メイル・アドレスではなく URI を構文に選んだのでしょう。)
[2] >>1 結局無くなったわけですが、案外 ETag: 欄あたりに引き継がれたのかもしれません。
[14] RFC 4229 は HTTP92 を出典に状態「provisional」でIANA登録簿に登録しています >>13。
[1] 2003-01-25 16:04 名無しさん: qmail の error message mail の Message-ID は元メッセージの Message-ID と同じことがあるそうです。困ったもんです。
[21] "@" を含まない Content-ID を良く見かけます。ほぼ間違いなくそれは HTMLメイルでした。 MUA などは "@" がない CID も受け入れてあげるのが親切ですが、 (大抵はうざいだけの HTMLメイルに使われているので) あえて対応することもないかもしれません:-) (text/html媒体型を上手く利用する人 (が使う UA) は変な CID を生成しないでしょう、ってことで。)
[3]
%x0D の入った Message-ID なんて実際にあるのか...
(名無しさん 2004-04-20 08:48:20 +00:00)
[12] RFC 4975 - The Message Session Relay Protocol (MSRP) ( ( 版)) http://tools.ietf.org/html/rfc4975#page-37
[15] draft-goland-http-reliability-00 - SOA-Reliability (SOA-Rity) for HTTP ( ( 版)) https://tools.ietf.org/html/draft-goland-http-reliability-00#section-3
[16] 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
[17] RFC 5536 - Netnews Article Format ( ( 版)) http://tools.ietf.org/html/rfc5536#section-1.5
[18] RFC 5536 - Netnews Article Format ( ( 版)) http://tools.ietf.org/html/rfc5536#section-3.1.3
[19] RFC 2392 - Content-ID and Message-ID Uniform Resource Locators ( ( 版)) https://tools.ietf.org/html/rfc2392