From: (Alan Emtage)
Date: Wed, 17 Nov 1993 19:30:33 -0500

	Here they be...



Minutes of the Uniform Resource Identifiers WG, 28th IETF Houston, Texas

Co-Chairs: Jim Fullton (
	   Alan Emtage (

The Uniform Resource Identifiers WG held 3 sessions in Houston. Two
were scheduled in advance, one scheduled in Houston as it was believed
that 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 minutes/note

Session 1

Introductory remarks were made by the co-chairs and the minutes of the
previous meeting 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.

  - The URI 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.

  - The Working Group Chair has the authority to remind the group that
    certain topics have already been discussed and 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.

  - 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.

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

  - 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.

  - 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-AD 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 a previous 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.

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

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

  - Suggestion that a protocol revision number be included in the the URL,
    as well as forthcoming Uniform Resource Name (URN) and Uniform
    Resource Citation (or Characteristics) (URC) specifications.


    suggested as the prefix to the URL.

  - Suggestion that the Working Group only concern itself with the URL,
    URN and URC objects at this time

  - Get back to basics:

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

  - 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*

  - 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
      - 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.

The following decisions were made:

  - It is a pointer for "resolution" of the URL to the actual object. The
    term "dereferencing" is dropped
  - It is transient in nature and applications may not depend on being
    able to resolve this to the object
  - It is "machine consumable". "Parseable" was also suggested
  - 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.
  - Has "global scope" (is absolute not relative)
  - URLs may be used to resolve any form of network "object" (e.g.,  Telnet
  - "machine independent". Does not depend on the platform trying to
    resolve it
  - 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
  - By taking "typing" information out of URLs some other mechanism needs
    to be defined to make the information available
  - 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.

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

  - 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)

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

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

A discussion of URN -> URL mapping reached no agreement but it was
decided that further discussion was required

Session 2

Jim Fullton presented a document produced by a number of working group members after previous session setting out the functional specifications
   - Locators may be valid only for a short time.  Methods for mapping
     between static identifiers and URLs are beyond the scope of this
   - Locators are machine consumable. Clarify that it is parsable.
   - 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.
   - Locators are transport friendly.  URLs must pass unscathed through 
     NNTP, SMTP, and other network protocols.
   - Locators contain no meta-information about the 
     resource other than the complete set of parameters required to access 
     the resource.
   - 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.
   - The locator is not intended for users, but the typical locator is 
     human readable but is transcribable.
   - The set of services/access methods is extensible.
   - 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:

   - Spaces. In the current draft they are legal but not recommended.
     - 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
   - Some modifications to partial URLs will be considered (changing
     /xxx/.. to xxx/../
     - Section on partials is not appropriate for the main text of the
       document and needs to be moved out to an appendix
   - The WAIS length field is not necessary for access and is dropped
     from the WAIS URL
   - The Prospero URL attribute mechanism will be modified (Mitra)
   - Character sets erroneously omitted the '+' and '=' characters and
     will be put back
   - Fragments. Removed from the document at a previous meeting , but
     never got deleted from the document .
   - News URL is more like a URN.  It uses the message ID, rather than
     information about such things as NNTP server.
     - 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
   - 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.
   - 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.
   - FTP requires some for 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.
   - 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

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:

   - They should provide persistent unique names for resources
   - They should be able to detect sameness of resources
   - 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

   - we have two groups here (IRTF and USRV/APPS), melting into one
     working group, and we have done a great deal of work in the last
   - we traditionally do R&D, and we may be doing more R&R (research 
     and release)

He then presented suggested functional specifications for URNs as proposed by a group of WG members:
   - 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?
   - It had been agreed before that the URN has the the following attributes
      - location independent name
      - human transcribable
      - transport friendly
      - machine consumable
   - 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:
      - 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
      - It was agreed that the URN not being an URL is an attribute not a
      - 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
      - Discussion of whether semantics in the URN should be discouraged.
        No consensus.
      - 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 net.  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  ability to name a large number of objects
	 - permits embedding of existing systems (grandfathering)
	 - extensible

      - No consensus was reached on the issue of uniqueness / sameness
        however the following points were made
        - This issue arises of the idea of "intellectual content"
	- It was agreed that the naming authority makes 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

      - The discussion about the URN permitting "resolution" made the
	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 are permanent

      - 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 specs of the URCs should also be started.