Re: URN Services

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

Received on Tuesday, 13 June 1995 15:08:50 UTC