# Toronto Minutes

Alan Emtage (bajan@bunyip.com)
Tue, 2 Aug 1994 02:42:09 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Alan Emtage: "So long...."
- Previous message: Mark P. McCahill: "Re: Version 5.3 of URL draft: NOTE URL: PREFIX MOVE"

    Message-Id: <9408020642.AA12259@mocha.bunyip.com>

    From: bajan@bunyip.com (Alan Emtage)

    Date: Tue, 2 Aug 1994 02:42:09 -0400

    To: uri@bunyip.com

    Subject: Toronto Minutes

Hello,
Here they be. Corrections should be sent directly to me.

-Alan

---------------------------------------------------------------

Minutes - URI Working Group

Co-Chairs - Alan Emtage, Bunyip Information Systems
Jim Fullton, CNIDR

The Chair wishes to thank Randy Bush and Luc Boulianne for taking the
minutes of the meeting. Minutes edited by Alan Emtage.

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 parmameter 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.
- 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 offline and resolved before the next session.
- 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 toward the ADs.

o Erik Huizer made note that the formal procedure is to register the
draft, give notice to the WG chair, the chair sends a message to the
ADs that consensus has been reached, and the ADs 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 offline 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 WG agreed that with a few minor changes this document would go on to
the next stage.

[Judith Grass presented CNRIs Electronic Copyright Management System. See
slides]

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:

URL Specifications
URL Requirements
URN Requirements
Presentations

The Chair warned the group that "religious" arguments would not well
received.

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

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

1.3 URL specifications - Larry Masinter

Larry summarized a number of responses from the net from the
latest draft.

a. Spelling

A few words need to be fixed.

b. Prospero

This section was reworked with the help of Clifford Neuman.
c. WAIS

This section had been reworked by the WAIS group and modified.
d. 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

e. Case of encoding characters

It was agreed upon that the case of encoding characters
would be insensitive: ie. %2f and %2F are both legal
encodings of `/'

f. Gopher specification

The gopher specification needs a bit of clarification and Mark
McCahill would be asked for further wordsmithing.

g. BNF Changes

Slight modifications to clarify that a URL Body does not
have any prefix.

h. Relative URLs

After much debate, it has been suggested that relative URLs
be specified in a separate document.

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

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

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

2.0 Presentations

2.1 LIFN - K. Moore

Keith made a presentation of Location Independent File Names
[LIFN], which he hopes will produce discussion on the Net.

[See slides in proceeding, ASCII rendition for net distribution
follows]

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

Slide #2:

What are LIFNs used for?

- caching
- replication
- integrity
- authenticity

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

Slide #4:

What do LIFNs look like?

LIFN:netlib:ewkongpmfdbskdhgoenbqdggrufs
\ /
| |
+--+-+
|
Naming Authority

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]-------+

Slide #6:

Integrity/Authenticity:

URN ---> [lookup] ---> URC
|
V
LIFN -----> FILE
MD5 ___ |
Author \ |
Title \ |
etc. `MD5

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:

- the late binding of the LIFN
- URC mappings
- 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.

2.3 Reposting of the I-D for URN specification by Chris Weider/Peter
Deutsch

URN:IANA:XYZ:opaque-string

Issues where brought up about

- the lack of structure in the opaque string, and
the fact that it should remain so
- 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
- issues in with naming authorities with stress on
political ownership and the expected lifetimes of
these naming authorities.

2.4 Priorities wrt 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.

2.5 Presentation of URCs - M. Mealling

This short presentation served to bring up issues concerning
URCs. These issues were:

- what are URCs used for?
- should they represent one or multiple
objects/resources?
- what relationships do they define?
- should they be assertions about objects?
- what kind of meta information should URCs describe?
- has a bibliographical search been done on this topic?
- are URCs always bound to some name?
- are gopher menus URCs without a name?

The chair proposed the following:

a. URNs need some nitty gritty work done soon
b. URCs call for documents that specify the intent of
these. K. Sollins has volunteered to do this.

3.0 Closing comments by Erik Huizer

Both Alan Emtage and Jim Fullton have indicated that they wish to
step down. They will retain the Chair until the documents in
progress are completed.

Erik thanks both for their dedication and effort in during these
last few years.

Larry Masinter has accepted to take over from Alan and Jim.

- Next message: Alan Emtage: "So long...."
- Previous message: Mark P. McCahill: "Re: Version 5.3 of URL draft: NOTE URL: PREFIX MOVE"