From: bajan@bunyip.com (Alan Emtage) Date: Wed, 17 Nov 1993 19:30:33 -0500 Hello, Here they be... -Alan ----------------------
Co-Chairs: Jim Fullton (jim.fullton@cnidr.org) Alan Emtage (bajan@bunyip.com) 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 (craig@cni.org) for minutes/note taking.
Introductory remarks were made by the co-chairs and the minutes of the
previous meeting approved.
- Erik Huizer (Erik.Huizer@surfnet.nl), 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 (jak@violet.berkeley.edu) 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.
URL:1:
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
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.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 (mrose@dbc.mtview.ca.us)
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
sessions)
- "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
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
document.
- 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 (mitra@path.net) 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 (mpm@boombox.micro.umn.edu) 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
list.
General consensus was reached as
to the agreements on changes to the
current draft. The author Tim Berners-Lee
(timbl@info.cern.ch) will be asked
to make the changes.Discussion on the current URN and URC drafts was started. Larry Masinter (masinter@parc.xerox.com) 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 ?
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 (peterd@bunyip.com) 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
year.
- 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
requirement
- 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 (sollins@lcs.mit.edu) 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
(moore@cs.utk.edu) 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 (calur@uccmvsa.ucop.edu) 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.