URNs: syntax and registries

Keith, Ron,

Many thanks for your extremely helpful comments on the draft message that I
recently circulated to the Knoxville participants.  Here is a revised (and
shortened) version which I am posting to the full URI list.

There appear to be only two issues where the Knoxville framework is
difficult for non-DNS based URNs.  Can I suggest the following?

1.  Make the naming-scheme explicit in the syntax of a URN.  (In the
Knoxville design, the naming-scheme is implicit.  This forces every URN
resolution to begin with an access to a URN registry.  It also causes
problems for integrating existing naming-schemes, which typically come from
a non-DNS world.)

2.  Define the URN registry in terms of an abstract data structure that is
capable of replication.  (My concern is that although you envisage multiple
registries the current design is tied too tightly to DNS.)

If we can reach agreement in these two area,  I hopeful that we will leave
Dallas with broad agreement on all the main topics.

Bill

--------------------------------------------------------------


THE SYNTAX OF URNS AND URN REGISTRIES


This note discusses requirements of the URN syntax, and the registration of
naming-schemes.  It recommends a syntax, and compares the recommendation
with the syntax proposed at the recent Knoxville meeting.


A.  INTRODUCTION

The note uses the following terminology:

(a)  A "naming-scheme" is a system for assigning unique, persistent names
(URNs).

(b)  A "resolution-system" is a computer system that resolves a URN.

(c)  A "URN-registry" is a system that, given a URN, identifies the
resolution-systems that can resolve the URN.

Naming-schemes should be recognized as separate from resolution-systems.
Naming-schemes may well have a longer life than any specific
resolution-system.  Several resolution-systems may be capable of resolving
names from a given naming-scheme.


B.  RECOMMENDATIONS

This note makes four recommendations:

Syntax of URNs

R1)  The syntax of a URN should explicitly identify the naming-scheme.
(Inspection of a URN should indicate that this is a Handle, or a Path-URN,
etc.)

R2)  The character set and separators used within a URN should be left to
the discretion of the naming-scheme.


Registration of Naming-schemes

R3)  Each naming-scheme should register a list of resolution-systems that
can resolve URNs from that naming-scheme.  (This list will change with
time.)

R4)  The registration data should be distributed in a generic format which
can be used in a variety of URN-registries.


C.  A PROPOSED SYNTAX FOR URNs

The following is a simple syntax that satisfies R1 and R2:

   URN:<scheme>:<r-name>

<scheme> is the name of a naming-scheme.
<r-name> is a resource name, i.e. a persistent identifier that is unique
within the naming-scheme

The following are valid URNs within an imaginary naming-scheme called "xyz":

     URN:xyz:foo.bar/item1
     URN:xyz:janedoe!august95.html


D.  EXAMPLE -- INTEGRATION OF DIVERSE SYSTEMS

Recommendations R1 to R4 and the proposed syntax permit integration of
diverse naming-schemes, resolution-systems, and URN-registries.

For example, consider the connection to the Internet of a service called
ABC.  (Imagine that ABC is CompuServe, America On-Line, the Microsoft
Network, Disney, or the French Minitel.)  ABC may be only loosely
integrated with the Internet.  From ABC's viewpoint, the Internet is a
legacy system to be accommodated; from the Internet's viewpoint, ABC is a
legacy system.

Suppose that ABC has a private naming-scheme and resolution-system for
persistent, unique names.  Subsequently, ABC decides to make its resources
available to others, including the general Internet, and wishes to allow
its users to have access to other resources.

This is achieved by registration of ABC's identifiers as a URN
naming-scheme.  Thus, a resource known internally to ABC as "item1" has the
URN "URN:abc:item1".  ABC provides a public resolution-system or arranges
that an existing resolution-system can resolve URNs in the abc
naming-scheme.

Recommendation R1 ensures that ABC's identifiers are universally
recognizable and that ABC's resolution-system can differentiate between
ABC's identifiers and other URNs.

Recommendation R2 ensures that ABC does not have to change any identifier
or its internal systems to make its resources available to the Internet.

Recommendation R3 allows ABC to register its URN in existing URN-registries.

Recommendation R4 allows ABC to operate its own URN-registry.


E.  THE KNOXVILLE PROPOSAL

The Knoxville proposal for URN syntax is:

        URN:NA[:LUI]

  NA is a naming authority.
  LUI is a locally unique string.

In this proposal, the naming-scheme is not explicitly identified. Therefore
every URN resolution begins by looking in a URN-registry to determine the
resolution-system to use.  The Knoxville meeting proposed a URN-registry
mechanism based on DNS.  The meeting proposed the definition of one or more
new DNS resource record types (tentatively called NAPTR records) that
define mappings from the naming authority portion of a URN to resolution
servers for that URN.

This introduces some subtle problems for naming-schemes and
resolution-systems that are not based on DNS.

(a)  Since, in general, the naming-scheme can not be deduced from the URN,
an arbitrary URN can not be resolved without reference to a URN-registry.

(b)  There is a danger that by designing the first URN-registry to be
integrated tightly with DNS will create data structures that will limit
replication beyond DNS.

(c)  An organization (such as ABC) that wishes its naming-scheme to coexist
with other URN naming-schemes will usually have to modify its identifiers
(for example by adding the prefix "abc." to all identifiers.

On the surface, the Knoxville syntax would allow shorter URNs than the
suggested syntax.  However, the need to support alternative name-schemes as
peers essentially suggests that the scheme name will be added to every
naming authority name.


F.  ACKNOWLEDGMENTS

This is a shortened version of a message that was recently sent to the
participants of the Knoxville meeting. Many thanks for the comments on the
note from Ron Daniel and Keith Moore, and for related comments from Dan
LaLiberte and Stu Weibel.  (This does not imply that they agree with
everything in this revised version.)



William Y. Arms
November 27, 1995

Received on Monday, 27 November 1995 14:23:13 UTC