Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/uri/uri-minutes-95apr.txt

Text File | 1995-05-26 | 19KB | 483 lines

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.,
         <URN: Schemeid:Authorityid:Elementid>
      -  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:

           <URL:http://www.cnri.reston.va.us/home/cstr.html>

     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.

<URL:ftp://ds.internic.net/internet-drafts/draft-ietf-uri-resource-names-03.txt>

     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.