URI minutes

[Larry Masinter <[e-mail]>]

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, [e-mail])

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, [e-mail])


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.