From: "Ron Daniel Jr." <firstname.lastname@example.org> Message-Id: <9506130924.ZM1832538@macrdan.acl.lanl.gov> Date: Tue, 13 Jun 1995 09:24:40 -0600 In-Reply-To: email@example.com (Michael Shapiro) To: firstname.lastname@example.org (Michael Shapiro), email@example.com Subject: Re: URC spec Hi Michael, Thanks for the comment on the draft URC spec. > There is an implied assumption in the SGML-based URC > specifiction that URNs resolve to URCs. I think that this is a > fundamental mistake. URNs should not be required to resolve to > URCs. They should be allowed to resolve to any resource. I am going to add some stuff to the trivial query language section that steals from the OCLC URN proposal. I will add the N2L, N2C, N2N, L2C, C2C queries so that a name, location, or characteristic can be resolved into a name, location, or characteristic. Note that I am not adding the ability for a name to resolve directly to the resource. I am very hesitant to do such a thing. My take on the URC service is that it provides the level of indirection between the name and the resource that makes it possible to easily move resources, supply multiple copies, etc. Note that this does not mean that the user has to see the URC. For example, if N2L was requested, I will say that the response should come back as an HTTP Location: header (or whatever the new approach is) so that the client will immediately fetch the resource without the user noticing what is going on. > In section 3 "Attribute Sets", the specification states > > "A ... complication arises as a result of using a URN for > the AID .... We resolve AID-1, which is a URN, and ge back a > URC (URC-2) .... What is the AID in URC-2? How do we avoid > infinite regress?" > > The proposed solution is to convert the AID from a URN to > something which is not a URN, but has all the properties of a URN > in that it is a persistent name for a resource that happens not > to be a URC. > > This infinite regression could also be solved if the > requirement that all URNs resolve to URCs be relaxed. Here, it > seems to me, is a perfect example of the need for a URN which > does NOT resolve to a URC. In my draft spec, the AID can be a URN, or the reserved string "root". This is, admittedly, somewhat of a hack. However, I am very hesitant to allow the URN to return just anything. The whole point of the URN was to get away from the problems we have with URLs by providing the level of indirection. I can't forsee what all the consequences of resolving directly to a resource are, but it has a warning bell going off in my head. -- Ron Daniel Jr. email: firstname.lastname@example.org Advanced Computing Lab voice: (505) 665 0597 MS B287 fax: (505) 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM 87545 tautology:"Conformity is very popular"