UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 翻訳 1998年 8月21日 / translation 21 August 1998 修正 2006年12月09日 / correction 09 December 2006 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc2392 を訳者(marimo@wdic.org)が個人的な好奇心で適当に 翻訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。 誤訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要 な場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容につい ての指摘は、いつでも歓迎します。 著作権全文 (Full Copyright Statement) --- 本文書末尾の原文より Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 訳: この文書およびその翻訳は、コピーされ、他に供給され、そして派生語を 論評、違った形で説明、またはその実装の促進が準備され、コピーされ、 出版されて、もし上記の版権情報およびこのパラグラフが、すべてのその ようなコピーおよび派生した作品に含まれるなら、どのような種類の制限 なしで全体や部分を配布できる。しかし、この文書自身は、発展途上のイ ンターネット標準やインターネット標準プロセスにおいて定義された著作 権のための手続のために必要な場合や、英語以外の言語への翻訳の要求が ある場合を除いて、インターネットソサエティまたは他のインターネット 組織の版権情報や参照を削除するなど、いかなる点でも修正できない。 上記で与えられる制限された権限は永久で、インターネットソサエティま たはその後継者、委託人によって撤回されることはない。 ここに含まれるこの文書及び情報は、ありのまま "AS IS" インターネット ソサエティに関して提供され、そして、インターネット特別技術調査委員会 (IETF)タスクフォースは、保証、説明または暗示、どのような保証にも制限 されない一切の権利を侵害しない情報を利用すること、何らかの市販性の保 証の暗示、または、特定の目的のための適切性の全てを否定する。 Network Working Group E. Levinson Request for Comments: 2392 August 1998 Obsoletes: 2111 Category: Standards Track Content-ID and Message-ID Uniform Resource Locators URL の Content-ID と Message-ID このメモの位置づけ この文書は、インターネットコミュニティのためのインターネット標準運 用プロトコルを策定し、改善のための議論、提案を求めるものである。 規格化状態とプロトコルのステータスのために、この現在の版である「イ ンターネット公的プロトコル標準」 (STD 1) も参照されたい。このメモの 配布は無制限である。 著作権について Copyright (C) The Internet Society (1998). All Rights Reserved. 摘要 ユニフォーム・リソースロケータ (URL) スキーム、"cid:" および "mid:" は、メッセージおよびメッセージボディ部分の参照を許す。 例えば、単一のマルチパートメッセージの中に、一つのHTMLボディ部分が、 同じメッセージの他のパーツに格納された参照を含むかもしれない。 (RFC 2111)からの変更 3ページ目の cid URL を Content-ID に変換する例を明瞭化した。現在の 例は mid の代わりに cid URLを使う。 正しい Content-ID を持つ際に生じるメッセージ例を訂正した。それらは 今は山形括弧(<>) を使う。Message-ID ヘッダを二番目の例に付け加えた。 1. 始めに ウェブページおよびそれらの関連したイメージを運搬する電子メール内の [MIME] の使用は、HTMLが、イメージまたはメッセージに含められている他 のデータを参照することを許可するために、URLスキームを必要とする。 Content-ID の URL、"cid:" は、その目的にかなう。 同様に、ネットニュースリーダは、関連するメッセージにリンクするため に Message-IDを使用する。Message-ID URLは、そのようなメッセージを "resource" (資源) と言うために、スキーム "mid:" を提供する。 "mid:"（Message-ID) と "cid" (Content-ID) URLスキームは、識別子を メッセージおよびそれらのボディ部分に提供する。"mid" スキームは、特定 のメッセージを参照するために、電子メールメッセージの message-id （の一部）を用いる。 "cid" スキームは、メッセージの特定のボディ部分を参照する。その使用 は、一般に参照した本文と同じメッセージの他のボディ部分の参照に制限さ れる。"mid" スキームは、また、content-ID のアドレスを含むことによっ て、明示されたメッセージ内の特定のボディ部分を同様に参照するかもしれ ない。 専門用語の解説。用語 "body part"（ボディ部分）および "MIME実体" は 同義である。それらは、MIMEメッセージ、またはメッセージそのものか、マ ルチパート・メッセージに含まれるボディ部分のうちの 1 つのいずれかの ヘッダ、及びボディを参照する。 2. MID と CID URL スキーム RFC 1738 [URL] は、Message-ID と Content-ID のために、"mid" と "cid" スキームをそれぞれ確保する。このメモはそれらのURLのための構文 を定義する。それらが同じ構文要素を使うので、それらは、一緒に提出され る。 URL の取る書式 content-id = url-addr-spec message-id = url-addr-spec url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec cid-url = "cid" ":" content-id mid-url = "mid" ":" message-id [ "/" content-id ] 注意事項: インターネットメールメッセージにおいて、Content-ID [MIME] ま たは Message-ID [822] ヘッダにおける addr-spec は山形括弧(<>)に 囲まれる。Message-ID または Content-ID の addr-spec 以来、URL内 で許されていない文字を含んでいるかもしれない。そのような何らか の文字（"/" を含み、それが "mid" スキーム内で予約される）を含む ときは [URL] の %hh エスケープ処理を使って１６進符号化されなけ ればならない。 "message-id" だけを持つ "mid" URLは、全体のメッセージを参照する。 "cid" URL と同様に、付加された "content-id" によってそれはメッセー ジ内のボディ部分を参照する。MIMEボディ部分の Content-ID は、世界中で 決して重複しないものである（一意である）ことが必要である。しかし、 メッセージを蓄える多くのシステムにおいては、ボディ部分は索引を独立し てそれらの文脈（メッセージ）を付けられない。 "mid" URL の長い書式は、そのようなシステムによってインターオペラビ リティ（interoperability）を支えるために必要な文脈に供給するためにデ ザインされた。 この指定に対応している実装は、"mid" URL の長い書式をサポートするた めに必要である(message-id/content-id)。 対応する実装により選択しうるが、それに必要ではなく、content-idの一 意性（重複しない性質）を利用し、メッセージ記憶装置のあらゆるボディ部 分でも参照すると "cid" URLは解釈する。 制限された状況（例えば multipart/alternate内）には、一つのメッセー ジは、同じ Content-ID を持つ幾つかのボディ部分を含んでいるかもしれな い。例えば、同一のデータが異なる方法によってアクセスされるとき、それ は発生する。 そのような場合、対応する実装は、Content-ID が参照するボディ部分を 選択するために包んでいる MIME実体（例えば、multipart/alternate）の規 則を使用するために必要である。 "cid" URLは、"cid:" 接頭辞を取り去り、% 符号化された文字をそれらと 同等の US-ASCII 文字に変換し、そして残った部分を <> 括弧の対によって 囲むことで一致する Content-ID メッセージヘッダ [MIME] に変換される。 例えば、"cid:foo4%25foo1@bar.net" は、 Content-ID: と一致している。 プロセスを逆転し、しかも URL の特別な文字をそれらの % 符号に変換す ることによりオリジナルな cid が生成される。 "mid" URLは、同様な方式の Message-ID または Message-ID/Content-ID ペアに変換される。 Message-ID と Content-ID は、世界中で決して重複しないもの（一意性） が要求される。 すなわち、どの種類のメッセージも同じMessage-ID addr-spec を持つこ とはなく、またどの種類のボディ部分も同じ Content-ID addr-spec を持つ ことはない。 多くのメッセージシステムにより使われた一般の技術は、時間を使い、そ してローカルなホストのドメイン名と共に、スタンプの年代を定めることで ある。例えば 950124.162336@XIson.com 。 いくつかの例 次のメッセージは、別のボディ部分に含まれるイメージを参照するHTML本 体部分を含んでいる。双方のボディ部分は、Multipart/Related MIME実体に 含まれている。HTML IMG タグは、イメージを指し示す cidurl を含んでい る。 From: foo1@bar.net To: foo2@bar.net Subject: A simple example Mime-Version: 1.0 Content-Type: multipart/related; boundary="boundary-example-1"; type=Text/HTML --boundary-example 1 Content-Type: Text/HTML; charset=US-ASCII 他のボディ部分、例えばこのようなステートメントにより: IETF logo --boundary-example-1 Content-ID: Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example-1-- 以下のメッセージは別のメッセージ（受取主がメッセージをためておいて くれることを希望する）を示す。 From: bar@none.com To: phooey@all.com Subject: Here's how to do it Message-ID: <970701.32784@VIers.none.com> Content-type: text/html; charset=usascii 前のメッセージ, あなたの提案するアプローチがどのように成し遂 げられたものかを示します。 3. セキュリティ対策 ここで定義された URL は、アドレッシングまたは参照を付けるメカニズ ムを提供する。これらの URL の値は、一致する Message-ID と Content-ID により創作者環境について明らかにしない。 機密情報が明らかにされないことを保証するために、関係する mid およ びcid URLを使う露見創作者について存在する所で用心が取らなければなら ない。 それらの用心は、Message-ID と Content-ID の既存のメールを扱うため に、すでに適所にあるべきである。 4. 参照 [822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", August 1982, STD 11, RFC 822, August 1982. [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [MULREL] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. 5. 受領 "mid" のオリジナルな概念、及び "cid" URL は、WWW の Tim Berners-Lee の独創的な視野の一部であった。 アイディアと設計は MHTML作業部会の Harald Alvestrand、Dan Connolly、 Roy Fielding、Larry Masinter、Jacob Palme らとの議論から大いに協力を 得た。 6. 奥付 Edward Levinson 47 Clive Street Metuchen, NJ 08840-1060 USA Phone: +1 908 549 3716 EMail: XIson@cnj.digex.net