NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
John Curran <jcurran@bbn.com>
Leslie Daigle <leslie@bunyip.com>
Applications Area Director(s):
Keith Moore <moore+iesg@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:
· A Framework for the Assignment and Resolution of Uniform Resource Names <draft-daigle-urnframework-00.txt
· Resolution of Uniform Resource Identifiers using the Domain Name System <draft-daniel-naptr-01.txt
· 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. |
Internet-Drafts:
· Architectural Principles of Uniform Resource Name Resolution
· Namespace Identifier Requirements for URN Services
· URI Resolution Services Necessary for URN Resolution
· Using Existing Bibliographic Identifiers as Uniform Resource Names
· URN Syntax
· A URN Namespace for IETF Documents
Request For Comments:
RFC |
Status |
Title |
RFC2141 |
PS |
URN Syntax |
RFC2168 |
E |
Resolution of Uniform Resource Identifiers using the Domain Name System |
RFC2169 |
E |
A Trivial Convention for using HTTP in URN Resolution |
Minutes of the URN Working Group
Session Chair: Leslie Daigle
Reported by: Dirk-Willem van Gulik
Leslie:
Agenda: A number of documents (outstanding ID's plus those currently prepared by Patrik/Renato on the namespace ID) and their open issues are to be discussed. Plus, there is a request honored for a short presentation/discussion of CNRI's Handle System.
I. Documents on the Table
Currently the intent is for two informational and one experimental RFC to be produced. The URI-Resolution services document is to go into the experimental track and the two background documents (about the architecture and the "IETF" URN namespace) are to have an informational status.
Within these documents a number of open issues are identified; with the details and process for handling of new URN name spaces requests as the main issue. It is emphasized that the IANA part is to be a largely mechanical process, i.e., firm, technical rules, and no interpretation.
Ted Hardie adds that user friendly name spaces are not to be an issue; although Karen Sollins adds that retrofitted legacy namespaces might be relatively friendly. The pitfalls are well known; and grim tales of the tld-wars and their free for all/first-come-first-serve procedure are related.
It is pointed out that IANA currently assigns names based on procedures described in informational RFC's; i.e., such a document does not need to be a full blown standards track document.
So in short, the proposed to-be-created namespace procedural document needs to distinguish between:
· IETF-based standardized namespaces and
· Experimental/private namespaces (which are registered to avoid collisions and permit global use as desired) with:
- assigned names/numbers for non-standardized name space
- _technical_ guidelines for namespaces of all descriptions
- need mechanical rules for registration
Within this framework Patrik Faltstrom (who works on this with Renato Iannella) points out in a short presentation that:
· Vanity names and numbers are a problem.
· A Namespace is to be defined as something that has an authority on the names.
· Each name space then probably has a number of (well-defined and specific) related services for registration and resolution of the urns.
· The hard part is to determine for a given name space
· Who can be responsible?
· Stability. What happens when the organization goes away?
· Is a resolution service also authoritative?
This last point of Patrik's raises a discussion (largely based on examples from the RFC space; created by Ryan Moats but under the flag of the IANA, with questions like: Is the entity creating the name space (or the entity authoritative on the name space) also responsible for resolution? And/or automatically authoritative for the resolution? Where does the authority begin and end?
The above presentation is cut short; Leslie's summary, there are two levels, with different roles and functions (standards-track and experimental/private). Dirk/Karen interrupted and added that one cannot impose all that much; some names might never (fully) resolve or not even resolve authoritatively; privacy, quality, approval, issues etc. Patrik/Dirk focus on the fact that the approval is only into one direction; i.e., there can be competitive resolution services for the same name space; for example ISBN resolution currently offered by various third parties; even though the first party is not offering such a service. This translates into a requirement for the name space creation document where the above mechanics must lead to a rule for a particular name space with regards to the relation between the naming authority, the name and its resolution in, possibly, both directions. Ted/Leslie stated that (most) namespaces will not allow for authoritative resolution without explicit consent/cooperation from the naming authority. This and the one-way direction argument seem to be understood as an important part of any namespace by most participants. This leads to the name space ownership issues; with related issues such as can one believe someone who claims to be authoritative on a resolution; which claims should one believe (and if self-asserted claims are valid). The tendency seems to be firmly split authority for assignment and resolution. However, there seems to a strong voice to insist on at least one registry and one resolution service for an acceptable name space. This resolution service might not be authoritative though. Also, one should not try to avoid/solve the problem of having many names for one object.
Patrik wants to focus on just the requirements for registering the namespace without any reference to resolution; Michael Mealling/Leslie and Keith counter/add requirements instead for the actual registered namespace (and resolution); such as multiple resolvers, conflicts between resolvers, authoritative resolvers. And do most certainly want to consider issues with grandfathering in schemes.
As a sideline, what to do with existing legacy schemes, such as ISBN, and more particular, who can claim to be the 'owner' of them. A concrete example is Ryan; can he register the 'rfc' space; or does he need the explicit consent of the IANA/IAB/IESG or Jon Postel. If he needs such consent, is a self-claimed one good enough as the (legal) mechanics to verify are daunting/not realistic according to some. Some people translate this into an extra requirement for the name space registration procedure to allow for many to many relations in both registration and resolution of the actual URNs for what are essentially the same objects.
This leads to the question "what" one gets when one asks for a name space; just a prefix; or also responsibility and the duty to assign and manage the space it self and/or the duty to assign (or perhaps even manage) the resolver assignment and/or authoritative resolvers.
The consensus seems to be that a namespace is limited to just a prefix, responsibility to manage the name space and the responsibility to manage (authoritative?) resolver assignment. The latter might translate into a requirement for the document; the scope of a name space, and what a name can be resolved into under auspices of the naming authority should be clear from the outset. (Though third parties might provide additional resolution services).
It is stressed that the authority who assigns the identifiers is not necessarily the owner of the space. The first is easy to identify; the latter is often not.
It is debated whether publishing the name assignment and/or resolution mechanics in an RFC is a useful requirement or pre-requisite for creating a name space (and perhaps use the RFC number as the name space identifier).
It is countered that the assignment/structure of a name space might be far away from the resolution mechanics; and syntaxes can be too opaque to make such documents realistic. But in general, it seems that any reasonable hurdle on the road to obtaining a namespace is welcomed.
The issue of sub delegation and the specification of any mechanics in the namespace-establishing document is brought to attention.
Michael/(?) concluded that we need more experience; and waiting to see how the RFC space develops might be worth the wait. Although the URL prefixes offer an example on how not to do things, as it does not work well according to Keith.
Michael points out that he, or his employer (NSI) do NOT OWN the urn.net domain or any database of NSI attached to it.
II. Handle Presentation
Sam Sun from CNRI is given some time to present the Handle system; see http://www.handle.net. Handles look like they might make a fine URN namespace.
Discussion does escalate into the usual discussion on the syntax limitations of URN's imposed by the URI specification. Sam is referred to the archive of the URN discussion list for previous iterations of the syntax issues. Our dear area director cuts this short and advises those who have issue with the URI spec to discuss that in the appropriate places; the URN work is to be done within the URI constraints.
None Received