# Re: URN Services

Michael Shapiro (mshapiro@ncsa.uiuc.edu)
Tue, 13 Jun 1995 14:04:55 -0500 (CDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: roxanab@attmail.com: "Re: OCLC's URN Services Proposal"
- Previous message: Ron Daniel Jr.: "Re: URC spec"

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

    Message-Id: <9506131904.AA10985@void.ncsa.uiuc.edu>

    Subject: Re: URN Services

    To: uri@bunyip.com

    Date: Tue, 13 Jun 1995 14:04:55 -0500 (CDT)

This is to provide comments on OCLC's "URN Services", Internet
Draft <draft-shafer-uri-urn-resolution-00>.

There are three sections. The first section suggests a
slightly different syntax that would allow dots in the naming
authority id. The second section claims that the "unregistered
name authorities" are in fact registered. The last section
comments on naming authority registration and recommends that DNS
be considered for the registry.

1. Syntax

The following single modification to the BNF syntax
definition (section 4.1) would allow dots(.) to appear
in the naming authority id:

request ::= service:[//rp/]urn

For example

N2L://oclc.org:555/OCLC/ISBN1234
N2L://oclc.org:555/OCLC.ohio/ISBN1234
N2L:OCLC.ohio/ISBN1234

2. Unregistered Naming Authorities

The resolution path (rp) is stated to be an unregistered
naming authority, but this is not true. If it were
unregistered, it could never be resolved. The rp is a fully
qualified domain name that in fact IS registered in DNS. It
therefore is not clear what the distinction is between rp and
na other than where they are registered (and perhaps the
order in which they are processed).

If the purpose of the rp is to provide alternatives to
enhance persistence, I would recommend that a more
dynamic, scalable means of discovering the alternatives be
designed. Encoding the rp in the reference is static. The
client table is not very scalable.

3. NA registry

I strongly recommend that serious consideration be given
to using DNS as the starting point for name resolutions.
DNS doesn't have to be used for all of the resolution, or
even most of it, just as a globally known starting
point, e.g. as the "registry" for the registered naming
authorities. DNS has enough functionality to be used for
this, at least. It is widely deployed. It has lookup. It
has caches. It has hierarchical names. It would also
eliminate the necessity for "startup configuration files",
like hosts.txt or the OCLC client table (or its implied
equivalent).

DNS TXT records could be used to encode the necessary
resolution information (or new a DNS resource record could be
proposed, but I think the TXT will suffice).

As a strawman example, I'll translate the sample client
table from section 5.2 of the OCLC URN draft into DNS.

Client table
N2L
ISBN -> oclc.org:555
ISSN -> oclc.org:555
LC -> loc.gov:120 ; oclc.org:555
GNU -> gnu.org:120
WWW -> info.cern.ch:120 ; oclc.org:555 ; someone.else:1234
N2C
OCLC -> oclc.org:555

A top level DNS node, e.g. urn-na, would maintain
the information for each naming authority. The DNS
records in the name server files for urn-na would be

isbn IN TXT "N2L oclc.org:555"
issn IN TXT "N2L oclc.org:555"
lc IN TXT "N2L loc.gov:120"
lc IN TXT "N2L oclc.org:555"
gnu IN TXT "N2L gnu.org:120"
www IN TXT "N2L info.cern.ch:120"
www IN TXT "N2L oclc.org:555"
www IN TXT "N2L someone.else:1234"
oclc IN TXT "N2C oclc.org:555"

Then the resolution for a URI like

N2L:ISBN/1-56592-010-4

would start by requesting the TXT records for <isbn.urn-na>
and proceed with the resolution via <oclc.org:555>

    --
    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: roxanab@attmail.com: "Re: OCLC's URN Services Proposal"
- Previous message: Ron Daniel Jr.: "Re: URC spec"