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.
- Minutes from Columbus Alan Emtage