# Re: URC spec

Michael Shapiro (mshapiro@ncsa.uiuc.edu)
Mon, 12 Jun 1995 23:03:36 -0500 (CDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Michael Mealling: "Re: URC spec"
- Previous message: Danyel Ceccaldi: "URN -> URL"
- Next in thread: Michael Mealling: "Re: URC spec"
- Reply: Michael Mealling: "Re: URC spec"

    From: mshapiro@ncsa.uiuc.edu (Michael Shapiro)

    Message-Id: <9506130403.AA19416@void.ncsa.uiuc.edu>

    Subject: Re: URC spec

    To: uri@bunyip.com

    Date: Mon, 12 Jun 1995 23:03:36 -0500 (CDT)

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.

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.

    --
    Michael Shapiro                   mshapiro@ncsa.uiuc.edu
    NCSA                              (217) 244-6642
    605 E Springfield Ave. RM 152CAB  fax: (217) 333-5973
    Champaign, IL 61820

- Next message: Michael Mealling: "Re: URC spec"
- Previous message: Danyel Ceccaldi: "URN -> URL"
- Next in thread: Michael Mealling: "Re: URC spec"
- Reply: Michael Mealling: "Re: URC spec"