Re: mid and cid URLs

Ned Freed (NED@innosoft.com)
Wed, 22 Nov 1995 12:29:16 -0800 (PST)


Date: Wed, 22 Nov 1995 12:29:16 -0800 (PST)
From: Ned Freed <NED@innosoft.com>
Subject: Re: mid and cid URLs
In-Reply-To: "Your message dated Wed, 22 Nov 1995 12:08:45 -0500"
To: Ed Levinson <elevinso@Accurate.COM>
Cc: Ned Freed <NED@innosoft.com>, asg@severn.wash.inmet.com,
Message-Id: <01HXY31QWF869BWPXN@INNOSOFT.COM>

> The context I intended for cid: is the current message, for mid: the
> user's mail hierarchy (i.e., all mail folders, not just an inbox).
> Ned pointed out some cases where one might want to use mid: to refer
> to an encapsulated message but that could as easily be done with a c-ID
> header for the Msg/822 body part.  Thus mid: means a message the user
> owns, a cid: means a MIME entity in the current message, and a
> mid: w/a cid: refers to a MIME entity in a message the user owns.

In other wors the mid specifies the message-id of the outermost message
in the message store.

> Under that definition, a MIME entity of type Msg/822 has no externally
> viewable structure.  To do otherwise creates a much more difficult
> requirement.

I'm not entirely sure it does. How about something like this:

   url-schemes = mid-scheme / cid-scheme
   mid-scheme = mid-ref ["/" (mid-ref / cid-ref)]
   mid-ref = "mid:" id-part
   cid-ref = "cid:" id-part

This would allow for the following:

(1) mid:id-part -- refers to a message as a whole in the message store.
(2) mid:id-part#mid:id-part -- refers to a message/rfc822 part within a
                               given message in the message store.
(3) mid:id-part#cid:id-part -- refers to a specific part of a specific
                               messaqe in the message store.
(4) cid:id-part -- refers to a specific part of the current message.

This gives a very clean result as far as implementation goes -- there's a
single index of outermost message-ids in the message store that is used by
(1)-(3) to find the message in question. In (4) the message in question is
implied by context. And once the message is found the (optional) additional
information is used to locate what part of it should be used.

> Since several MIME entities can contain identical c-IDs those should
> be resolved using Mul/Alt rules.

> I will revise the draft to reflect the above.

I think I'd prefer an approach where the content-id is always qualified by a
top-level message-id (either implicitly or explicitly).

It's also important that there be an indication in the BNF as to which
productions actually give you the URLs syntaxes you use, and which ones are
subordinate to that.

> With that clarification, the combination of Message/External-body;
> access-type=URL and a cid: URL scheme has the same functionality of the
> Message/External-body; access-type=content-id proposal.  While the
> latter will become an Experimental RFC implementors may look to this
> more general scheme.

There's another interesting problem with both of these things. When message or
content ids are used within a message/external-body, you end up with the two
sources of MIME information rather than one. Specifically,
message/external-body is a subtype of message because it also provides a MIME
header for the referenced object. But there is also the header that's attached
to the object itself. Its possible that these could disagree, especially in the 
case of a reference to duplicated identifiers.

The HTTP URL clashes in a similar way with the URL, but in the HTTP case
there's a cute answer -- use the MIME information that's provided in the
external reference as a filter to select a variant. If there's no match the URL
isn't valid in this context.

I think this needs to be resolved in conjunction with these schemes, preferably
by insisting the the types agree, and specifically allowing for the omission
of the inner message/external-body header if the access-type provides the
information itself.

				Ned