Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / uri / uri-minutes-94jul.txt < prev next >

Wrap

Text File | 1994-11-02 | 17KB | 531 lines

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.