Content-ID:

内容ID

[52] 内容識別子 (Content ID) は、 MIME実体識別する識別子です。

[53] メッセージ識別子とよく似ており、歴史的にも関係が深いですが、 メッセージ全体ではなく部分 (part) を識別できる点が違います。

目次

  1. 仕様書
  2. 意味
  3. 構文
  4. 文脈
  5. multipart/alternative における内容ID
  6. message/external-body における内容ID
  7. cid: URL
  8. mid: URL
  9. 歴史
    1. §

仕様書#

意味#

[54] 内容識別子は、それが付与されたMIME実体識別します。

[55] MIME実体への内容IDの付与は、 Content-ID: MIMEヘッダーによります。

[56] 内容識別子は、それ単独で大域的に固有な識別子であることが本来の仕様上は期待されています。

[57] しかし実際にはそれが含まれるメッセージ内で固有であることしか保証できない程度の固有性の識別子が使われることもよくあります。

構文#

[51] メッセージ識別子を参照。

文脈#

[58] 内容識別子の利用

multipart/alternative における内容ID#

[32] multipart/alternative の各本体部分は、 情報内容が同じでないなら、異なる Content-ID とするべきです >>31

[33] 情報内容が同じ本体部分は、同じ Content-ID でも構いません >>31

[34] 例えば異なる方法でアクセスする message/external-body 同士は、同じ Content-ID にできます >>31

[35] multipart/alternative 全体と各本体部分では、 異なる Content-ID とするべきです >>31

message/external-body における内容ID#

[37] message/external-body の内側のヘッダーでは、 Content-ID は必須です >>36

cid: URL#

[43] cid: URL を使うと Content-ID によって本体部分を識別できます。

[44] この URL は、同じメッセージ中の本体部分を参照するために使えます >>38

[45] 同じメッセージとの制約しかありませんから、 multipart/* の階層を超えて参照することはできると思われます。 message/rfc822 など message/* の壁を越えることはできないと思われます。

mid: URL#

[46] mid: URL にはメッセージIDに加えて Content-ID を指定できます。異なるメッセージであっても本体部分を識別できます。

mid: を参照。

歴史#

[40] RFC 1340 6.1 Optional Content-ID Header Field

In constructing a high-level user agent, it may be desirable to allow one body to make reference to another. Accordingly, bodies may be labeled using the "Content-ID" header field, which is syntactically identical to the "Message-ID" header field:

[1] 高水準利用者エージェントの構築のために、ある本体が他の本体を参照可能にするのが望ましいかもしれません。 従って、本体は "Message-ID" 頭欄と構文的に同等の "Content-ID" 頭欄を使って札付けできます。

  • [2] Content-ID := msg-id

Like the Message-ID values, Content-ID values must be generated to be as unique as possible.

[3] Message-ID 値同様、 Content-ID 値は可能な限り固有であるように生成しなければなりません。

[41] RFC 1521 6.1. Optional Content-ID Header Field

In constructing a high-level user agent, it may be desirable to allow one body to make reference to another. Accordingly, bodies may be labeled using the "Content-ID" header field, which is syntactically identical to the "Message-ID" header field:

[8] 高水準利用者エージェントの構築のために、ある本体が他の本体を参照可能にするのが望ましいかもしれません。 従って、本体は "Message-ID" 頭欄と構文的に同等の "Content-ID" 頭欄を使って札付けできます。

  • [4] id := "Content-ID" ":" msg-id

Like the Message-ID values, Content-ID values must be generated to be world-unique.

[5] Message-ID 値同様、 Content-ID 値は世界的に固有であるように生成しなければなりません。

The Content-ID value may be used for uniquely identifying MIME entities in several contexts, particularly for cacheing data referenced by the message/external-body mechanism. Although the Content-ID header is generally optional, its use is mandatory in implementations which generate data of the optional MIME Content-type "message/external-body". That is, each message/external-body entity must have a Content-ID field to permit cacheing of such data.

[6] Content-ID 値は幾つかの文脈で MIME 実体を唯一的に特定するために使われ得ます。 とりわけ message/external-body の仕組みでは参照データのキャッシュのために使われます。 Content-ID 頭は一般に省略可能ですが、任意の MIME 内容型 "message/external-body" のデータを生成する実装には使用することを強制します。 つまり、各 message/external-body 実体は必ず Content-ID 欄を持ってそうしたデータのキャッシュを可能にしなければなりません。

It is also worth noting that the Content-ID value has special semantics in the case of the multipart/alternative content-type. This is explained in the section of this document dealing with multipart/alternative.

[7] Content-ID 値は multipart/alternative 内容型の場合に特別な意味を持つことにも注意しておく必要があります。 これはこの文書の multipart/alternative の処理の節で説明しています。

訳注: message/external-body媒体型及び mulipart/alternative媒体型を参照。

[42] RFC 2045 7. Content-ID Header Field

In constructing a high-level user agent, it may be desirable to allow one body to make reference to another. Accordingly, bodies may be labelled using the "Content-ID" header field, which is syntactically identical to the "Message-ID" header field:

[9] 高水準利用者エージェントの構築のために、ある本体が他の本体を参照可能にするのが望ましいかもしれません。 従って、本体は "Message-ID" 頭欄と構文的に同等の "Content-ID" 頭欄を使って札付けできます。

  • [10] id := "Content-ID" ":" msg-id

Like the Message-ID values, Content-ID values must be generated to be world-unique.

[11] Message-ID 値同様、 Content-ID 値は世界的に固有であるように生成しなければなりません。

The Content-ID value may be used for uniquely identifying MIME entities in several contexts, particularly for caching data referenced by the message/external-body mechanism. Although the Content-ID header is generally optional, its use is MANDATORY in implementations which generate data of the optional MIME media type "message/external-body". That is, each message/external-body entity must have a Content-ID field to permit caching of such data.

[12] Content-ID 値は幾つかの文脈で MIME 実体を唯一的に特定するために使われ得ます。 とりわけ message/external-body の仕組みでは参照データのキャッシュのために使われます。 Content-ID 頭は一般に省略可能ですが、任意の MIME 内容型 "message/external-body" のデータを生成する実装には使用することを強制します。 つまり、各 message/external-body 実体は必ず Content-ID 欄を持ってそうしたデータのキャッシュを可能にしなければなりません。

It is also worth noting that the Content-ID value has special semantics in the case of the multipart/alternative media type. This is explained in the section of RFC 2046 dealing with multipart/alternative.

[13] Content-ID 値は multipart/alternative 内容型の場合に特別な意味を持つことにも注意しておく必要があります。 これはこの文書の multipart/alternative の処理の節で説明しています。

#

  • [14] 2002-12-10 (火) 20:19 名無しさん: CID を未だに正しく使わない UA があります。特に M$ 製品, 例えば Windoze XP 付属の M$NExplorer の「ようこそ」メッセージは、画像部分の Content-ID: 欄の値を foo.gif のような名前にし、 HTML 部分の img要素src属性を cid:foo.gif とするような激しい規格違反を平気でしています。どうせ M$ のことですから、プロトコルの脱共有化かなんかの一環として積極的にやってるんでしょう。
  • [15] HTML+ では、複数部分で form 入力を送る時に Content-ID: 欄を URI として使う云々と言っています (Sending form data to an HTTP server http://www.w3.org/MarkUp/HTMLPlus/htmlplus_42.html)。 cid: URI が規定される前ですし、 HTTPMessage-ID: 欄は URI を指定するとされていたことから考えても、この当時から Content-ID: 欄に URI を入れようと考えていたことが推察されます。 (ただ例示がないので確かではありません。)
  • [16] >>15 これは実装されてたんでしょうかね? Arena とかで。

[17] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( 版) http://tools.ietf.org/html/rfc5621#section-9.2

[18] デコメ。auのContent-IDの制約。@はひとつだけ。 - CPA-LABテクニカル ( 版) http://www.cpa-lab.com/tech/0135

[19] RFC 4463 - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks ( ( 版)) http://tools.ietf.org/html/rfc4463#section-5.4.5

[20] RFC 4975 - The Message Session Relay Protocol (MSRP) ( ( 版)) http://tools.ietf.org/html/rfc4975#page-38

[21] RFC 6787 - Media Resource Control Protocol Version 2 (MRCPv2) ( ( 版)) http://tools.ietf.org/html/rfc6787#section-6.2.7

[23] >>22 も正しくない Content-ID: の例を示しています。

[24] RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer ( ( 版)) https://tools.ietf.org/html/rfc5547#section-6

[28] DRPHTTPヘッダーとして、値が URL である Content-ID: ヘッダーを提案していました >>25

[27] RFC 4229DRP >>25 を出典に HTTPヘッダーIANA登録簿に状態「情報提供」で登録しています >>26

[29] RFC 2392 - Content-ID and Message-ID Uniform Resource Locators ( ( 版)) https://tools.ietf.org/html/rfc2392

[30] Batch Requests | ArangoDB Documentation ( ( 版)) https://docs.arangodb.com/HttpBatchRequest/README.html

[47] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( 版) https://tools.ietf.org/html/rfc5621

[48] Batching Requests  |  Gmail API  |  Google Developers ( 版) https://developers.google.com/gmail/api/guides/batch

If a given part of the request had a Content-ID header, then the corresponding part of the response has a matching Content-ID header, with the original value preceded by the string response-, as shown in the following example.

[49] Google アナリティクス API リクエストのバッチ処理  |  アナリティクス Real Time Reporting API  |  Google Developers ( ()) https://developers.google.com/analytics/devguides/reporting/realtime/v3/batching

リクエストのパーツに Content-ID ヘッダーがある場合、対応する応答のパーツには、それに一致する Content-ID ヘッダーが指定されます。応答のパーツのヘッダーは、以下の例に示すように、元の値の先頭に文字列 response- が付いた値となります。