Minutes from Columbus

Alan Emtage <bajan@bunyip.com> Wed, 14 April 1993 00:41 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01406; 13 Apr 93 20:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01402; 13 Apr 93 20:41 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa00602; 13 Apr 93 20:41 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15757 on Tue, 13 Apr 93 17:23:08 -0400
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15738 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Tue, 13 Apr 93 17:16:16 -0400
Message-Id: <9304132116.AA15738@mocha.bunyip.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Emtage <bajan@bunyip.com>
Date: Tue, 13 Apr 1993 17:16:15 -0400
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: uri@bunyip.com
Subject: Minutes from Columbus
Cc: urmarc@merit.edu, iafa@bunyip.com

Hi All,
	Here are the minutes from the Columbus IETF meeting. They are
kind of long, but we accomplished quite a bit and we did have 3 sessions.
Also I know that a lot of people out there are interested in this stuff
so I've tried to be a thorough as possible. If I've messed up somewhere
(or misrepresented anybody's position) please let me know.

-Alan

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

Minutes of the Uniform Resource Identifiers WG, 26th IETF Columbus, Ohio


Co-Chairs: Jim Fullton (jim.fullton@cnidr.org)
	   Alan Emtage (bajan@bunyip.com)
	   

The Uniform Resource Identifiers WG held 3 sessions in Columbus. These
minutes are separated on a per-session basis. The basic agenda was as
follows:

Session 1	Uniform Resource Locators (URLs)
Session 2	Uniform Resource Names (URNs)
Session 3	Discussion of other necessary objects


Session 1
---------

In order to try to prevent further confusion it was agreed that the
following terminology would be used:

For all the various UR* objects being discuss, the "U" would stand for
"Uniform" and the "R" would stand for "Resource".

URL is Uniform Resource Locator
URN is Uniform Resource Name
URI is Unform Resource Identifier (the collective name for UR*)


A discussion of Tim Berners-Lee's (timbl@info.cern.ch) current draft on
Uniform Resource Locators (URLs) followed. The following points were made:

- It is expected that in the near future character sets other than ASCII
  will need to be addressed. However in the short run it was decided that
  ASCII would be adequate for the task. The point was made by several
  European members of the WG that while other character sets would be
  necessary, it is important to get the current draft out and have the
  protocols discussed therein implemented. Wording to the effect that
  this matter has been addressed should be incorporated into the current
  text. The mechanisms defined need to be extensible to allow for
  expansion in this area.

- The issue of "fragments" was raised. While the current draft addresses
  "large scale" objects such as entire files and services, it makes no
  attempt at defining sub-objects (such as a paragraph, word or
  individual letter in text file). For example, how does one define a
  "paragraph" in a PostScript file, given that this is effectively an
  interpreted language? The general consensus was that this we still do
  not have an adequate understanding of the underlying principles involved
  and that this discussion should be pursued on the mailing list.

- The issue of OSI distinguished names in URLs was discussed. While
  further discussion is probably warranted, consensus held that this
  would probably be too "heavy" for the current proposals.

- MIME encodings are also one possible avenue for describing network
  objects. It was agreed that the WG should work closely within the
  framework of existing RFCs for such descriptions.

- It was agreed that the current URL draft should include an example
  URL specification for each access method defined in order to guide
  implementors.

- Again the issue of partial URLs in the current draft was raised. It was
  agreed that while systems may choose to use such constructs internally,
  at no time would they be valid at the inter-system interface.
  Consensus was reached that stronger warnings need be placed in the
  current draft to that effect. It was also agreed that in the interests
  of time further discussions of the issue should be taken to the mailing
  list. The definition of partial URLs should also be moved to an appendix
  of the current document since they are not part of the official
  specification. Any algorithm for determining partial URLs should also
  be moved to the appendix.

- The mechanism for registering new access methods with the Internet
  Assigned Numbers Authority (IANA) should be more prominently placed in
  the current draft. Also, some mechanism for defining experimental
  access methods should be included.

- Several issues were raised which, it was decided, were better suited for
  the upcoming URN discussion since they fell into that domain.

  o Some form of integrity test was suggested (check digits) for URLs. It
    was decided that since URLs are inherently transitory in nature, that
    such tests would not be necessary.

  o Versioning

  o Security issues

  o Time to Live (TTLs)

 - It is expected that with this input the current draft can be submitted
   for Internet Draft status within a few weeks following the meeting.

Session 2
---------

Before the meeting Cliff Lynch (calur@uccmvsa.ucop.edu) had posted an
overview document to the mailing list titled "A Framework for
Identifying, Locating, and Describing Networked Information Resources"
and at the beginning of the session, he described the major points that
the paper contained.

John Kunze (jak@violet.berkeley.edu) had also posted a document entitled
"Resource Citations for Electronic Discovery and Retrieval" and made a
short presentation about the paper.

Peter Deutsch (peterd@bunyip.com) made a presentation as to a possible
architecture for URNs.

A "spirited" discussion followed as a result.

There was much discussion as to what properties a URN should and should
not have and the resulting fracas was in the best tradition of IETF
"consensus building".

It as agreed that while some the underlying data of particular network
objects changed (for example, a video feed), that the URN associated with
such an object would remain essentially the same. However, the URNs for
the underlying data would have to change as the data changed.

Several suggestions for the type of information to be included in URNs were
discussed and it was decided that a final decision would be made at the
final session.

Session 3
---------

After canvassing several members of the working group, the session
started with short presentation by one of the co-chairs Alan Emtage
(bajan@bunyip.com). It was proposed that the URN have a very simple
structure. In order to be able to completely distinguish URNs from URLs
the following structure was proposed:

	URN:<ID Authority>:<URS>

The string "URN" is part of the structure. <ID Authority> is the unique
identifier for the issuing authority. <URS> is the Uniform Resource
String which is unique (as determined by the ID Authority) for that ID
Authority. No assumptions may be made about the substructure of the URS
which is effectively opaque to any entity other than the ID Authority.
The ID Authority would be registered with the IANA to ensure uniqueness.

This proposal was endorsed and the corresponding document would be
written by Alan Emtage, Jim Fullton (jim.fullton@cnidr) and Chris Weider
(clw@merit.edu) and submitted to the mailing list as soon as possible. It
is hoped that the document can go to ID status at or before the Amsterdam
meeting.

A presentation was made by Rob Raisch (raisch@ora.com) which suggested
some revisions to the above scheme.

Questions about architecture were raised and it was suggested that the
current draft architecture document from the Integration of Internet
Information Resources (IIIR) working group be consulted.

Further discussion illustrated the fact that the combination of URL & URN
would not be sufficient for a effective infrastructure since much of the
data needed by the user to determine desirability of an object located
through a search was not present in these structures. These include such
things as :

	- Versioning
	- Language
	- Character Sets
	- Representation (eg, PostScript, bitmaps, ASCII etc)
	- A whole array of non-static/non-text attributes

Tim Berners-Lee, John Kunze and Michael Mealling
(Micheal.Mealling@oit.gatech.edu) made presentations as to how to handle
this "meta data" or "factoids".

It was decided that defining the semantics and syntax of these attributes
would take careful work and should be the focus of upcoming meetings.