URN Agreement Check List

URN AGREEMENT CHECK LIST

This is a slightly expanded version of a check list that I created during
the IETF meeting this week.  It is my summary of where I believe the URN
implementors are in agreement.  Please correct me if I have assumed
agreement where there is none.

I would value comments on any of these points, and especially Section 6.


A  TECHNICAL ISSUES

1.  GENERAL PRINCIPLES

1.1  There is a clear separation between name-spaces and resolution-systems.

1.2  Several independent names-spaces and several resolution-systems will
be developed.  Existing name-spaces may become part of the URN framework.

1.3  A registry (or registries) will be created to map URNs to
resolutions-systems.


2.  SYNTAX

The URN implementors are willing to accept the following compromise
concerning syntax. There are many details that need to be discussed (e.g.,
character sets).

2.1  The syntax of a URN explicitly indicates the name-space.  It may
indicate a naming-authority.

2.2  The syntax of a URN is:
          <urn> := urn:<nid>:<nss>
     <nid> is a name-space identifier.
     <nss> is a name-space string.

[Note.  There is a question whether the leading "urn:" is desirable.]

2.3  Many name-spaces, use the expanded syntax:
          <nss> := <na><sep><lui>
     <na> is a naming-authority.
     <sep> is a separator defined by the name-space.
     <lui> is a locally unique string.

2.4  With this syntax, each <nid> is a URI as defined in RFC 1630.  In
addition, the whole URN framework forms a URI.


3.  MANAGEMENT OF NAME-SPACES

3.1  Each name-space has associated with it a management system that
ensures the integrity of the name-space and of the URNs within it.  This
includes ensuring that the <nss> are unique within the name-space.

3.2  For those name-spaces that use naming-authorities, the name-spaces
have independent systems for establishing naming-authorities.

3.3  A central procedure will be developed to determine which name-spaces
form part of the URN framework.  Hopefully, there will be a small number of
high quality name-spaces.


4.  REGISTRIES

The following general principles appear to be agreed, but the technical
details need to be worked through.

4.1  The data included in a registry is in a new name pointer format
(NAPTR) which is under development.

4.2  The data includes a mapping
     from: either (a) a <nid>, or (b) a <nid><na> pair
     to:  one or more resolution-systems.

[Note.  It has been suggested that the NAPTR record includes information
about the <nid>, e.g., separators.]

4.3  The format of NAPTR records will not be tied to any specific computer
system.  One use of NAPTR records will be through a modified version of
DNS.


B.  USE OF URNS

5.  AREAS WHERE URN IMPLEMENTATIONS WILL DIFFER

The URN implementors do not require conformance in the following areas.
[Note.  Variations in these important areas will give the schemes their
distinctive features and will determine which are most suitable for
specific application areas.]

5.1  A URN many resolve to one or many data items; it may resolve to
untyped data, typed data, entity-attribute pairs, etc.

5.2  Assertions about names, semantic decisions, and management issues may
be enforced by the name-scheme or the resolution-system, or they may be
left to external systems.  Examples of such assertions are uniqueness,
retention, security, etc.


6.  COMMITMENTS TO USERS OF URNS

To encourage the use of URNs by the developers of  system software and
applications, the URN implementors collectively commit:

6.1  Users can incorporate valid URNs in documents, indexes, and other
items with the assurance that future developments of the URN framework will
not force users to reformat or otherwise modify existing URNs.

6.2  If any URN name-space or resolution-system ceases to be supported, the
remaining URN implementors will ensure that valid URNs will continue to be
resolved through other resolution-systems.

[Note:  Section 6 is a more forceful statement of ideas that have been
discussed informally.]

William Y. Arms
December 7, 1995

Received on Monday, 4 December 1995 13:57:41 UTC