Re: mid and cid URLs

To follow up on what Keith Moore said ...
  
  > 1. By construction, these two nominal schemes are one scheme and we
  > should only use one name for them.  MID or MIDCID are possibles.
  
  No they're not the same, and as long as we're talking about URLs,
  we shouldn't try to force the two into a single scheme.
  
Looking at what follows the ( mid | cid ): in Ed's syntax,
what is different?  They are the same syntax scheme. 

  a) A message is not the same as a body part.  A message has senders,
  recipients, a subject, and so on, in addition to content.  A body part
  just has typing information and content.

Message and Part URIs can be told apart anyway, without peeking at
the scheme prefix.  That is my argument.  You don't need to use
two scheme-names because you can tell 'em apart anyway.  I am not
attempting to assume that Content-IDs and Message-IDs are jointly
World-unique, although I bet they are.  All a URI is is a key.
The syntax for the key can be the same and the semantic class of
the two subsets of keyed objects still be different.

That's all MIME processing is allowed to know it has.  URIs don't
have to be so blind.  There could be other headers on the part.
  
  b) The likely use of CID is to reference bodyparts within a
  multipart/related.  The likely use of MID is to refer to messages in a
  message store (like an IMAP server).  Some mail readers will support
  one and not the other.  The two need to be able to succeed or fail on
  their own merits, rather than trying to load each one with the other's
  burdens.

If that's the only use, you don't need to define a URI to cover
the cid case.  To define a URI, you need to think of the bulk 
of the URI users who are not MIME mail handlers.
  
  c) You don't want to refer to a body part as a message-id plus an
  offset.  The same body part (with the same CID) can occur in multiple
  messages.
  
I now understand the risks (Thanks, Ned).  At least the message
originating agent would know the right part numbering, so a
part-number-path URL returned to the sending node would function
correctly as a part key.  The alternate syntax I suggested still
supports object identification by matching the Content-ID markup.

  Either MIDs or CIDs could probably be implemented fairly easily, and
  (at least as importantly) consistently between differnet platforms.
  But for a combined MID/CID, you don't know where to find the object.
  
By either my syntax or Ed's syntax, the two kinds of identifiers
are syntactically distinguishable without reference to the scheme-name.

Here is an example which assumes that one retrieves by Content-ID
without reference to any Message-ID.  I'll start with the more
URL-traditional syntax.

	mid: //path-to-host/?part-unique		; is Content-ID
	mid: //path-to-host/message-unique		; is Message-ID
  
Here is a rough hack at Ed's syntax for these:

	cid: "#part-unique@path-to-host"		; is Content-ID
	mid: "message-unique@path-to-host"		; is Message-ID

You can throw a blanket over the scheme prefix and still tell
these apart.  And you know one place to go: There is a
path-to-host in either one.  Even if a message is sent from
one site embedding a part Content-ID-ed at another node,
you have two places to go, which may be better than just
being told one, because only one may support archiving.

  It's a Bad Idea to try to impose URN functionality on URLs.  In order
  to implement URNs, we need a URL substrate that works simply and
  rationally.

Wrong.  Equally bad to fail to document incumbent URN forms
(which Message-ID is) while waiting for the retrieval services to
materialize.  Message-ID

Al

Received on Tuesday, 21 November 1995 17:59:54 UTC