[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:
[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:
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.
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.
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:
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.
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.
[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 serverhttp://www.w3.org/MarkUp/HTMLPlus/htmlplus_42.html)。 cid: URI が規定される前ですし、 HTTP の Message-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
[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
[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