Minutes of the URN Working Group 40th IETF Washington D.C. December 11, 1997 Session Chair: Leslie Daigle Minutes: 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: Experimental Informal Standard 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 specificially 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 which 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 to these to special standard ones. We may need to not use OIDs and IANA hands out a 15 or 32 digit number (or alpha-numeric) 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 which 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? Is 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 refferred to te mailing list. We then went over the documents which 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 info, 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.