W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

are 'cid' URLs relative?

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 26 May 2000 09:36:00 -0500
Message-Id: <200005261324.JAA2170991@smtp2.mail.iamworld.net>
To: "Jonathan Borden" <jborden@mediaone.net>
Cc: xml-uri@w3.org
At 10:53 PM 2000-05-25 -0400, Jonathan Borden wrote:

>	True, but the identical URI can exist in different messages each having a
>distinct contents part.

This would be a direct violation of the relevant Proposed Standard of the

[sorry to have to belabor the correction of a minor red herring...]

RFC-2392 which defines the IETF Proposed Standard for the 'cid' URL says
explicitly  "The Content-ID of a MIME body part is required to be globally

For 'globally' in this case, read "across all messages and not just within
the current multipart."

A Content-ID may be reused across multiple physical parts in one or more
messages where the several parts sharing an ID contain alternate
formattings of the same content, as in PDF, HTML, plaintext.  But this is
an assertion that the sense of the message is common and will be delivered
by any choice among the like-identified body parts.  Compare this with the
smil:switch construct.

The kind of context-dependency that you allude to is explicitly proscribed
by the "required to be globally unique" language in the RFC.


At 10:53 PM 2000-05-25 -0400, you wrote:
>Al Gilman wrote:
>> At 10:10 PM 2000-05-25 -0400, Jonathan Borden wrote:
>> >
>> >	For example "el cid":
>> >
>> >	"cid:contents" = "cid:contents"  (these are absolute URIs
>> no :-?) and yet
>> >the resources returned are dependent on the document context of the
>> >enclosing MIME message.
>> >
>> I am sorry, how do you get that?
>> Even if cid: URLs are only used to refer to parts in the same multipart
>> message, their suffixes are all different.  There is only one part with a
>> given cid: URL anywhere in any message.
>	True, but the identical URI can exist in different messages each having a
>distinct contents part.
>Jonathan Borden
Received on Friday, 26 May 2000 09:24:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:58 UTC