# Re: URC spec

Ron Daniel Jr. (rdaniel@acl.lanl.gov)
Tue, 13 Jun 1995 09:24:40 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ron Daniel Jr.: "Re: URC spec"
- Previous message: Michael Mealling: "Re: URC spec"
- Next in thread: Daniel LaLiberte: "Re: URC spec"
- Reply: Daniel LaLiberte: "Re: URC spec"

    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"

- Next message: Ron Daniel Jr.: "Re: URC spec"
- Previous message: Michael Mealling: "Re: URC spec"
- Next in thread: Daniel LaLiberte: "Re: URC spec"
- Reply: Daniel LaLiberte: "Re: URC spec"