[要約] RFC 2392は、Content-IDとMessage-IDのUniform Resource Locators（URL）に関する仕様を定めたものです。このRFCの目的は、メッセージ内のリソースを一意に識別するためのURLの使用方法を提供することです。
Network Working Group E. Levinson
Request for Comments: 2392 August 1998
Obsoletes: 2111
Category: Standards Track
Content-ID and Message-ID Uniform Resource Locators
Content-IDおよびMessage-ID Uniform Resource Locator
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message.
Uniform Resource Locator（URL）スキームの「cid：」と「mid：」を使用すると、メッセージとメッセージの本文部分を参照できます。たとえば、単一のマルチパートメッセージ内で、1つのHTMLボディパートに、同じメッセージの他のパートへの参照が埋め込まれている場合があります。
Changes from (RFC 2111)
（RFC 2111）からの変更点
Clarified the example on page 3 on of converting cid URLs to Content-IDs. The example now uses a cid URL instead of an mid.
cid URLをContent-IDに変換する3ページ目の例を明確にしました。この例では、midではなくcid URLを使用します。
Corrected the example messages to have the correct Content-ID form; they now use the angle brackets. Added a Message-ID header to the second example.
サンプルメッセージを修正して、正しいContent-IDフォームを追加しました。山かっこを使用するようになりました。 2番目の例にMessage-IDヘッダーを追加しました。
The use of [MIME] within email to convey Web pages and their associated images requires a URL scheme to permit the HTML to refer to the images or other data included in the message. The Content-ID Uniform Resource Locator, "cid:", serves that purpose.
電子メール内で[MIME]を使用してWebページとその関連画像を伝達するには、HTMLがメッセージに含まれる画像やその他のデータを参照できるようにするURLスキームが必要です。 Content-IDのUniform Resource Locator、「cid：」がその目的を果たします。
Similarly Net News readers use Message-IDs to link related messages together. The Message-ID URL provides a scheme, "mid:", to refer to such messages as a "resource".
同様に、ネットニュースリーダーはメッセージIDを使用して、関連するメッセージをリンクします。 Message-ID URLは、そのようなメッセージを「リソース」として参照するためのスキーム「mid：」を提供します。
The "mid" (Message-ID) and "cid" (Content-ID) URL schemes provide identifiers for messages and their body parts. The "mid" scheme uses (a part of) the message-id of an email message to refer to a specific message. The "cid" scheme refers to a specific body part of a message; its use is generally limited to references to other body parts in the same message as the referring body part. The "mid" scheme may also refer to a specific body part within a designated message, by including the content-ID's address.
「mid」（メッセージID）および「cid」（コンテンツID）URLスキームは、メッセージとその本文部分の識別子を提供します。 "mid"スキームは、電子メールメッセージのメッセージID（の一部）を使用して、特定のメッセージを参照します。 「cid」スキームは、メッセージの特定の本文部分を指します。通常、その使用は、参照している本文部分と同じメッセージ内の他の本文部分への参照に限定されます。 「mid」スキームは、コンテンツIDのアドレスを含めることにより、指定されたメッセージ内の特定のボディパーツを指す場合もあります。
A note on terminology. The terms "body part" and "MIME entity" are used interchangeably. They refer to the headers and body of a MIME message, either the message itself or one of the body parts contained in a Multipart message.
用語に関する注記。 「ボディパーツ」と「MIMEエンティティ」という用語は同じ意味で使用されます。それらはMIMEメッセージのヘッダーと本文を参照します。メッセージ自体、またはマルチパートメッセージに含まれる本文部分の1つです。
RFC 1738 [URL] reserves the "mid" and "cid" schemes for Message-ID and Content-ID respectively. This memorandum defines the syntax for those URLs. Because they use the same syntactic elements they are presented together.
RFC 1738 [URL]では、メッセージIDとコンテンツIDにそれぞれ「mid」と「cid」のスキームが予約されています。このメモは、これらのURLの構文を定義します。それらは同じ構文要素を使用するため、一緒に表示されます。
The URLs take the form
URLは次の形式を取ります
content-id = url-addr-spec
message-id = url-addr-spec
url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
url-addr-spec = addr-spec; RFC 822 addr-specのURLエンコーディング
cid-url = "cid" ":" content-id
cid-url = "cid" "：" content-id
mid-url = "mid" ":" message-id [ "/" content-id ]
Notes: In Internet mail messages, the addr-spec in a Content-ID [MIME] or Message-ID [822] header is enclosed in angle brackets (<>). Since addr-spec in a Message-ID or Content-ID might contain characters not allowed within a URL; any such character (including "/", which is reserved within the "mid" scheme) must be hex-encoded using the %hh escape mechanism in [URL].
注：インターネットメールメッセージでは、Content-ID [MIME]またはMessage-ID [822]ヘッダーのaddr-specが山括弧（<>）で囲まれています。 Message-IDまたはContent-IDのaddr-specには、URL内で許可されていない文字が含まれている可能性があるためです。このような文字（「mid」スキーム内で予約されている「/」を含む）は、[URL]の％hhエスケープメカニズムを使用して16進エンコードする必要があります。
A "mid" URL with only a "message-id" refers to an entire message. With the appended "content-id", it refers to a body part within a message, as does a "cid" URL. The Content-ID of a MIME body part is required to be globally unique. However, in many systems that store messages, body parts are not indexed independently their context (message). The "mid" URL long form was designed to supply the context needed to support interoperability with such systems.
「メッセージID」のみを含む「中間」URLは、メッセージ全体を指します。 「content-id」を追加すると、「cid」URLと同様に、メッセージ内の本文部分を参照します。 MIME本文のContent-IDは、グローバルに一意である必要があります。ただし、メッセージを格納する多くのシステムでは、本文部分はそのコンテキスト（メッセージ）とは独立して索引付けされません。 「中間」URLの長い形式は、そのようなシステムとの相互運用性をサポートするために必要なコンテキストを提供するように設計されています。
A implementation conforming to this specification is required to support the "mid" URL long form (message-id/content-id). Conforming implementations can choose to, but are not required to, take advantage of the content-id's uniqueness and interpret a "cid" URL to refer to any body part within the message store.
この仕様に準拠した実装は、「mid」URLの長い形式（message-id / content-id）をサポートするために必要です。準拠する実装では、コンテンツIDの一意性を利用し、「cid」URLを解釈してメッセージストア内の任意のボディパーツを参照することを選択できますが、必須ではありません。
In limited circumstances (e.g., within multipart/alternate), a single message may contain several body parts that have the same Content-ID. That occurs, for example, when identical data can be accessed through different methods. In those cases, conforming implementations are required to use the rules of the containing MIME entity (e.g., multipart/alternate) to select the body part to which the Content-ID refers.
限られた状況（例：multipart / alternate内）では、1つのメッセージに、同じContent-IDを持つ複数のボディパーツが含まれる場合があります。これは、たとえば、同じデータに異なる方法でアクセスできる場合に発生します。これらの場合、コンテンツIDが参照する本文部分を選択するために、包含MIMEエンティティ（例：multipart / alternate）のルールを使用するための準拠実装が必要です。
A "cid" URL is converted to the corresponding Content-ID message header [MIME] by removing the "cid:" prefix, converting the % encoded character to their equivalent US-ASCII characters, and enclosing the remaining parts with an angle bracket pair, "<" and ">". For example, "cid:foo4%25foo1@bar.net" corresponds to
「cid」URLは、「cid：」プレフィックスを削除し、％エンコードされた文字を同等のUS-ASCII文字に変換し、残りの部分を山括弧のペアで囲むことにより、対応するContent-IDメッセージヘッダー[MIME]に変換されます。 、「<」および「>」。たとえば、「cid：foo4%25foo1@bar.net」は、
Content-ID: <foo4%25foo1@bar.net>
Reversing the process and converting URL special characters to their % encodings produces the original cid.
プロセスを逆にして、URL特殊文字をそれらの％エンコーディングに変換すると、元のcidが生成されます。
A "mid" URL is converted to a Message-ID or Message-ID/Content-ID pair in a similar fashion.
「中間」URLは、同様の方法でメッセージIDまたはメッセージID /コンテンツIDのペアに変換されます。
Both message-id and content-id are required to be globally unique. That is, no two different messages will ever have the same Message-ID addr-spec; no different body parts will ever have the same Content-ID addr-spec. A common technique used by many message systems is to use a time and date stamp along with the local host's domain name, e.g., 950124.162336@XIson.com.
メッセージIDとコンテンツIDはどちらもグローバルに一意である必要があります。つまり、2つの異なるメッセージが同じMessage-ID addr-specを持つことはありません。異なるボディパーツが同じContent-ID addr-specを持つことはありません。多くのメッセージシステムで使用されている一般的な手法は、ローカルホストのドメイン名（例：950124.162336@XIson.com）と共に日時スタンプを使用することです。
Some Examples
いくつかの例
The following message contains an HTML body part that refers to an image contained in another body part. Both body parts are contained in a Multipart/Related MIME entity. The HTML IMG tag contains a cidurl which points to the image.
次のメッセージには、別の本文部分に含まれる画像を参照する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
to the other body part, for example through a statement such as:
<IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
--boundary-example-1
--boundary-example-1
Content-ID: <foo4*foo1@bar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
R0lGODlhGAGgAPEAAP ///// ZRaCgoAAAACH + PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4Aなど...
--boundary-example-1--
--boundary-example-1--
The following message points to another message (hopefully still in the recipient's message store).
次のメッセージは別のメッセージを指します（うまくいけばまだ受信者のメッセージストアにあります）。
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
<A HREF= "mid:960830.1639@XIson.com/partA.960830.1639@XIson.com"> previous message</A>, shows how the approach you propose can be used to accomplish ...
<A HREF= "mid:960830.1639@XIson.com/partA.960830.1639@XIson.com">前のメッセージ</A>は、提案したアプローチを使用して達成する方法を示しています...
The URLs defined here provide an addressing or referencing mechanism. The values of these URLs disclose no more about the originators environment than the corresponding Message-ID and Content-ID values. Where concern exists about such disclosures the originator of a message using mid and cid URLs must take precautions to insure that confidential information is not disclosed. Those precautions should already be in place to handle existing mail use of the Message-ID and Content-ID.
ここで定義されたURLは、アドレス指定または参照メカニズムを提供します。これらのURLの値は、対応するMessage-IDとContent-IDの値よりも、発信者環境については公開しません。そのような開示に懸念がある場合、midおよびcid URLを使用するメッセージの発信者は、機密情報が開示されないように予防策を講じる必要があります。 Message-IDとContent-IDの既存のメールの使用を処理するために、これらの予防策はすでに整っているはずです。
[822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", August 1982, STD 11, RFC 822, August 1982.
[822]クロッカーD。、「ARPAインターネットテキストメッセージのフォーマットの標準」、1982年8月、STD 11、RFC 822、1982年8月。
[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME] Borenstein、N。、およびN. Freed、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[MULREL] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[MULREL] Levinson、E。、「The MIME Multipart / Related Content-type」、RFC 2387、1998年8月。
The original concept of "mid" and "cid" URLs were part of the Tim Berners-Lee's original vision of the World Wide Web. The ideas and design have benefited greatly by discussions with Harald Alvestrand, Dan Connolly, Roy Fielding, Larry Masinter, Jacob Palme, and others in the MHTML working group.
「mid」および「cid」URLの元のコンセプトは、Tim Berners-Leeのワールドワイドウェブの当初のビジョンの一部でした。アイデアとデザインは、MHTMLワーキンググループのHarald Alvestrand、Dan Connolly、Roy Fielding、Larry Masinter、Jacob Palmeなどとの議論によって大きな恩恵を受けています。
Edward Levinson 47 Clive Street Metuchen, NJ 08840-1060 USA
エドワードレビンソン47 Clive Street Metuchen、NJ 08840-1060 USA
Phone: +1 908 549 3716
EMail: XIson@cnj.digex.net
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。