Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/uri/uri-minutes-93nov.txt

Text File | 1994-02-08 | 21KB | 559 lines

CURRENT_MEETING_REPORT_

Reported by Alan Emtage/Bunyip Information Systems

Minutes of the Uniform Resource Identifiers Working Group (URI)

The Uniform Resource Identifiers Working Group held three sessions in
Houston.  Two were scheduled in advance, and the third was scheduled
on-site as an additional session would be necessary to complete the
business of the working group.  These minutes are separated on a
per-session basis.  Our thanks to Craig Summerhill for taking notes.



Session 1

Introductory remarks were made by the co-chairs and the minutes of the
previous meeting were approved.

Erik Huizer, co-Director of the Applications Area, spoke to clarify
certain procedural aspects concerning the running of the working group
as well as to comment on some of the discussions which had occurred on
the mailing list before the Houston meeting.  He made the following
points:


  1. The URI Working Group falls under the joint administration of the
     User Services and Applications Areas of the IESG and as such must
     approach the problems to be solved with both protocol development
     and the user's perspective in mind.

  2. The working group chair has the authority to remind the group that
     certain topics have already been discussed and to direct members to
     the mailing list archives and previous minutes of meetings to
     review the discussion.  However the group may still choose to
     discuss a topic if the issue still exists.

  3. Given the nature of the work, discussions revolving around the
     current installed base, while important, must not be the primary
     focus of the group.  This installed base is very small when
     compared with expected growth in the information systems area.

  4. Rough consensus must be achieved on all documents---this does not,
     however, mean unanimity.  Voting is a gauge and does not
     necessarily determine if consensus has been obtained.

  5. The area directors do not believe that consensus has been reached
     on the current Uniform Resource Locator (URL) document and would
     not approve it if submitted.

  6. The area directors require the group to produce a companion
     document to the current URL draft containing a list of functional
     specifications and requirements.  This document can then be used to
     determine if the current URL draft meets the requirements.  Similar
     documents will be required for all UR* protocol specifications.
     There was some discussion that the working group would be delayed
     by having to produce another document.  However, the co-Area
     Director made it clear that while this document did not have to be
     very long, without it the current URL document would not be
     recommended for approval by the User Services and Applications Area
     Directors for acceptance by the full IESG.
     Jim Fullton agreed to coordinate efforts on the functional
     specification draft.


John Kunze made a presentation describing an earlier meeting of some
members of the working group.  This meeting attempted to iron out some
of the problems currently being discussed on the mailing list.


   o There is a need for URLs in the real world now, even though it
     might be imperfect.

   o A migration path from the current installed base to the form
     adopted by the working group would be necessary.

   o It was suggested that a protocol revision number be included in the
     URL, as well as forthcoming Uniform Resource Name (URN) and Uniform
     Resource Citation (or Characteristics) (URC) specifications.
     URL:1:
     was suggested as the prefix to the URL.

   o It was suggested that the working group only concern itself with
     the URL, URN and URC objects at this time.

   o Get back to basics:

      -  Do not deal with ``relatedness'' of the object being addressed.
      -  Get rid of the character set field in the current URN draft.


   o A document describing the overall architecture of the UR* objects
     in addition to the following information should be produced.

      -  How to register a new ``Naming Authority.''
      -  An appendix with examples of the various UR*s.


   o Proposal for the UR*s

      -  The URL should have the following properties:
          * Used as a pointer for ``de-referencing.''
          * Transient in nature.
          * ``Machine consumable'' (that is ``parsable'').
          * ``Transport friendly'' (that is, visible ASCII string).

      -  The URN should have the following properties:
          * Location-independent names.
          * Persistent name (although the object to which it refers is
            not persistent).
          * Human transcribable.
          * Transport friendly.

      -  The URC should have the following properties:
          * Contain identification (or ``meta'') information.
          * Human and machine consumable.
          * Transport friendly.
          * Provide some mechanism for URL and URN ``caching.''


A general discussion on the functional specifications for the URL
followed using the points set out by John Kunze.  A number of decisions
were made.


   o It is a pointer for ``resolution'' of the URL to the actual object.
     The term ``dereferencing'' is dropped.

   o It is transient in nature and applications may not depend on being
     able to resolve this to the object.

   o It is ``machine consumable.''  ``Parseable'' was also suggested.

   o It is transport friendly (visible ASCII string).  Methods for
     transport need to be defined.  Marshall Rose suggested that the
     phrase ``transportable on common Internet protocols'' be used.

   o Has ``global scope'' (is absolute not relative).

   o URLs may be used to resolve any form of network ``object'' (e.g.,
     Telnet sessions).

   o ``Machine independent.''  Does not depend on the platform trying to
     resolve it.

   o Meta-information issues:

      -  Does not contain meta-information.  There may be cases (e.g.,
         Gopher) in which meta-information is required.  However in
         these cases this should be considered ``access information.''

      -  URL should contain protocol information if it is required to
         locate/access/transfer the object, but the URN should not
         contain protocol information.

   o By taking ``typing'' information out of URLs some other mechanism
     needs to be defined to make the information available.

   o Is it a requirement that a URL is readily identifiable as such
     (rather than as a URN or URC)?

      -  Should there be a prefix?  (e.g., ``URL:'')
      -  Should protocol revision information?
      -  Should there be versioning information after the protocol
         descriptor (e.g., ``ftp:1//...'')?

     By rough consensus (though not unanimity) it was decided that the
     prefix ``URL:'' would be used on the URL specification.  No
     versioning information will be included.

   o There needs to be a way of passing a package of parameters between
     services that returns a specific (predictable) response.

   o As a technique of achieving consensus:  fall back on a few concrete
     scenarios that can be solved today, and a few more that can be
     solved next year (second round).

   o There needs to be some consensus about methods of organizing
     meta-information (especially in multiple IR tools) before consensus
     can be reached.

   o URL should do all that MIME external body references now does.


A discussion of URN!URL mapping reached no agreement.  It was decided
that further discussion was required.


Session 2

Jim Fullton presented a document produced by a number of working group
members after the previous session, setting out the functional
specifications.


   o Locators may be valid only for a short time.  Methods for mapping
     between static identifiers and URLs are beyond the scope of this
     document.

   o Locators are machine consumable.  Clarify that it is parsable.

   o Machines can readily identify locators as such.  Is it a
     requirement that a URL can be removed from its presentation context
     and still be recognizable?  Is it a requirement that they be
     position independent?  Should they be tagged?


      -  It must be possible to recognize a URL as distinguishable from
         URNs and other URIs.

      -  In certain contexts, URLs should be easily extracted from
         running ASCII text.


   o Locators are transport friendly.  URLs must pass unscathed through
     NNTP, SMTP, and other network protocols.

   o Locators contain no meta-information about the resource other than
     the complete set of parameters required to access the resource.

   o Other than the prefix and protocol designators the URL is an opaque
     string to everything other than that protocol.  Unless the
     information is needed to access the resource, the information
     should not be included in the URL.

   o The locator is not intended for users, but the typical locator is
     human readable and is transcribable.

   o The set of services/access methods is extensible.

   o Locators have global scope.  Information for access must be
     absolute, not relative.


Having reached general consensus on the functional specifications, the
group reviewed the current URL document for agreement between the two.

Mitra presented a review of the results of the discussion on the mailing
list before the Houston meeting.  The following points and decisions
were made:


   o Spaces.  In the current draft they are legal but not recommended.
     The group decided that spaces (and other whitespace) failed to meet
     the human transcribable requirement and thus are not allowed.  All
     spaces must be escaped to %20.

   o Some modifications to partial URLs will be considered (changing
     /xxx/..  to xxx/../).  The section on partials is not appropriate
     for the main text of the document and needs to be moved out to an
     appendix.

   o The WAIS length field is not necessary for access and is dropped
     from the WAIS URL.

   o The Prospero URL attribute mechanism will be modified by Mitra.

   o Character sets erroneously omitted the `+' and `=' characters and
     will be put back.

   o Fragments.  Removed from the document at a previous meeting, but
     never got deleted from the document.

   o News URL is more like a URN. It uses the message ID, rather than
     information about such things as NNTP server.  The group decided
     that the ``news'' URL should be removed from the document, and
     replaced with a valid NNTP: URL. Installed base will continue to
     use ``news'' URL until transition can be made.

   o Gopher+ protocol is not included.  The current URL and new
     information at the end.  Mark McCahill, speaking for the Gopher
     group, agreed to take care of this with a new URL type.

   o Gopher type needs to be added back in because it is required for
     access and is thus not considered ``type'' information in this
     context.  Suggestions will be presented on the list for this.

   o FTP requires some form of type information for access (such as
     Binary or ASCII mode) and as such this is access information.  A
     review of MIME was suggested and will be presented to the list.

   o Wrappers.  Do we need them and if so what should they be.  One of
     the functional specifications is that locators be readily
     identified.  Does the URL: prefix suffice?  After discussion and
     for the sake of time, this was postponed to the list.


General consensus was reached as to the agreements on changes to the
current draft.  The author Tim Berners-Lee will be asked to make the
changes.

Discussion on the current URN and URC drafts was started.  Larry
Masinter suggested that this be postponed until functional specification
and requirements documents could be produced.

The functional specifications for the URNs was discussed and the
following points were made:


   o They should provide persistent unique names for resources.
   o They should be able to detect sameness of resources.
   o Should they be used in conjunction with a description for a process
     for mapping or resolving to locators URN!URL?


Session 3

The chair proposed that the session be split into discussions on the
functional specifications for the URN and then on the current URN draft.

Peter Deutsch had some comments on the working group process.


   o We have two groups (IRTF and USRV/APPS) melting into one working
     group, and we have done a great deal of work in the last year.

   o We traditionally do research and development, and we may be doing
     more R&R (research and release).


He then presented functional specifications for URNs as proposed by a
group of working group members.


   o Function statement.  What is the function of the URN? Is it
     persistent name which is globally unique, or is it persistent name
     which is globally unique and also permits resolution of location?

   o It had been agreed that the URN has the the following attributes:

      -  Location independent name
      -  Human transcribable
      -  Transport friendly
      -  Machine consumable


   o The discussion focussed on other necessary attributes of which the
     following were initially suggested:

      -  URNs are globally unique.
      -  They compare uniqueness/sameness.
      -  They are resolvable.
      -  They are permanent.
      -  URNs are scalable/distributably assigned.
      -  The scheme must permit grandfathering of existing naming
         schemes.
      -  They must be extensible.
      -  They may allow caching.


Each attribute was discussed in turn:


   o For the location-independent name attribute, consensus was reached
     on the following points:

      -  Names do not designate or imply location.

      -  No matter where you use you get the same effect (global scope).

      -  Definition:  ``name with global scope that does not imply
         location.''

      -  The naming authority can use an opaque string which has no
         meaning to anyone other than that particular naming authority.

      -  Once it goes past the naming authorities boundaries, it is an
         opaque string.


   o It was agreed that the URN, not being a URL, is an attribute not a
     requirement.

   o Consensus was not reached on the human transcribability attribute
     due to the fact that the character representations could not be
     agreed upon.  The following suggestion were made:

      -  We collapse the human transcribable and machine consumable
         attributes.  No consensus was reached.

      -  Does this mean entered on standard ASCII keyboards?  It did for
         URL. These things might not really be typable.

      -  Should there be a length limitation on these things?

      -  There may need to be a discussion regarding limited character
         set.  No rough consensus was reached.  Discussion on this item
         moved to list.


   o It was discussed whether semantics in the URN should be
     discouraged.  No consensus.

   o The following points met with consensus:

     Transport friendly

      -  One should be able to mail them around, and other common
         protocols (and print) should be possible

      -  Machine parsable

      -  Globally unique

      -  Permanent/persistent

          * The life of the object need not be included in definition

          * URNs may exist beyond life of the object

      -  scalable

          * URNs can be assigned to anything.  We must be able to assign
            a URN to anything on the network.  However, there may be
            practical limits to this.

          * Information universe should be hierarchical

          * The naming authority should be discouraged from, but is
            permitted to, design a naming scheme which is not scalable

          * The URN must have the ability to name a large number of
            objects

      -  permits embedding of existing systems (grandfathering)

      -  extensible


   o No consensus was reached on the issue of uniqueness/sameness
     however the following points were made:

      -  This issue arises of ``intellectual content''

      -  It was agreed that the naming authority makes the decision
         regarding the intellectual content of the document.

      -  If an object is moved out of the domain of the naming
         authority, do we assign a new URN for it?  If we make new
         copies in new formats, do we assign new URN? We need to have
         URN atomically bound into the resource.

     It was agreed that this discussion should be taken to the list

   o The discussion about the URN permitting ``resolution'' made did not
     reach consensus but the following definition was adopted.  The
     scheme chosen for the URN ``does not impede resolution of names''
     to locations.

      -  From an atomic URN you can perform a resolution that gets you
         to a URL or set of URLs

      -  Support a distributed diversity of resolution services

      -  Karen Sollins made the point that even a pointer to a place to
         look will change with time, therefore including this
         requirement defeats the idea that these objects are permanent


   o No consensus was reached on the issue of caching.  Keith Moore
     considered this a very important function.  The group made the
     following points:

      -  If you cache object and name associated with it, you would want
         to know that object is valid.

      -  Clifford Lynch said that arguably, caching doesn't have a place
         in the naming syntax, but it may be manifest in some of the
         naming/locator mapping services.

      -  Are we talking about the cachability of the URN or the
         cachability of the content?


Karen Sollins and Larry Masinter volunteered to write the initial draft
of this document.

The group also decided that discussions on the functional specfications
of the URCs should be started.


Attendees

Harald Alvestrand        [e-mail]
Farhad Anklesaria        [e-mail]
Jules Aronson            [e-mail]
Sepideh Boroumand        [e-mail]
Luc Boulianne            [e-mail]
Randy Bush               [e-mail]
Susan Calcari            [e-mail]
Brian Capouch            [e-mail]
Hallie Carlson           [e-mail]
James Conklin            [e-mail]
John Curran              [e-mail]
Peter Deutsch            [e-mail]
Walt Drummond            [e-mail]
Alan Emtage              [e-mail]
Qin Fang                 [e-mail]
Jill Foster              [e-mail]
Ned Freed                [e-mail]
Jim Fullton              [e-mail]
Kevin Gamiel             [e-mail]
Arlene Getchell          [e-mail]
Judith Grass             [e-mail]
Deborah Hamilton         [e-mail]
Russ Hobby               [e-mail]
Jeroen Houttuin          [e-mail]
Richard Huber            [e-mail]
Erik Huizer              [e-mail]
Barbara Jennings         [e-mail]
Brendan Kehoe            [e-mail]
John Klensin             [e-mail]
Jim Knowles              [e-mail]
Andrew Knutsen           [e-mail]
John Kunze               [e-mail]
Edward Levinson          [e-mail]
Ben Levy                 [e-mail]
Clifford Lynch           [e-mail]
April Marine             [e-mail]
Jim Martin               [e-mail]
Larry Masinter           [e-mail]
Chip Matthes             [e-mail]
Mark McCahill            [e-mail]
Michael McLay            [e-mail]
Michael Mealling         [e-mail]
Mitra                    [e-mail]
Pushpendra Mohta         [e-mail]
Keith Moore              [e-mail]
Mark Needleman           [e-mail]
Clifford Neuman          [e-mail]
Lars-Gunnar Olsson       [e-mail]
Scott Paisley            [e-mail]
Rakesh Patel             [e-mail]
Pete Percival            [e-mail]
Karen Petraska-Veum      [e-mail]
Cecilia Preston          [e-mail]
Joyce K. Reynolds        [e-mail]
Steven Richardson        [e-mail]
Richard Rodgers          [e-mail]
Jon Saperia              [e-mail]
Srinivas Sataluri        [e-mail]
Rickard Schoultz         [e-mail]
Michael Schwartz         [e-mail]
Mark Smith               [e-mail]
Patricia Smith           [e-mail]
Karen Sollins            [e-mail]
Milan Sova               [e-mail]
Simon Spero              [e-mail]
John Stewart             [e-mail]
Craig Summerhill         [e-mail]
Thuan Tran               [e-mail]
Gregory Vaudreuil        [e-mail]
Janet Vratny             [e-mail]
William Weems            [e-mail]
Chris Weider             [e-mail]
Taehwan Weon             [e-mail]
Jackie Wilson            [e-mail]