To: email@example.com Subject: URI minutes From: Larry Masinter <firstname.lastname@example.org> Message-Id: <95Apr9.email@example.com> Date: Sun, 9 Apr 1995 09:56:39 PDT Attached are the first draft of the minutes Margaret St. Pierre and Stu Weibel. If you have additional notes from the meeting, please send them. There are some phrases in the minutes so far that are not complete sentences; if anyone would care to offer a disambiguation, it would be much appreciated. For those who spoke with slides (Leslie, Ron, Michael, etc.), please send me (a pointer to) your slides or a summary of them, for inclusion in the official minutes. -------------------------------------------------------------------------- Minutes of Uniform Resources Identifiers Working Group, April 3 & 4, 1995. Session I (minutes by Margaret St. Pierre, firstname.lastname@example.org) 1. Reviewed of agenda, accept minutes from last meeting. 2. Leslie Daigle gave a presentation on URAs (Uniform Resource Agents). URAs are a means of specifying network activities. For more information on URAs, see: <URL:ftp://ds.internic.net/internet-drafts/draft-ietf-uri-ura-00.txt> 3. URN-Fest: A 10-minute presentation was given to summarize each of the URN schemes given below. For more information on each scheme, see the associated URL. Schema/Authority/Element Speaker: Ron Daniel <URL:ftp://ds.internic.net/internet-drafts/draft-ietf-uri-yaurn-00.txt> Path Speaker: Michael Shapiro <URL:ftp://ds.internic.net/internet-drafts/draft-ietf-uri-urn-path-00.txt> Handle Speaker: Bill Arms <URL:http://www.cnri.reston.va.us/home/cstr.html> LIFN (Location Independent File Name) Speaker: Keith Moore URL = ? General Syntax Speaker: Mitra (Michael Mealling/Chris Weider) <URL:ftp://ds.internic.net/internet-drafts/draft-ietf-uri-resource-names-03. txt> 4. 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: Issue: 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. Issue: Will the URN schemes be able to scale up to over one million publishers on the net, and how will administration of such a large number of URNs be handled? - 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. - The URI group should look into making use of the work the DNS group is doing to handle administration and namespace issues. - 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 URN's 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. Issue: How is payment for these schemes handled? - A hierarchical URN scheme is attractive because billing can be done locally. ------------------------------------------------------------------- Session II, 1300-1500 (minutes by Stuart Weibel, email@example.com) 1. Reltive URLs: Roy Fielding draft-ietf-uri-relative url-06.txt The draft was declared complete without objections, and will be submitted to IESG for 'last call' before becoming standards track RFC. 2. 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 isn't ready to propose adoption. The URI list is asked for any comments on the draft, however. 3. Finger, Mailserver URL-scheme extension mechanism draft-ietf-uri-url-finger-02.txt draft-ietf-uri-url-mailserver-01.txt No comments on either... both can be submitted for last call and proposed as Draft Standard. ISSUE: How will such extensions be vetted in the future? The working group is now reviewing extensions (3 so far)... in future months, someone must edit revision of URL draft, and decide how extensions will be done in future. No one present at the meeting volunteered to adopt these responsibilities, though there was recognition that it is necessary and important. 4. URC Scenarios and Requirements Ron Daniel and M Mealling The authors are seeking feedback concerning the minor modifications made to the document (Daniels, Mealling). We deferred discussion on this issue in order to get back to the URN discussion. 5. Remainder of the session (about 75 minutes) were given over to continued discussion of the 5 URL schemes and associated issues. The following assertions or comments reflect the sense of the discussion; It is time for a new namespace/resolution system - existing DNS is fragile and flawed; extending these flaws into the URN arena will propagate these flaws (eg.: flatness of .com space) We should identify solutions to DNS problems and take advantage of the existing investment in technology and administrative infrastructure... do not confuse architecture (sound) with implementation (currently weak) 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. What happens when something moves? (Review of the 'scenarios' questions mailed by masinter to the WG mailing list). examples: All web documents from CERN move to INRIA, but high-energy physics documents stay at CERN. What happens to URNs? Grad-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 online journal. Does it get a new URN, or just keep the old one? One or several URN schemes? There may be call for several, some tailored to specific aspects of the problem set. eg: 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). Name Resolution: Should it be to a location (URL) or to a URC? There is a need for a private part of the name space; (spook.gov, snidely.com, privacy.edu, for eg., will need mechanisms for assuring security) 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 Names with human-readable components (built in semantics) are intrinsically less persistent than those made of opaque strings (OIDs, ISBNs, etc.) Schemes must be maintainable over time frames of hundreds of years to achieve acceptance as identifiers of important cultural records by research libraries Qualification of a name space with time stamp (possibly low resolution; year or year-month) will help make the inclusion of human readable info in URNs more accessible to long term interpretation. Semantics should be kept out of the name space mechanism Semantics may be included, but only as convenience; they should be ignorable (processable as content free tokens). Join the DNS WG if you think you can invent a better namespace; anyone who thinks this can be done probably doesn't understand the problems. 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). The new scheme entries should formally apply the URN requirements document to their schemes. It's time to decide on a syntax and character set so experimental work can go forward. We must agree on the semantics before we do a syntax A URN Scheme Bake Off is proposed for the Stockholm (or failing that, the Dallas IETF). Set ground rules by 20th of April Report preliminary results by Stockholm Argue results in Dallas 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.