# Re: CID: and MID: URL schemes

Ed Levinson (elevinso@Accurate.COM)
Thu, 02 Nov 1995 11:05:48 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Barton E. Schaefer: "Re: host vs hostname (Was: CID: and MID: URL schemes)"
- Previous message: Ned Freed: "Re: host vs hostname (Was: CID: and MID: URL schemes)"
- In reply to: Larry Masinter: "CID: and MID: URL schemes"
- Next in thread: Larry Masinter: "Re: CID: and MID: URL schemes"
- Reply: Larry Masinter: "Re: CID: and MID: URL schemes"
- Reply: Harald.T.Alvestrand@uninett.no: "Re: CID: and MID: URL schemes"

    Message-Id: <9511021605.AA03874@Accurate.COM>

    To: Larry Masinter <masinter@parc.xerox.com>

    Subject: Re: CID: and MID: URL schemes

    In-Reply-To: Your message of "Wed, 01 Nov 1995 16:13:59 PST."

                 <95Nov1.161400pst.2733@golden.parc.xerox.com>

    Date: Thu, 02 Nov 1995 11:05:48 -0500

    From: Ed Levinson <elevinso@Accurate.COM>

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?

- Next message: Barton E. Schaefer: "Re: host vs hostname (Was: CID: and MID: URL schemes)"
- Previous message: Ned Freed: "Re: host vs hostname (Was: CID: and MID: URL schemes)"
- In reply to: Larry Masinter: "CID: and MID: URL schemes"
- Next in thread: Larry Masinter: "Re: CID: and MID: URL schemes"
- Reply: Larry Masinter: "Re: CID: and MID: URL schemes"
- Reply: Harald.T.Alvestrand@uninett.no: "Re: CID: and MID: URL schemes"