CURRENT_MEETING_REPORT_
Reported by Randy Bush/RGnet and Luc Boulianne/Bunyip Information
Systems
Minutes of the Uniform Resource Identifiers Working Group (URI)
Session I
The first order of business was administrative items.
Alan Emtage reported that he has informed the Area Directors responsible
for the URI group that he will be relinquishing his position as Chair at
the earliest convenient opportunity, but will continue to participate in
the working group Jim Fullton will also be leaving a Both resignations
are due to general work overload.
Alan remarked that when this group started two years ago, most people
(including himself) did not really know th depth and breadth of the
problems being addressed and he feels that, although progress has been
slow, given the depth the group should be proud of the work that it has
done.
Minutes of last meeting were approved.
The posted agenda had the working group doing URNs and URCs. A number
of people have asked to work on URLs first, specifically the URL
Requirements and Specifications documents needs closure. Larry Masinter
will bear primary responsibility for final edit of the latter document.
It is suggested that the group do this first and then get to URNs and
URCs. Judith Grass, Michael Mealling and Keith Moore have requested
time for short presentations to the group. These changes were approved.
URLs
o John Kunze on URL Requirements Internet-Draft
- Minimum set of requirements for URL standards
- To help us evaluate specifications (only one has been
submitted)
- Little or no comment was in evidence on the list
- John evaluated current URL specification to see if (in his
opinion) it met the requirements. Only those points in
contention were discussed.
* 1 locators are transient
YES
* 2 locators have global scope
MOSTLY
Karen Sollins raises the issue that policy reasons may
prevent your reaching an object and John noted that the
file: scheme of the URL does not have global scope as
currently defined.
* 4 can be readily distinguished
MOSTLY
John suggested that the group should perhaps reserve URL,
URN, URC as scheme names.
* 5 machines can recognize them in context.
NO.
John believes that ``URL:'' does not fulfill the requirement
* 8 URL is scheme and host information plus an opaque
parameter package
MAYBE
- Now what do we do with this document? The Chair suggested that
the group move on to go to specs and look at the problems in
that context.
o Larry Masinter presented the URL spec
- version presented was that of 21 July.
- the goal was to respond to Nef Freed's comments on the draft
and to make the document more self-contained.
- the wording re the URL syntax was changed to make it clear that
it is a scheme and that each scheme's particular syntax is
viewed within that framework.
- encoded and reserved characters were contentious. The
important thing is that reserved characters have different
semantics when encoded or unencoded.
- fragment identifiers were not in the current ID, despite use in
WWW. but it was done in a way which would allow WWW's syntax.
- a common underlying Internet scheme was clarified with hosts,
ports, ...
- the FTP scheme wound up being having a type of B, A, I, or D,
but the type code is optional.
- the http part did not change substantially. the ``/'' is not
part of the path, but is a separator.
- gopher URL was enhanced by Mark McCahill who added the gopher+
syntax
- mail URL was extended, but not handling mail external body
semantics
- the news URL did not change substantially
- an NNTP URL was added since the last meeting
- the TELNET URL did not change substantially
- Margaret St. Pierre did a WAIS URL, but a revision arrived
Friday and so would be included
- the file URL is in the specification, but the body of the URL
is unusual as it does not specify a protocol.
- registration of new schemes is allowed via IANA
- people are working on POP, IMAP and other URLs.
- the BNF is being refined, specifically to eliminate recursion,
etc.
- security considerations have not changed.
o Mitra commented:
- Why was Prospero removed? Observed as an inadvertent editing
error.
- The hash character text as current is not implementable. Is it
a Web specific URL or is it part of a filename, i.e. the
parser has to know if it is parsing a web URL? Should hash be
reserved? Larry argued for the position that URLs are only
interpreted within a context thus the prefix label, angle
braces, etc. are all within context.
o Tim Berners-Lee responded
- Larry's position is technically correct and quite feasible. The
wording is weak, and should be clarified to remove 'almost' and
other waffles. The Chair requested that this discussion will be
taken off-line and resolved before the next session.
o Karen Sollins points out that in her work that in the long run
identifiers do not want access protocols as those protocols will
change in time.
Erik Huizer observed that the URL: prefix issue had not been resolved
and the Chair noted that as things stand that the Specifications do not
meet the criteria in the Requirements document.
o John: Let's go through the requirements in order
- 2 - global scope: file scheme is only exception
- 4 - can be distinguished. are URN and URC
distinguished/reserved? URN is reserved, URC is not.
- 5 - machines can identify URLs as such. the URL: prefix is
required and clearly specified. 2.1.1. did change in that the
justification has been removed.
The following discussion revolved around the fact that the current
specifications did not meet the requirements. The Chair observed that
the fact that current implementations did not meet the specifications
does not invalidate the specifications.
It was decided that the ``machine recognizable'' requirement be dropped
as being un-implementable.
Participants were asked to try to resolve the issue before the next
session.
URN Requirements
o Karen Sollins discussed the current URN Requirements document.
Given the review on the list, the comments are fewer and smaller,
so they are ready to ship the document.
o Speak now or send mail in the next few days, or they will proceed
to register the draft and pass it to the area directors.
o Erik Huizer made note that the formal procedure is to register the
draft, give notice to the working group chair, the chair sends a
message to the area directors that consensus has been reached, and
the area directors will insert it into the administrative loop.
Erik also noted that he had several comments to make on the current
draft and would take it off-line with Karen and Larry. He
suggested that the ``Implications'' chapter may be out of place in
the document. Karen responded that it was included to give context
to the casual reader. A section would also be added to the
requirements that URNs be unique over time. Karen responded that
this was the intent and that wording would be added to this
document.
The working group agreed that with a few minor changes this document
would go on to the next stage.
[Judith Grass presented CNRIs Electronic Copyright Management System.]
Larry Masinter questioned whether the group had enough of a grasp on the
concept of URCs to move forward with the discussion. There was
agreement that the kind of information envisioned for URCs is needed
however it is unclear whether the current syntax can be evaluated given
the lack of context to the use to which they would be utilized. The
Chair observed that the URCs were intended to hold that information
which was removed from the URL and URN discussions.
Session 2
The agenda as agreed to by the group was:
o URL Specifications
o URL Requirements
o URN Requirements
o Presentations
The Chair warned the group that ``religious'' arguments would not be
well received.
URN requirements - K. Sollins
The document requires a few changes. In particular, some word smithing,
must be performed so that some suggestions not be reworded so as not to
be interpreted as requirements. A clarification must be done to clarify
that although URNs must be human transcribable, they need not be
user-friendly. Finally the requirement of global uniqueness over
all-time must be stressed further.
Changes should be ready in a few days following the meeting.
URL requirements - John Kunze
John demonstrated with an excerpt from the San Francisco Chronicle in
which typesetting hyphens occurred within the URL. It was generally
agreed that little could be done about this.
URL specifications - Larry Masinter
Larry summarized a number of responses from the net from the latest
draft.
o Spelling
A few words need to be fixed.
o Prospero
This section was reworked with the help of Clifford Neuman.
o WAIS
This section had been reworked by the WAIS group and modified.
o
ftp://host/path
The leading slash following the hostname of the FTP URL should be
emphasized and clarified to point out that this slash is NOT part
of the path. If a leading slash is needed, then this slash should
be encoded as %2F. This is necessary because some FTP servers
implement the CWD command differently.
If you want to execute this command:
RETR /foo/bar/file
then the proper URL must be:
ftp://host/%2Ffoo%2fbar%2Ffile
If you want to execute this sequence of commands:
CWD /foo
CWD bar
RETR file
then the proper URL must be:
ftp://host/%2ffoo/bar
o Case of encoding characters
It was agreed upon that the case of encoding characters would be
insensitive: i.e., %2f and %2F are both legal encodings of `/'
o Gopher specification
The gopher specification needs a bit of clarification and Mark
McCahill would be asked for further wordsmithing.
o BNF Changes
Slight modifications to clarify that a URL Body does not have any
prefix.
o Relative URLs
After much debate, it has been suggested that relative URLs be
specified in a separate document.
o WAIS and Gopher+ URL
Because there is no official standards document defining WAIS and
Gopher+, it seems incorrect to refer to a standard definitions of
URLs for these. Jon Postel will be consulted in this matter.
o xxx://host:/...
the : following the host is used to define a port number. In the
case above, the document is ambiguous. It has been suggested that
a port number must follow this colon, and that compliant code will
always do so. However, there is nothing to prevent a server to
accept the above and assume the default port for the xxx protocol.
The Internet convention strictly producing but liberally accepting
was re-iterated here.
o URL: prefix
The issue of the URL: prefix was raised and the group decided that
a time limited debate of 30 minutes would be conducted. After the
debate it has been agreed that the URL: prefix would not be part of
the standard definition of a URL. However, the use of such a prefix
has been relegated to an Appendix to the document. In such a case
the URL:[ftp://....] form would be appropriate.
Presentations
LIFN - K. Moore
Keith made a presentation of Location Independent File Names [LIFN],
which he hopes will produce discussion on the Net.
o Slide 1
What are LIFNs?
- a LIFN is a particular sequence of octets
- once assigned, the name may not be reused -- that is, the
binding between a LIFN and the sequence of octets never changes
- this is *not* an intellectual content identifier
o Slide 2
What are LIFNs used for?
- caching
- replication
- integrity
- authenticity
o Slide 3
What are the requirements for LIFNs (compared to URNs)
LIFN URN
_________________________________________________
global scope global scope
global uniqueness global uniqueness
persistence persistence
sameness sameness
- two files have the
same LIFN if they are
identical
scalability scalability
- we won't run out
distribute assignment distribute assignment
grandparenting
extensibility
allows resolution allows resolution
- you can get URLs from it
machine parseable machine parseable
human transcribable human transcribable
transport friendly transport friendly
o Slide 4
What do LIFNs look like?
LIFN:netlib:ewkongpmfdbskdhgoenbqdggrufs
\ /
| |
+--+-+
|
Naming Authority
o Slide 5
How do you use LIFNs?
resolution:
LIFN ---> Location Server ---> URLs
caching:
+--> file
|
LIFN ---> Cache/Proxy Server --+
|
+--> nothing
replication:
+-------[LIFN]---->--+
| |
--+-- V
Slave Server Master File Server
^ --+--
| |
+--<----[LIFN]-------+
o Slide 6
Integrity/Authenticity:
URN ---> [lookup] ---> URC
|
V
LIFN -----> FILE
MD5 ___ |
Author \ |
Title \ |
etc. `MD5
o Slide 7
A slide showing how the user interacts with the systems, in color.
Just a bit too complicated to reproduce in ASCII.
Discussion followed. Some of the points brought up for later
discussion:
o the late binding of the LIFN
o URC mappings
o similarity of LIFNs to URNs
Keith suggests that LIFNs could be used as a transition step from URLs
to URNs.
Discussion will continue on this on the net.
Reposting of the Internet-Draft for URN specification -
Chris Weider/Peter Deutsch
URN:IANA:XYZ:opaque-string
Issues where brought up about:
o the lack of structure in the opaque string, and the fact that it
should remain so
o whether or not DNS names be used in the naming authority, and that
if this is the case, then dots should be used instead of colons
o issues in with naming authorities with stress on political
ownership and the expected lifetimes of these naming authorities.
Priorities with regard to URNs and URCs
The chair brought up whether the group should divide its efforts and
pursue both URNs and URCs concurrently. No resolution was brought up on
this.
Presentation of URCs - M. Mealling
This short presentation served to bring up issues concerning URCs.
These issues were:
o what are URCs used for?
o should they represent one or multiple objects/resources?
o what relationships do they define?
o should they be assertions about objects?
o what kind of meta information should URCs describe?
o has a bibliographical search been done on this topic?
o are URCs always bound to some name?
o are gopher menus URCs without a name?
The chair proposed the following:
o URNs need some nitty gritty work done soon
o URCs call for documents that specify the intent of these. K.
Sollins has volunteered to do this.
Closing comments by Erik Huizer
Both Alan Emtage and Jim Fullton have indicated that they wish to step
down. They will remain co-chairs until the documents in progress are
completed. Larry Masinter will then take over as URI Chair.
