Re: mid and cid URLs

Ed Levinson (elevinso@Accurate.COM)
Wed, 22 Nov 1995 12:08:45 -0500


Message-Id: <9511221709.AA08740@Accurate.COM>
To: Ned Freed <NED@innosoft.com>
Cc: asg@severn.wash.inmet.com, elevinso@Accurate.COM, ietf-types@cs.utk.edu,
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