CURRENT_MEETING_REPORT_ Reported by Larry Masinter/Xerox PARC Minutes of the Uniform Resource Identifiers Working Group (URI) The URI Working Group met twice at the Danvers IETF on 3 and 4 April. Thanks to Margaret St. Pierre and Stu Weibel for taking notes in both sessions, and Karen Sollins for contributing notes. Larry Masinter has edited the minutes to merge the notes from the various contributors. Session I The agenda was reviewed and the minutes from the last meeting were accepted. Uniform Resource Agents Leslie Daigle presented Uniform Resource Agents (URAs). URAs are a means of specifying network activities. For more information on URAs, see draft-ietf-uri-ura-00.txt. Briefly, URAs are a means of expressing complex Internet activities. The goal is to capture an object with five parts: 1. Identification and URC. 2. Data elements required. 3. Internet resources required. 4. Definition of find: how does one access things? Scripting. 5. Postprocessing mechanism on results for client of URA. URN Schemes A 10-minute presentation was given to summarize each of the following URN schemes. For more information on each scheme, see the associated URL. o Ron Daniel presented the Schema/Authority/Element URN scheme (draft-ietf-uri-yaurn-00.txt). Key features: - Syntax is the same as Mitra's, e.g., - Each name determines the character set restrictions for the following field. - It uses `DNS' for SchemeID, then a FQDN for AuthorityID. o Michael Shapiro presented the Path URN scheme (draft-ietf-uri-urn-path-00.txt). Key features: - A uniformly hierarchical namespace, dynamically reconfigurable, etc. - Totally separate from hostnames, but has to emulate what DNS is doing now. In the process of walking down the path, it learns about where a server is. - The client chooses the lowest level server; everything below that is served by that server. How is the Path scheme different? - Just one of many naming schemes - each with different semantics - Hierarchical vs. flat - Dynamically configurable - servers can move independent of names - Implemented on top of existing DNS and HTTP Does the Path scheme meet the URN Requirements? - Global scope -- yes. Root is known to all clients. Each node will have a corresponding resolution service. - Global uniqueness -- yes. - Persistence -- as much as any scheme could be. Names live forever. Naming authorities can disappear. Path naming authorities/resolvers are responsible for their children. - Scalability -- yes. Assignment is hierarchically distributed. Resolution is hierarchically distributed. - Legacy Support -- sort of. - Extensibility -- sort of. Use Generic URL syntax for other URN schemes. - Independence -- yes. Name authority only constrained by the syntax and encoding rules. - Resolution -- yes. Path-->URL, or Path-->URC, or Path-->object, all permitted (by HTTP). Scalable resolution because it is publicly hierarchical. Frequently Asked Questions: - Are we using existing DNS hostnames? No. - How will this impact DNS? * Load on local and remote nameservers and caches. Nameservers -- O(1) hit per node Caches -- larger (due to TXT and more activity) -- unknown. Needs study. * Administration A few new rules. Initially more work, but not much after that. - What happens when a Path naming authority or resolver goes out of business? The parent is responsible to take over or redelegate. In the discussion, some controversies arose about the use of DNS or the recreation of name resolution services. There was also a question about whether the correct algorithm is to walk up the tree or down; they think that top-down walking will allow them to take advantage of caching. o Bill Arms presented the Handle service. This is described in: This effort is happening independently of the IETF; it comes from the CNRI global digital library. It is a pure naming system; no URC or meta-information is returned. The syntax is very similar to other schemes: naming_authority/string (where string can be flat or hierarchical). Any naming authority can name subauthorities. A global authority provides global naming. For resolution it makes no use of any structure in handle; they intend to have global and local resolution and caching. When you send a handle to a handle server, you get back everything stored with it. They are building a handle server mechanism with global servers and caching, and talking with NCSA about embedding the resolution mechanism in web clients. Use hash to map to a global server. Discussion brought up a question of aging; what happens when the cache is out of date? This is more of a problem for local servers. o Keith Moore gave a quick refresher about LIFNs, used to name a particular version of a file. They expect that location and file servers are not co-located. It can have a small number of location servers and lots of file servers. It comfortably deals with file server or communication failures because all locations have mirrors of files. o Mitra, Michael Mealling and Chris Weider spoke about the ``General'' syntax. It is fast, implementable and based on current technology. They want it to be ``the'' scheme, because a single mechanism is needed that it is trivial to implement in clients, or, by using proxies, client builders do not need to do anything. The important design goal was the need to do de-resolution in around one second. Discussion of the URN Schemes The remainder of Session 1 was devoted to discussion of the presentations, with a chance to ask any of the presenters questions on their proposed URN schemes. The following issues were raised, and a number of (sometimes contradictory) points were raised on each of these issues, as described below. o Should one protocol or multiple protocols be used (e.g., WHOIS++ and HTTP)? - A single protocol approach would make it possible for client software not to have to change to support all protocols. - A single protocol would permit wider adoption. - A security model that would support multiple protocols may be difficult to achieve, although may not be a problem with a security scheme such as SSL. o Will the URN schemes be able to scale up to over one million publishers on the network and how will administration of such a large number of URNs be handled? Each scheme scales in terms of name definition, but persistence of name management. What does one do for resolution of names for naming authorities that have gone out of business? Problem of scale is resolution. Handle scheme -- there is a problem of global updates, but need to register authorities, not actually objects. - Scaling: Name assignment separated from name resolution -- different numbers. - A global server may have problems updating if the number of URNs doubles each year. - The solution to this problem depends on how many URNs are registered globally versus locally. - URNs have to be globally resolvable. - Locality of reference cannot be assumed on the Web, e.g., in Norway, most references are to local organizations or to the US. - The URI group should look into making use of the work the DNS group is doing to handle administration and namespace issues. DNS will not scale. If it is decided to make a barrier to users that cannot define names without going to the DNS administrator, this should not be done without talking with DNS folks about revising to do much greater scaling. - Use DNS name as the registration authority, e.g., the resolver for gatech would be uri.gatech.edu. - Not all URLs will have a corresponding URN. There are not going to be that many ``published'' documents that need to be cataloged for the long term, and thus the number of URNs assigned will not be a major problem. - The URN scheme should be built to handle the assumption that everyone will want to author, and that publishers should ensure that URNs stay around for the long term. - Name assignment is separate from the name resolution scheme, and should be solved separately. - People would be willing to wait for name resolution. - People would not be willing to wait for name resolution; name resolution should occur with less than a one-second retrieval time. o How is payment for these schemes handled? - A hierarchical URN scheme is attractive because billing can be done locally. - Sometimes archivers will pay, while in some cases people will pay for their own. - For the present for DNS, if pay for DNS naming then pay and otherwise not. Someone asked if LIFNs are dependent on using something that will never hash to same ID? Keith responded that no, any form of hash function can be used. Security comes from file servers, not names. Peter Deutsch raised the issue of one protocol vs. many protocols. Many folks responded that more than one will need to be dealt with, but recommended shooting for one now. The key thing is that clients may only have a single hook. Using a proxy scheme may solve the problem. Mitra urged that we need a single scheme and protocol or will lose. We are really just talking about interface definition. Keith claimed we need to define a single protocol on the wire. It was asked if proxy servers that can speak multiple protocols should be used. A security question is, will one be willing to run resolutions at firewalls? Session II Relative URLs -- Roy Fielding draft-ietf-uri-relative-url-06.txt The draft was declared complete without objections, and will be submitted to the IESG for Last Call before becoming a standards track RFC. Z39.50 URL Status Report -- John Kunze draft-ietf-ietf-uri-url-irp-02.txt The ZIG mailing list has raised enough questions on this that the author is not ready to propose adoption. The URI list is asked for any comments on the draft. Relative URL Draft There were no more comments. The document will be submitted for IESG Last Call unless anyone has anything else to say. Finger, Mailserver URL Scheme Extension Mechanism draft-ietf-uri-url-finger-02.txt draft-ietf-uri-url-mailserver-01.txt There were no comments on either document. Both will be submitted for IESG Last Call and moved to the standards track. Issue: How will such extensions be vetted in the future? The working group is now reviewing extensions (three so far). In future months, someone must edit the revision of the URL draft and decide how extensions will be done in the future. No one present at the meeting volunteered to adopt these responsibilities, though there was recognition that it is necessary and important. A stronger mechanism is needed than saying that IANA will do it. Can we use the MIB mechanism? MIME type people also do this. For MIBs, all work goes through the working group. For MIME types, work is done by posting and discussing on a mailing list. A process needs to be set up for when the working group no longer exists. There was a suggestion of an intelligent assistant editor for IANA. Someone will be needed in the next few months to revise the URL document. URC Scenarios and Requirements -- Ron Daniel and Michael Mealling The authors are seeking feedback concerning the minor modifications made to the document (Daniels, Mealling). The group deferred discussion on this issue in order to get back to the URN discussion. The syntax discussion was shut down last time in order for implementation. Currently, multiple query languages should always be supported. By next time, the goal is to have running code and revisions of the document. The hope is to have it close to Last Call next time. Ron wants to make sure that people understand that there is not just one URC. There may be one default one. No required attributes. There is a question of whether there should be a single data model or more than one. Continued Discussion of the URN Schemes The remainder of the session was given over to continued discussion of the five URN schemes and associated issues. The following assertions or comments reflect the sense of the discussion: o It is time for a new namespace/resolution system - the existing DNS is fragile and flawed; extending these flaws into the URN arena will propagate these flaws (e.g., flatness of .com space) o URNs will not, of themselves, solve the problem of persistence of OBJECTs -- only persistence of names. Schemes need not assure persistence of objects, but some thought should be given to assure that the problem is not exacerbated by the scheme. o Most of the URN schemes do not really go into detail about what happens when something moves. So far they have dealt only with what happens when a whole organization moves. Granularity of mobility must be addressed. For example: - All Web documents from CERN move to INRIA, but high-energy physics documents stay at CERN. What happens to URNs for the web documents? - A student graduates but someone wants to retain editorial control of one of his pages. How can this happen? - A university retains all articles by staff members; someone on the staff publishes the exact document in an on-line journal. Does it get a new URN, or just keep the old one? o There are two different requirements: (1) URNs be resolvable quickly and (2) URNs last a long time. However, there is no requirement that URNs should be resolvable quickly for the foreseeable future. That is, over time, as the number of resources grow and items migrate from one location to another, we do not have to design for efficient access in the future. o DNS does not guarantee uniqueness in time; however, it is possible to add some limited time stamp (e.g., DNS name plus year, or DNS name plus year and month.) This gives uniqueness over time without adding a full 32-bit timestamp. In general, qualification of a name space with time stamp (possibly low resolution; year or year-month) will help make the inclusion of human readable information in URNs more accessible to long term interpretation. o Claim: We should always go to URC in order to find URL. It should be possible to modify a set of URLs in a URC. There is an issue of finding all copies of the URC -- this is tied to a publisher being responsible for the default URC for all time. o Proposal: In the near term, the agent that handed out the name will do resolution, but we quickly will need an alternate solution. This suggests that all moves are handled based on naming authority or subauthority. o Solutions to DNS problems should be identified and advantage should be taken of the existing investment in technology and administrative infrastructure -- do not confuse architecture (sound) with implementation (currently weak). Join the DNS Working Group if you think you can invent a better namespace; anyone who thinks this can be done probably does not understand the problems. o One or several URN schemes? There may be a call for several, some tailored to specific aspects of the problem set. For example, LIFNs do not solve all the problems of the URN domain, but might be very useful as a guarantee of version identity (imagine wanting to assure a JAVA applet version or identity). o Name Resolution: Should it be to a location (URL) or to a URC? o There is a need for a private part of the name space (spook.gov, snidely.com, privacy.edu, for example, will need mechanisms for assuring security). o Are we trying to solve NIDR with permanent names? Names should last as long as the issuing agency -- go to a permanent naming authority if you want your stuff to last. o Names with human-readable components (built in semantics) are intrinsically less persistent than those made of opaque strings (OIDs, ISBNs, etc.). o Schemes must be maintainable over time frames of hundreds of years to achieve acceptance as identifiers of important cultural records by research libraries. o Some assert that semantics should be kept out of the name space mechanism. Others assert that semantics may be included, but only as convenience; they should be ignorable (processable as content free tokens). Hierarchical resolution cannot be done with acceptable resolution times (sub-second responses). Overloading names with semantics is necessary to achieve low resolution times (sub-one-second). o Some assert that it is time to decide on a syntax and character set so experimental work can go forward. On the other hand, we must agree on the semantics before we do a syntax. o A URN Scheme Bake-Off is proposed for the Stockholm (or failing that, the Dallas IETF). - Set ground rules by 20 April. - Report preliminary results by Stockholm. - Argue results in Dallas. Preliminary ground-rules: - Use URL requirements and syntax for URNs (e.g., no spaces), scheme:scheme-specific-part. - Invent new URL-`scheme' to describe your URNs, but do not use `urn:'. - Explain how the scheme meets URN requirements. - Describe behavior and performance in the use scenarios, especially when resources have moved. Chris Weider, Larry Masinter, and Tim Berners-Lee are nominated to establish ground rules (having spoken up about them in the meeting), though comment and proposals from others are welcome. Theoretical models of performance, though suspect, may also help to shed light or point in the direction of further experimentation.