2.1.25 Uniform Resource Names (urn)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Oct-97


John Curran <jcurran@bbn.com>
Leslie Daigle <leslie@bunyip.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>

Applications Area Advisor:

Harald Alvestrand <Harald.T.Alvestrand@uninett.no>

Mailing Lists:

General Discussion:urn-ietf@bunyip.com
To Subscribe: majordomo@bunyip.com
In Body: In body of message: subscribe urn-ietf
Archive: ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive

Description of Working Group:

The goal of this working group is to define both a Uniform Resource Name (URN) framework and an initial set of components that fit this framework.

URNs are persistent identifiers for information resources. The output of this Working Group will comply with RFC 1737, which defines URNs and gives requirements for them. The framework will define the mechanics for enabling global scope, persistence, and legacy support requirements of URNs; requirements for namespaces to support this structure will also be defined. Although the framework will allow URNs to be defined that vary in terms of degree of scalability and persistence, ensuring "user friendliness" of all resultant identifiers is beyond the scope of this group.

This WG will define the framework for URNs, at least one resolution registry system, and at least one namespace. RFCs describing additional material will also be developed (per the milestones, below).

Input documents:

o A Framework for the Assignment and Resolution of Uniform Resource Names <draft-daigle-urnframework-00.txt

o Resolution of Uniform Resource Identifiers using the Domain Name System <draft-daniel-naptr-01.txt

o Requirements for URN Resolution Systems <draft-girod-urn-res-require-00.txt

Goals and Milestones:

Oct 96


Submit revision of URN Framework document as Internet-Draft.

Oct 96


Submit revised version of the NAPTR proposal as an Internet-Draft.

Oct 96


Submit Syntax document as an Internet-Draft.

Oct 96


Submit document detailing the N2L/N2R/etc resolution results as an Internet-Draft.

Nov 96


Submit document describing one (new) namespace as an Internet-Draft.

Dec 96


Submit revised N2L/N2R/etc document as an Internet-Draft.

Dec 96


Submit NAPTR proposal to IESG as Experimental RFC. Submit Framework document to IESG for publication as an RFC. Submit syntax paper to IESG for publication as an RFC.

Dec 96


Submit paper outlining grandfathering one namespace into the framework as an Internet-Draft.

Feb 97


Submit revised grandfather namespace document as Internet-Draft.

Feb 97


Submit N2L/N2R/etc document to IESG for publication as RFC.

Feb 97


Submit revised new Namespace document as Internet-Draft.

Mar 97


Submit grandfathered namespace paper to IESG for publication as RFC. Submit new namespace proposal to IESG for publication as RFC.


Request For Comments:







URN Syntax



Resolution of Uniform Resource Identifiers using the Domain Name System



A Trivial Convention for using HTTP in URN Resolution

Current Meeting Report

Minutes of the Uniform Resource Names (URN) Working Group

Session Chair: Leslie Daigle

Reported by: Sally Hambridge

Reviewed by: URN WG

The URN working group met to discuss "URNs in a practical world," with the intent of talking about registration and standardization, NAPTR, RFCs, PDIs and the possibility of wrapping up the working group.

There are several systems currently using URNs. There is a current draft: draft-lyon-itp-nodes-02.txt, as well as FINBNs and NISO ISDIs. The group agreed that these were "good" illustrations of URNs since they seemed to be using names reasonably. The lyon draft specifies the URN as the transaction ID but the common case is to define its own transaction ID as the URN. This is not standard. FINDBNs are used by the National Library of Finland. This is a naming system for documents and a name space to fit with it. NISO ISDIs are digital IDs for publications. Multicast is also interested in URNs for their work.

Registration and Standards Doc - this is a re-working of an earlier document. It was re-focused at the Munich meeting and is now a set of mechanical procedures for registering name spaces. The doc proposed 4 levels:

1. Experimental
2. Informal
3. Standard
4. Top-level

The idea has been copied in great part from the MIME media-types. Experimental namespace IDs would be self-assigned; Informal would be easy to get and contexts for use would be identifiable as short-term. It would be a string ID based on OID/accession number. These would not be legislated or enforced. The Standard NIDs would represent a small number of namespaces for which the marketplace has decided success. These would be built for real name space requirements and used in the Internet context. These would require an RFC to document the space and some entities will wish to document their requirements more closely than others, but there should be enough documentation for resolution. Both the name space and the name space ID are specifically registered.

For the Top-level (TL) the proposal is for a hierarchical structure with the TL reserved allowing sub-delegation. A rough cut at the TL is the RFC 1766 country codes. This allows a country to delegate the NID as it sees fit. We need to make sure that the reserved characters as stated in the syntax RFC are the only ones we need for this hierarchical scheme. We had a discussion about setting aside a particular structure for the TL name spaces. There was a question about DNS impact, which was really a question about how flat the name space is. We said that these are not volatile structures, but are fairly static which could be cached and replicated. There was some discussion about the structure and we noted that if we used any characters other than A-Z, a-z, 0-9 and - we would be in violation of our own syntax RFC.

Leslie expressed frustration over the fact that only one person had commented on the draft on the mailing list, while the room seemed filled with contentious opinion on the draft. She urged people strongly to be sure to bring their thoughts up on the mailing list, where official group discussion takes place.

The discussion about how to register name spaces fell down the proverbial vanity name space well. The first part of the discussion concentrated on the process. The suggestion was that the process be analogous to mime-type registration a la RFC 2048. That is, all NIDs would register with the IANA but Experimental types. Informal would have and NID assigned. Standard and TL would require an RFC-publication for documentation. There was then a discussion about the problems with conflict and conflict resolution at the Informal level. What if there were duplicates? The suggestion was that we use OIDs and dashes, not dots. Keith Moore claimed this was too complex, that we need real NIDs with vetting and attainable ones, that they need to be very lightweight and are assigned, not requested. This would need a lightweight process that is just number assignment. This position is based on 2 things: the names have to fit the rules; and they have to be unique. He argued for decoupling the assignment of IDs with whether or not they go in registries -- what an entity does internally doesn't matter. Other comments included: if they want to collaborate and not clash they should use Informal NIDs. Very well known spaces should use TLs and vetting. Standard and top-level may be combined. We might go to Internal, Public and Private.

This led to the (sigh) discussion about vanity names. We need to reduce the number of these to special standard ones. We may need to not use OIDs and IANA hands out a 15 or 32-digit number (or alphanumeric) which would not prejudice any particular resolution scheme. However, we need some motivation for going formal. We need implementation experience with managing the name space. To take this discussion back to the original examples used, ISBNs or SICI codes would be standard; FINBNs would be a assigned by the Finnish TL. A Big Corporation would use Informal; Social Security numbers would be TL/country specific, and US social security numbers are Top-level country. We had a contentious discussion which looked like Munich. Keith suggested that we need to pick solutions that fit the URN requirements. How should they be distinguishable in the RDS? What is the impact and reliability of the level of service? How is a lab different from being WWW accessible? All this needs to be well documented and described.

Properties and characteristics of the namespace should all be changeable so they should not be embedded in the name. Remember - who needs to know and when do they need to know? Are 3 classes reasonable? Is renaming reasonable? This is a registry issue and wrapping a quality issue around it is probably a problem. We need to deal (still!) with the vanity name spaces as a public process. Some should be "very well documented" and not just assigned numbers.

We need to have some consensus here - is a structure allowed in NIDs? The document assumed yes it is, but we really don't know. Experimental may be noted but the structure is left to the name space owner. With a registry we need to revisit the entire area, but we shouldn't make assumptions. We actually have 2 design choices:

1. Assign numbers with technical criteria.
2. Pick the hard choice (allow vanity spaces).

This discussion was referred to the mailing list.

We then went over the documents that were mandated by our charter:

The Biblio IDs - show how grandfathering an existing space would work. The architecture draft, as the working group chair reminded the AD needs resolution. The IETF name space draft may be superceded by PDIs. NAPTR needs a document to explain how to get a namespace and how it gets resolution.

John Mallery gave a presentation on PDIs. The White House is using these in conjunction with thttp to name documents and get resolution. The most contentious issue was that they used the "|" and this was not on the list of OK characters. Ryan suggested using "$". Check the draft for all relevant information, including the BNF draft-mallery-urn-pdi-00.txt.

PDI may take the place of ietf as a new namespace showcase example. PDI needs to coordinate with the http extensions group.

Clearly, we're not wrapped up yet, although the Chair expressed the hope and expectation that fruitful work on the mailing list could yield the necessary remaining components before the next IETF meeting.


None Received

Attendees List

go to list

Previous PageNext Page