Re: mid and cid URLs

Keith Moore (moore@cs.utk.edu)
Tue, 21 Nov 1995 15:35:12 -0500


Message-Id: <199511212035.PAA01709@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: asg@severn.wash.inmet.com (Al Gilman)
Cc: uri@bunyip.com, elevinso@Accurate.COM, ietf-types@uninett.no,
Subject: Re: mid and cid URLs 
In-Reply-To: Your message of "Tue, 21 Nov 1995 14:52:48 EST."
             <9511211952.AA06275@severn.wash.inmet.com> 
Date: Tue, 21 Nov 1995 15:35:12 -0500

> Does it serve any useful purpose, in reviewing the proposed "mid
> and cid URL schemes" to point out that the RFC 822 MIDs and RFC
> 1521 CIDs are our leading legacy example of World-unique resource
> _names_?  That is to say, creating a syntactic scheme whereby
> they fit into the URI family is to create a class of URNs.  These
> items are more aptly called URNs than URLs.  The information in
> the URI does not tell you where to find the object or how to get
> it.  They are identifiers by which we validate that we have an
> instance of a particular named thing, given that we got a
> candidate instance somehow.

Yes, it's good to point this out.

One way to describe a URN is "a resource name which is not tightly
coupled to a particular service location or access method."

URNs aren't terribly useful without an infrastructure that lets a
client find a service location and access method for a particular URN.
Once this (carefully designed) infrastructure is in place, it becomes
fairly easy to add message-ids or content-ids to that URN space.
(modulo perhaps some mapping to make mids or cids fit whatever URN
syntax ends up being used)

I've been thinking of "cid", "message/external-body; access-type=cid"
(and by association, "mid") as *URL* schemes, especially (for the
former two) within the context of multipart/related.  Such a scheme is
useful even without the URN infrastructure.

We need cid URLs now.  Unfortunately, cid URNs will have to wait a bit
longer.

Keith