Message-Id: <9511221709.AA08740@Accurate.COM>
To: Ned Freed <NED@INNOSOFT.COM>
Subject: Re: mid and cid URLs
In-Reply-To: Your message of "Tue, 21 Nov 1995 22:33:31 PST."
<01HXX6XEA39Y9BWNBV@INNOSOFT.COM>
Date: Wed, 22 Nov 1995 12:08:45 -0500
From: Ed Levinson <elevinso@Accurate.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.
Under that definition, a MIME entity of type Msg/822 has no externally
viewable structure. To do otherwise creates a much more difficult
requirement.
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.
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.
While I'm looking at changes...
Al suggested that the rule
cidmid = msgmid "#" cidurl
would fit with the general URL syntax if it used "/" as the separator.
I like that and will, if there are no objections make that change.
Using a sytax that differs from msgid, however, does not make sense
to me.
Much earlier we had a discussion about using hostname or host for what
the draft calls id-spec. My conclusion from that is that host should
be used. I will make that change and suitably adjust the pragraph
about transforming an id-spec to a message- or content-ID.
All the changes will come out after the IETF meeting and Cynthia's
deadline has passed.
Best.../Ed
PS Just to let people know where I stand in Keiths hierarchy of
concerns, I'm at step 1 one of those who
... saw the need for intra-message references in MIME and
proposed a mechanism for it using content-ids and
message/external-body (thus involving minimal changes to MIME)
On Tue, 21 Nov 1995 22:33:31 PST Ned Freed wrote:
> > To follow up on what Ned Freed said ...
>
> > <Al Gilman:>
> > > 1. By construction, these two nominal schemes are one scheme and we
> > > should only use one name for them. MID or MIDCID are possibles.
>
> > While its certainly possible to do this, I don't see why you'd want to.
> > Message-IDs and Content-IDs are distinct entities. A given part of a mess
age
> > can have neither, one, or both of them.
>
> > I thought from Ed's construction that one was expected to cite a
> > Message-ID to reference a Content-ID. So I didn't expect that
> > one would not find an identified [part] Content in an
> > un-identified Message.
>
> Its certainly possible... Its also possible for a message to have a bunch of
> message-ids and a bunch of content-ids, associated with a set of parts that
> don't overlap.
>
> This needs to be clarified in Ed's draft, I believe. When a content-id is
> qualified with a message-id, which message-id is it qualified by? The outermo
st
> one on the entire message seems logical and its what I would choose, but I ca
n
> come up with cases where its not the right choice. For example, suppose you
> have a message that contains a bunch of different drafts of the same message,
> each draft having the same content-ids but different message-ids. This is
> admittedly a contrived example, but it illustrates the sorts of concerns
> qualification leads to.
>
> For that matter, the issue of whether or not nested message-ids can be referr
ed
> to needs to be addressed.
>
> > There is also the question of scope. I see support of message-ids as a
> > cross-message sort of thing, preferably implemented as an index emcompass
ing
> > the entire mailbox. (Preference would be given to whatever message is
> > "current", of course.) Content-ids, on the other hand,
> > are largely intended to
> > be used within a single message. It therefore seems logical to give some
> > indication of scope in the scheme identifier.
>
> > Defining a URI scheme gets you into a much bigger market than
> > that. Look at what Hypermail does to link things up from a
> > combination of Message-IDs, mailbox designations, and http: URLs.
>
> This doesn't change the fact that there's going to be a separate database
> of content-ids and message-ids to search.
>
> > If any significant traffic in CID-identified parts develops,
> > people will want to refer to them across wider scopes. In
> > particular, I would expect that enclosures to one message will be
> > recycled as references cited [or attached as a
> > message/external-body] in other messages. You only discover
> > after the fact that there are seven people who would be
> > interested in what you cooked up to tell Joe.
>
> One problem with this is there are no reference counts to insure that a given
> chunk of content will be retained. This is a fact of life with messages store
s,
> which typically have very high content turnover rates.
>
> Ned