- From: Keith Moore <moore@cs.utk.edu>
- Date: Tue, 21 Nov 1995 15:35:12 -0500
- To: asg@severn.wash.inmet.com (Al Gilman)
- Cc: uri@bunyip.com, elevinso@Accurate.COM, ietf-types@uninett.no, moore@cs.utk.edu
> 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
Received on Tuesday, 21 November 1995 15:35:48 UTC