From: "Ron Daniel Jr." <rdaniel@acl.lanl.gov>
Message-Id: <9506130924.ZM1832538@macrdan.acl.lanl.gov>
Date: Tue, 13 Jun 1995 09:24:40 -0600
In-Reply-To: mshapiro@ncsa.uiuc.edu (Michael Shapiro)
To: mshapiro@ncsa.uiuc.edu (Michael Shapiro), uri@bunyip.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: rdaniel@lanl.gov 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"