[52] 
[DFN[[RUBYB[内容識別子][Content ID]]]]は、
[[MIME実体]]を[[識別]]する[[識別子]]です。

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

* 仕様書

[REFS[
- [31] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) <http://tools.ietf.org/html/rfc2046#section-5.1.4>
- [36] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) <http://tools.ietf.org/html/rfc2046#section-5.2.3>
- [38] [CITE@en[RFC 2392 - Content-ID and Message-ID Uniform Resource Locators]] ([TIME[2015-06-21 16:39:07 +09:00]] 版) <https://tools.ietf.org/html/rfc2392>
- [39] [CITE[RFC Errata Report]] ([TIME[2015-06-24 13:52:46 +09:00]] 版) <http://www.rfc-editor.org/errata_search.php?rfc=2392>
]REFS]

* 意味

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

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

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

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

* 構文

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

* 文脈

[FIG(short list)[ [58] [[内容識別子]]の利用

- [CODE[cid:]]
- [CODE[mid:]]
- [CODE[message/external-body]]

]FIG]

* [CODE(MIME)@en[multipart/alternative]] における内容ID

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

[33] 情報内容が同じ[[本体部分]]は、同じ [CODE(MIME)@en[[[Content-ID]]]]
でも構いません [SRC[>>31]]。

[EG[
[34] 例えば異なる方法でアクセスする [CODE(MIME)@en[[[message/external-body]]]]
同士は、同じ [CODE(MIME)@en[[[Content-ID]]]] にできます [SRC[>>31]]。
]EG]

[35] [CODE(MIME)@en[[[multipart/alternative]]]] 全体と各[[本体部分]]では、
異なる [CODE(MIME)@en[[[Content-ID]]]] とするべきです [SRC[>>31]]。

* [CODE(MIME)@en[message/external-body]] における内容ID

[37] [CODE(MIME)@en[[[message/external-body]]]] の内側の[[ヘッダー]]では、
[CODE(MIME)@en[[[Content-ID]]]] は必須です [SRC[>>36]]。

* [CODE(URI)@en[cid:]] URL

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

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

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

* [CODE(URI)@en[mid:]] URL

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

;; [CODE(URI)@en[[[mid:]]]] を参照。

* 歴史

[FIG(quote)[
[FIGCAPTION[
[40] RFC 1340             6.1  Optional Content-ID Header Field
]FIGCAPTION]

> 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 値は可能な限り固有であるように生成しなければなりません。
]FIG]

[FIG(quote)[
[FIGCAPTION[
[41] RFC 1521 6.1.  Optional Content-ID Header Field
]FIGCAPTION]

> 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 の処理の節で説明しています。

[INS[

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

[FIG(quote)[
[FIGCAPTION[
[42] RFC 2045 7.  Content-ID Header Field
]FIGCAPTION]

> 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 の処理の節で説明しています。


;; [50] [[訳注]]: [[message/external-body媒体型]]及び
[[multipart/alternative媒体型]]を参照。

]FIG]

**

- [14] [WEAK[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 入力を送る時に [CODE[Content-ID:]] 欄を [[URI]] として使う云々と言っています (''Sending form data to an HTTP server'' <http://www.w3.org/MarkUp/HTMLPlus/htmlplus_42.html>)。 [[cid:]] URI が規定される前ですし、 [[HTTP]] の [[Message-ID:]] 欄は [[URI]] を指定するとされていたことから考えても、この当時から [CODE[Content-ID:]] 欄に URI を入れようと考えていたことが推察されます。 (ただ例示がないので確かではありません。)
- [16] >>15 これは実装されてたんでしょうかね? [[Arena]] とかで。

[17] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
([TIME[2009-09-12 07:37:40 +09:00]] 版)
<http://tools.ietf.org/html/rfc5621#section-9.2>

[18] [CITE@ja[デコメ。auのContent-IDの制約。@はひとつだけ。 - CPA-LABテクニカル]]
([TIME[2009-10-16 09:00:00 +09:00]] 版)
<http://www.cpa-lab.com/tech/0135>

[19] [CITE@en[RFC 4463 - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks]]
( ([TIME[2011-12-04 10:31:11 +09:00]] 版))
<http://tools.ietf.org/html/rfc4463#section-5.4.5>

[20] [CITE@en[RFC 4975 - The Message Session Relay Protocol (MSRP)]]
( ([TIME[2012-02-26 13:20:50 +09:00]] 版))
<http://tools.ietf.org/html/rfc4975#page-38>

[21] [CITE@en[RFC 6787 - Media Resource Control Protocol Version 2 (MRCPv2)]]
( ([TIME[2012-11-13 15:18:40 +09:00]] 版))
<http://tools.ietf.org/html/rfc6787#section-6.2.7>

[REFS[
- [22] [CITE[OData Version 4.0 Part 1: Protocol Plus Errata 01]] ([TIME[2014-09-04 16:00:00 +09:00]] 版) <http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html#_Toc370374937>
]REFS]

[23] >>22 も正しくない [CODE(MIME)@en[[[Content-ID:]]]] の例を示しています。

[24] [CITE@en[RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer]]
( ([TIME[2014-09-13 18:22:39 +09:00]] 版))
<https://tools.ietf.org/html/rfc5547#section-6>

[28] [[DRP]] は [[HTTPヘッダー]]として、値が [[URL]] である [CODE(HTTP)@en[[[Content-ID:]]]]
[[ヘッダー]]を提案していました [SRC[>>25]]。

[REFS[
- [25] [CITE[The HTTP Distribution and Replication Protocol]]
( ([TIME[1999-02-05 02:56:54 +09:00]] 版))
<http://www.w3.org/TR/NOTE-drp>
- [26] [CITE@en[RFC 4229 - HTTP Header Field Registrations]] ([TIME[2014-11-02 18:53:20 +09:00]] 版) <http://tools.ietf.org/html/rfc4229#section-2.1.24>
]REFS]

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

[29] [CITE@en[RFC 2392 - Content-ID and Message-ID Uniform Resource Locators]]
( ([TIME[2014-12-22 15:20:11 +09:00]] 版))
<https://tools.ietf.org/html/rfc2392>

[30] [CITE@en-US[Batch Requests | ArangoDB Documentation]]
( ([TIME[2015-01-13 16:43:59 +09:00]] 版))
<https://docs.arangodb.com/HttpBatchRequest/README.html>

[47] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
([TIME[2015-06-21 16:17:31 +09:00]] 版)
<https://tools.ietf.org/html/rfc5621>

[FIG(quote)[
[FIGCAPTION[
[48] [CITE@en[Batching Requests  |  Gmail API  |  Google Developers]]
([TIME[2015-10-08 03:21:07 +09:00]] 版)
<https://developers.google.com/gmail/api/guides/batch>
]FIGCAPTION]

> 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.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[49] [CITE@ja[Google アナリティクス API リクエストのバッチ処理  |  アナリティクス Real Time Reporting API  |  Google Developers]]
( ([TIME[2016-09-30 03:30:47 +09:00]]))
<https://developers.google.com/analytics/devguides/reporting/realtime/v3/batching>
]FIGCAPTION]

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

]FIG]