- From: Keith Moore <moore@cs.utk.edu>
- Date: Tue, 07 Nov 1995 18:04:32 -0500
- To: urn@mordred.gatech.edu, uri@bunyip.com, urc@lists.gatech.edu
- Cc: moore@cs.utk.edu
On October 30-31, several proponents of various URN schemes met to discuss
ways to make progress on URNs. This message contains a report of that
meeting, including a list of items for which there was general agreement,
a list of topics requiring further discussion, and outlining areas
and assignments for additional work.
A URN BOF has been scheduled for the Dallas IETF for further discussion
of these topics.
As host of the meeting, I would like to express my appreciation to
the meeting attendees for their hard work, patience, and good will
in working out these agreements.
Keith Moore
----------------------------------------------------------------------
URN Architecture Meeting
A workshop of representatives of announced URN schemes was held at the
University of Tennessee on Oct 30-31. The objective was to identify
areas of convergence, areas likely to benefit from focussed
discussion, and topics marked by deep divisions. It is further hoped
that useful discussion documents will flow from this meeting that can
serve to focus discussion at the upcoming Dallas IETF.
Attendees:
Keith Moore University of Tennessee
Reed Wade University of Tennessee
Michel Mealling Georgia Tech
Ron Daniel Los Alamos National Laboratory
David Ely CNRI
Patrik Falstrom Bunyip Information Systems, Inc.
Stuart Weibel OCLC
Dan Laliberte NCSA
Michael Shapiro NCSA
Agreements:
1. Syntax of URNs
The URN consists of three parts: a prefix string, a naming
authority, and a local unique identifier. There will be a
visible separator between the naming authority and the
local unique identifier.
Canonical proposed URN syntax:
URN:NA[:LUI]
where
URN: identifies the namespace
NA a hierarchical top-level-first slash-delimited name of the
authority who assigns the name. For the purposes of a
generalized Internet specific lookup mechanism this name
should, through some transformation algorithm, be a valid
DNS name.
: designated separator between naming authority and
the LUI
LUI a locally unique identifier of unspecified syntax or
structure. The LUI is optional so that the naming
authority itself can be identified.
examples:
URN:edu/uiuc/ncsa:doc-1234
URN:urn/oclc:35,564,234
URN:org/cni
2. New DNS record type
It is desirable to define one or more new DNS resource record types
(tentatively called NAPTR records) that define mappings from
the "NA" portion of a URN to resolution servers for that URN.
The new resource records will allow listing of multiple resolution
servers and protocols.
3. Basic resolution strategy:
Transform the NA portion of the URN into traditional domain name
syntax, and query DNS for any NAPTR records listed under that domain.
Any fallback strategies to be used (if no resource records are found)
are for future discussion.
4. New TLD (probably .URN)
It is judged desirable to promote the introduction of a new
top-level domain in DNS for the restricted purpose of URN resolution
and to ensure/promote the longevity of the names assigned under this
TLD.
This domain would operate under slightly different rules:
- reassignment is prohibited
- other rules to be determined
Assignment of URNs is not contingent on use of this namespace
It is intended to be a resolution specific, longevity-oriented
part of the DNS name space.
Open Issues for future discussions
Fallback Mechanisms for DNS lookup
-what happens if there are no NAPTR records?
Shorthand notation for URN: redundancy
Detailed URN Syntax
International character sets
Specification of NAPTR Records
Rules for new Top level domain
How are resolution request services specified?
Committee assignments:
NAPTR record structure
Mealling/Moore/Shapiro
URN Syntax and shortcut
Daniel and Weibel
Fallback mechanisms: justification and mechanisms
LaLiberte and Moore
Rules for new TLD
Falstrom, Weibel and Moore
Service requests
LaLiberte Weibel Moore Daniel
Probably two dimensions of service requests:
a.) Resource record encoded services
the availability of services available for a naming authority
might be recorded in resource records
may be a core set of such services which can be defined
in advance.
b.) Document Link service requests
there needs to be a way to invoke services by specification
within a document.
Received on Tuesday, 7 November 1995 18:04:53 UTC