From: email@example.com (Alan Emtage) Date: Wed, 17 Nov 1993 19:30:33 -0500 Hello, Here they be... -Alan ----------------------
Co-Chairs: Jim Fullton (firstname.lastname@example.org) Alan Emtage (email@example.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 (firstname.lastname@example.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 (email@example.com) 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 (firstname.lastname@example.org) 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 (email@example.com) 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 (firstname.lastname@example.org) 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 (email@example.com) will be asked to make the changes.
Discussion on the current URN and URC drafts was started. Larry Masinter (firstname.lastname@example.org) 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 (email@example.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 cachingEach 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 (firstname.lastname@example.org) 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 (email@example.com) 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 (firstname.lastname@example.org) 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.