Message-Id: <199511212035.PAA01709@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: asg@severn.wash.inmet.com (Al Gilman)
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