Re: mid and cid URLs

Al Gilman (asg@severn.wash.inmet.com)
Wed, 22 Nov 1995 13:40:51 -0500 (EST)


From: asg@severn.wash.inmet.com (Al Gilman)
Message-Id: <9511221840.AA19004@severn.wash.inmet.com>
Subject: Re: mid and cid URLs
To: masinter@parc.xerox.com (Larry Masinter)
Date: Wed, 22 Nov 1995 13:40:51 -0500 (EST)
Cc: uri@bunyip.com
In-Reply-To: <95Nov22.101953pst.2733@golden.parc.xerox.com> from "Larry Masinter" at Nov 22, 95 10:19:52 am

To follow up on what Larry Masinter said ...
  
  I was actually speaking of mid: and cid:, not mailserver: or mailto:,
  but the argument is similar:

Sorry, I answered from the wrong context.
  
  mid: refers to messages
  cid: refers to message bodies and other content
  
Message-ID is changed if you re-send the same content, but Message-ID
is still a key which lets you know you have the right content if
it matches.  This is the way it is used in intermodal operations
between News and Mail.

I a recommending that both MID and CID as used in Mail and MIME be
regarded as most useful as content keys which fit the definition
Roy gave for a URN.  It allows the client to verify content identity
independent of access method or source of retrieval.

If you are sometimes going to qualify a part by the Message-ID as well
as its Content-ID, you need a syntax with room for both parts.  Ed
provided this.  I still want to emphasize that '?' is more literate
URI language than '#' for the punctuation in this form.

Let the syntactic scheme be

thisURI ::= scheme-name: "message-unique@path-to-host"?content-descriptor
		( ; header-phrase )

	content-descriptor ::= "content-unique [ @ host-path-if-different ]

	scheme-name ::= 			; one or choice

Since both semantic classes fit neatly into this harmonized syntax, you
introduce only ONE new scheme and you are done.

I really don't understand why I have to keep explaining this on the
_Uniform_ resource identification list.

  mailto: refers to interactive mail
  mailserver: refers to pre-scripted mail

You and the tool don't really know.  For security reasons there is no
such thing as non-interactive mail.  For infobots such as info@tmn.com,
a simple mailto: URL is enough.  All the URL processing client program
is going to do is send mail.  The difference between chatting with
a buddy and retrieving an archived object should be handled in the
heuristic text contained in the anchor and need not be keyed to the
tool by the URI.  The tool should handle both cases the same.
It must MayI the user for everything in the script.
  
  It's the same reason why there are two z39.50 URL schemes being
  proposed.
  
That may be good or bad.  I haven't reviewed that one.