Re: CID: and MID: URL schemes

Larry,

Thanks for kind words about draft-levinson-cid-01.txt.

How would you suggest the handling of %xx hex-encoding be described.
Here's my attempt:

       where id-spec is a restricted form of "addr-spec" as defined
       in [RFC822] and hostname and uchar are defined in [RFC1738,
       sec 3.1].  The purpose of the restriction on addr-spec is to
       eliminate special characters from the cid URL.  Such
       characters, if required, can be encoded using the [RFC1738]
       %xx hex encoding escape mechanism included in uchar.

I'm not sure about having to decode any %nn in the content- or
message-IDs.  Why not leave them as is, they're valid characters in
the content- and message-ID environments.  Nope, that leads to
ambiguity.  Are <E%20Levinson@accurate.com> and "<E Levinson@accurate.com>"
the same?  How's this:

       ...  To transform a cidurl or
       midurl into a valid content-id or message-id, decode the escape
       sequences and surround the id-spec part with the enclosing
       brackets, i.e.,

	       raw-spec   =  id-spec ; with escape sequences decoded

               content-id = "<" raw-spec ">".

               message-id = "<" raw-spec ">".

	The content- or message-ID may contain special characters and
	may require quoting.

It would seem simpler to declare "E%20L" and "E L" as different and
require the same form to be used in both places.

Yes, a mid does imply Message/rfc822 and since both the mid and cid
URLs are globally unique one might assume that they couldn't be the
same.  But they are two different name spaces.  This is the first
situation that I'm aware of in which they're both discussed together.
Given the specs 822 and 1521 quiet about this, we could as well.  Or
suggest that the intersection of cid and mid urls be nil.

Best.../Ed

On Wed, 01 Nov 1995 16:13:59 PST Larry Masinter wrote:
> OK, I found draft-levinson-cid-01.txt document. It looks pretty good.
> 
> Comments:
> 
> I think you need to be more careful about your description of the
> handling of %xx hex-encoding of characters in content-ID tags that are
> not otherwise representable inside URLs.
> 
> > 	 To transform a cidurl or
> >        midurl into a valid content-id or message-id, surround the
> >        id-spec part with the enclosing brackets, i.e.,
> 
> but in fact you also have to decode any URL-encoded sequences %nn. It
> seems that these URL schemes aren't really *subsets* but *encodings*
> of content- and message- IDs.
> 
> Why, in fact, are two schemes needed? Can the same id-spec appear as
> both a cid and a mid?
> 
> Is the type of the object referred to by a mid always implicitly
> message/rfc822?

Received on Thursday, 2 November 1995 12:02:03 UTC