Minutes of the URN Working Group 39th IETF Munich Germany August 7, 1997 Session Chair: Leslie Daigle Minutes: 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 honoured for a short presentation/ discussion of CNRI's Handle System. o 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 emphazised 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 legecy 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 standarized 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 which has an authority on the names. - Each name space then propably 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 interrupt and add 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 resoution 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 state 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 to firmly split authority for assignment and resoution. However there seems to a strong voice to insist on at least one registry and one resolution service for a 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 requirments 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 a 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 requirment 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 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 aditional resolution services). It is stressd that the authority who assigns the identifiers is not nessesarily the owner of the space. The first is easy to identify, the latter is often not. It is debated wether publishing the name assignment and/or resolution mechanics in an RFC is a usefull requirment 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/(?) conclude 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. Handle Presentation Sam Sun from CNRI is given some time to present the Handle system; see http://www.hanlde.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 contraints.