Editor's note: These minutes have not been edited. Minutes of the URN Working Group 37th IETF, San Jose, December 12, 1996 Group Co-Chairs: Leslie Daigle, leslie@bunyip.com John Curran, jcurran@bbn.com Minute-Meister: Sally Hambridge, Intel Leslie opened the meeting by reviewing the Charter and Milestones. Hot Spots in the milestones are: we lack a draft detailing N2L/N2R/etc resolution results. We will probably use Ron Daniel's HTTP conventions draft as a start on this milestone. We also need to submit a document describing one new namespace and a document which describes grandfathering in older naming schemes, as well as the Frameworks and Requirements draft. Karen Sollins presented the open issues with the current Frameworks and Requirements document: The document discusses the assumptions of longevity, delegation, and independence. The requirements fall in 3 major areas: Evolution, Usability, and Security. The framework looks like this: URN: | | Global NID registry | | | | | Private URN resolution service UDS server | | Private URN resolution service Karen includes a definition section which defines Local Resolution service - what transforms URNs into access to resources; Hints - information that helps to access the information; UDS - URN Resolution Service Discovery Service - how to find the right URN resolution service; HFN - Human friendly names. The Security area will discuss access control on hints; server authenticity; Server distribution (a countermeasure on denial of service attacks) and Privacy - the users from resolution services and for publishers for their clients and publications lists. Issues: - Encouragement of separation of URNs from semantics - Efficiency as a goal or a requirement is in several places (documents) which need to be aggregated. - Whether there is a useful distinction to be made between long- term and short-term hints - Acceptance by potential providers of UDS services. Karen asked what's missing from the list of issues: Internationalization (i18n) should be covered one way or another. Name space ID - needs to be in a document but probably not this document. Ryan Moats presented the issues with the URN syntax ID: URN: should this be optional. Please see the later discussion on this for the consensus. NID syntax: Why not use numbers and "-". No reason - Ryan will change the draft. There was a suggestion for following the RFC for URLs on this, but it was pointed out that this document is currently undergoing a revision. NID namespace will have case insensitivity and add %escaping. The NSS may be case sensitive. URN Character set adds/deletes: Add "%" to the allowed character set and add a list of characters NOT part of the set to the draft. %escaping: Will be allowed for escaping of reserved characters in addition to characters outside the URN character set; and allow for %HH escaping to use either upper or lower case. Where does a URN end? At the first non-URN character set character. Equivalency: Are things the same when they point to the same resource? (Equivalency of resources was deemed to be a rathole). Leslie offered that a URN could point to a specific day's weather and another could refer to today's weather, and these were pointing to the same thing but were not equivalent. ROUGH CONSENSUS was reached that ONLY lexical equivalency will be covered in the draft. Each namespace may have its own rules. For the Human readability - MUST/SHOULD the following text is being substituted: Any namespace (existing or newly-devised) that is proposed as a URN-namespace must be expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set they must be translated into canonical form as discussed in section 2.2 Ron Daniel discussed the NAPTR draft. - There will be verbiage to state that records with unknown flags must be ignored. - The Pseudo-code will get a strong disclaimer. - "R" Flag for treating Regex as "Raw" - Don't do "E" flag for encrypting Raw fields. - Flag field reserves 0-9 for experimentation. ROUGH CONSENSUS was to allow people to create new flags however they want, but that if you see a flag you don't recognize you ignore it. Ron is going to revise the wording of the draft so that people may place any interpretation they want on the various fields as long as they define a flag for it. There was a question of the references to other drafts, and John Curran said he would find out if the text RFC xxx could be written and if the RFC editor would insert the correct numbers. This draft will be going as an Experimental RFC. There was discussion about how the experimental status will effect DNS and the regex substitutions. We need to be explicit. We need to say how this doesn't overload DNS and how DNS security will help and where it won't. Also, there will probably be more than one discover service in the future and we don't want this one to be "The Standard". We need operational experience. The requiring resolution problem is not part of this draft. We will have one more revision on the mailing list, then this goes to Experimental. HTTP Conventions: Ron took this one too. We need a simple resolver for testing, the goal is not Standards track. The goal is to use the conventions on encoding on requests and responses on http: GET /uri-res// HTTP 1.0 Open Discussion: URN: There was a question of rough consensus on the problem of whether to require urn:. The room seems to indicate that urn: should be required on any part of the urn that was shipped around the Internet. Whether or not implementors would use urn: was left up to them for their own local products, but in transmission the urn: would be required. The problem with urn: seems to be at the user interface and user services level. Don't confuse human friendly names with internal representation. Documents: We need a URN dereferencing document to discuss the resolution service and the resolution system. These need the syntax (which is close) and the system requirements needs the framework (which is also close.) Assign URN - needs everything! We need namespace requirements. Renato Iannella was volunteered to create a first draft of this document. We need to have one new namespace and we need to bring in 1 existing namespace. We need to pay some attention to potential lawsuit issue. It is important for someone who has authority for the namespace to say how it works in URN. The proposal is for these to be experimental. Dun and Bradstreet is interested in working on this as soon as the syntax is ready. Clifford Lynch said that the NISO bibliographic IDs could move en masse. We can create a resolution system which can be used outside the URN space, but we need to make it work there first. Charter directions: * We need to get a grip on bringing in an existing namespace * We need a new namespace scheme * We need the Name space requirements document (to see whether DNS-based namespace will or won't work, and if not, what we can do about a generically-accessible namespace) * We need to look at the process of creating new namespaces -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ----------------------------------------------------------------------------