NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Leslie Daigle <leslie@bunyip.com>
John Curran <jcurran@bbn.com>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
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
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.txtGoals and Milestones:
· Resolution of Uniform Resource Identifiers using the Domain Name System
· A Trivial Convention for using HTTP in URN Resolution
· Requirements and a Framework for URN Resolution Systems
· Namespace Identifier Requirements for URN Services
· URN Resolution Services
Minutes of the Uniform Resource Names (URN) Working Group
Reported by: Sally Hambridge, Intel
The URN Working Group met and discussed the status of submitted RFCs and drafts. There are three documents which have gone to the IESG: The URN Syntax Draft as Proposed Standard, The NAPTR Document, which has gone as Experimental, and the THTTP Draft, also Experimental. There are also three new drafts and one revised draft, although one "draft" did not make it to the ID editor by the deadline for the Memphis meeting. After discussing all the documents, the group reviewed progress to date on milestones and agreed to a revised set of dates for deliverables. Finally, they agreed to creating a FAQ to document decisions, and to using the RFCs as a new namespace (pending IESG approval).
Leslie opened the meeting by reviewing the status of the charter. We have not met all the milestones although we have made substantial progress. The group has three documents which have gone to the IESG: The URN Syntax has gone as a Proposed Standard, the NAPTR Document has gone as an Experimental Document, and the THTTP Document has also gone as an Experimental Document. The group has three new drafts and one revised draft. There are relatively few things left as milestones that we have to produce so it is conceivable that Munich might be our last meeting.
Karen Sollins presented the Framework and Requirements Document and began by talking about the Security requirements. She has added some paragraphs on potential threats and how to deal with them in the framework (not mechanisms to deal with them). She noted that there was clarification needed about the words "authoritative" which could mean it must be possible to have a version by a person authorized to write it, or there must be a certified version. Both should be possible. She also noted that "access control" could mean access for read only, for read and modify, and for read with verification. There also needs to be a means for certification without passing the original record.
Leslie wondered if the draft should really be called a "Requirements" Document when we would not be able to see far enough into the future to be able to state categorically what needs to be a requirement. John Curran thought the draft was much better than previous versions as one could easily relate paragraphs to requirements, but he too felt uneasy with the word "requirements." After much discussion, we agreed (ROUGH CONSENSUS - FAQ maintainer take note) that the document should proceed but needs to be called Guidelines or Considerations for an RDS rather than Requirements. Karen felt that ubiquity and scalability are requirements (or considerations) which are still missing from the document, and urged us to take up discussion of these issues on the list.
John Curran said that in the future, after we have operational experience, we (not in the lifespan of this working group) need to produce a crisp requirements document and that Karen's doc would continue to proceed as informational.
Michael Mealling spoke to the URN Resolution Services Draft. He said he had drawn most of the content from the THTTP draft. He felt that the scope of the document is larger than the working group charter, since it encompasses other URI services. Karen suggested he needs to be clearer that he is not talking about a global RDS but about local resolution services. The draft also needs a section on security considerations, and on error processing. John C. pointed out that Text/URI is not registered as yet, and Ron Daniel admitted he needed to do that. Karen S. said she is not happy with the example and that we need to be clearer about "today's weather" and "a weather map for April 10, 1997" which are two separate things that might have a point in time of overlap. Michael agreed that a concept of equality which is time-based needs to be clarified.
Finally, we agreed (ROUGH CONSENSUS) that the Draft needs to be called URI Services Necessary for URN Resolution Services and that it could proceed as either Informational or Experimental. Again, a standards-track document will be revisited after operational experience has been gained.
Cliff Lynch presented the ID that is not quite an ID. It had been posted to the list, but in a format that was not friendly for all mailers and needed to be re-posted. Since the URN syntax has been established, this draft explored how ISBNs and ISSNs as well as Serial Item and Contribution Identifier Strings might map to URN. There are no particular syntax problems although some %HH encoding is required. This document is useful for showing how resolution will work in practice. ISSNs will probably take the user to a navigation apparatus because they represent an ongoing publication. The apparatus will lead the user to a way to search/browse the serial desired. The group made clear that this document showed how the bibliographic area mapped into the URN name space. Ron pointed out a caveat that we hadn't talked about which standard's bodies have control over, the ISBN and ISSN space. Cliff assured him there is weasel language in the draft over this issue.
Patrik Faltstrom presented the Namespace Requirements Draft. This draft is problematic because in trying to define the requirements for registering of a name space, one fell into operational requirements for the registration process. There has been some violent disagreement about what should be in the document and Patrik and his co-author Renato (not able to be present at the meeting) do not seem to be in agreement. Patrik thought it should deal with grandfathering in existing name spaces. Renato thought it should be about the registration process. John C. suggested we decide who the consumer of the document should be. He suggested we presume it is IANA, and that we should think about what IANA would need from the document. We decided (ROUGH CONSENSUS) that the document needs to go forward as a non-judgmental checklist. This led to a discussion about the problems of having a checklist that avoided operations issues, and the problems of assigning names. Michael Mealling mentioned that he needs some arbiter for this problem, and Leslie suggested he refer current name registration problems to the URN Working Group. Leslie acknowledged that we have problems with assigning name spaces: Is it a name space, Should someone have the name? What happens when "you" say "no"? We are just NOT ready to address the "Can you have it" problem, and will focus for now on the technical issues of evaluation whether something COULD be a namespace.
We spoke for quite a while on the problems of registering name spaces and discovered areas where there be dragons. There seems to be large dragons where ownership is unclear.
III. Summary for Existing Drafts
Requirements and Framework - will go through another round of editing, and continue on its way as informational with a change in focus from "requirements" to "Considerations and Guidelines."
URN Resolution Services: Will go forward as FYI as the "List of URI Services needed by URNS."
Bibliographic IDs - Is OK as a proof of the concept. Will go quickly to last call as informational after reposting to the list in a format readable by all.
Namespace Requirements - Will describe technical considerations of a namespace, not "Can you have it" issues.
We decided we need a glossary that would define terms that span all the documents. Dirk-Willem Van Gulik volunteered to be the glossary editor, and thought he could have a version that would be put on the web page by July 1997.
Ryan Moats presented an Experimental URN Namespace, in which he took RFC's as the data. The experiment is intended to help gain experience and insight into the namespace registration process and issues.
- <nss> := <family> ":" <number>
- <family> := "rfc" | "std" | "fyi"
Resolution functionality is currently: N2L, N2Ls, N2R, N2Rs, and N2C
Introductory URL Page: http://dsm0.ds.internic.net/urn
URL for testing: http://dsm0.ds.internic.net:8080/urn-res/<function>>?<urn>
Michael said he will try NAPTR today as well.
Following on to Dan Connolly's suggestion on the mailing list, the group then decided that decisions of the group need to be captured somehow, so we do not have to constantly revisit decisions. We decided (ROUCH CONSENSUS) to create a FAQ tat could be posted to the list periodically. Leslie will write the first iteration of the FAQ. One of the first things to be documented will be the decision surrounding the use of urn:
There is a new URL syntax draft (draft-*-fielding---.04.txt) which has ONE paragraph which says that URL syntax is for all URIs. We will approach the editors and ask them to change it. We need to demonstrate the lack of consensus from the URN working group that the URL syntax draft applied to URNs. There is very good work in the draft about relative URLs.
We then reviewed the milestones and decided that the only work that is absent is work on a new namespace. We elected to use Ryan Moats’ experiment with the RFCs pending approval from the IESG. The new milestones are:
Submit revised grandfather Namespace Document as Internet-Draft.
Submit revised N2L/N2R/etc document as an Internet-Draft.
Submit revised Namespace Requirements Document as an Internet-Draft.
Submit document describing one (new) namespace as an Internet-Draft.
Submit Framework (Guidelines) Document to IESG for publication as an RFC.
Submit N2L/N2R/etc document to IESG for publication as RFC.
Submit grandfathered namespace paper to IESG for publication as RFC.
Submit revised new Namespace document as Internet-Draft.
Submit new namespace proposal to IESG for publication as RFC.