Message-Id: <199511072304.SAA19963@wilma.cs.utk.edu> From: Keith Moore <email@example.com> To: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: report: URN Architecture Meeting at University of Tennessee, Oct 30-31 Cc: email@example.com Date: Tue, 07 Nov 1995 18:04:32 -0500 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.