CURRENT_MEETING_REPORT_ Reported by Jim Conklin/CREN Minutes of the Uniform Resource Identifiers Working Group (URI) The URI Working Group met on Tuesday, 18 July. Minutes of the group's last meeting were approved without dissent. Reviews of Material The majority of the meeting was devoted to reviews of material provided electronically to the Working Group. Specifics of these activities may be found in the e-mail and Internet-Drafts which were the basis of the presentations. Some additional information is also captured later in these notes. o Leslie Daigle presented an overview of the SILK-based URA and metadata resolver developed at Bunyip. o Karen Sollins summarized her perspectives on URN resolution standards and services. o Keith Moore reviewed the key aspects of the resolution server developed at the University of Tennessee, Knoxville. o Dirk van Gulik highlighted the Harvester search and resolver tool developed at the Center for Earth Observation. There was a brief question and answer period as follow up to these presentations, which included discussion on the distinction between URLs and meta-data in general, and whether meta-data or actual documents should be returned by a resolver or search engine. The issue of punctuation and character sets was raised but not pursued. Pointers to electronic sources of information and experimental tools were given. Ron Daniels provided a brief update on the URC drafts and work needed to complete them. Related IETF sessions were highlighted: the Read the Label BOF (RTL) on Wednesday afternoon, the unofficial Tuesday afternoon BOF on meta-data, and the Tuesday evening MIME registration session. The URI Working Group Charter The remainder of the meeting was devoted to a discussion of the Working Group's charter. John Klensin, as the responsible Area Director, started this discussion. He noted that the working group had completed its original milestones and had been troubled by lack of consensus and a tendency to ``solve'' problems by creating yet another new type of UR identifier to be defined. He suggested that the working group must reorganize itself, use small-group interactions to achieve focus, and find appropriate mechanisms for separating activities rather than reasons to add new work to the working group. Discussion was reasonably lively and included concerns about coordination among multiple groups working on the various activities that relate to UR*'s, the claim that there is working code and rough consensus on URAs by those that need them, and a reminder that the original URI charter was deliberately written very broadly. This was followed by a charter review presented by Leslie Daigle and based on the proposals for charter revision which she and Ron Daniel had distributed electronically to the working group. This began with a quick review of the text defining the work of the working group, which, by common consent, was not addressed in discussions in order to focus on the Goals and Milestones section. There was considerable discussion of many aspects of the proposed Goals and Milestones, with the following actions resulting therefrom: o Working group action on the URN syntax drafts should be moved ahead and accomplished by an interim report comparing the various URN proposals (based on work already distributed to the working group) and recommending action, with either a proposed standard for a unified, general URN syntax to be adopted by the working group at the December IETF or agreement to allow separate, competing proposals for URNs to proceed independently. o A similar approach should be followed for URCs, though specifics were not determined. o Revision of RFC 1738 will be postponed until after the working group action on URN syntax. (A new date was not agreed upon for this.) o Revision of RFC 1736 will not be done by this working group. Instead, a new working group to be formed specifically for the purpose of determining procedures for IANA acceptance of new URNs for registration. This working group will be tasked to revise RFC 1736 or create a new document for that purpose, and to revise RFC 1737 only if that appears necessary in order to accomplish its task. o The working group needs to reach consensus on the finger and mailserver URLs in order for them to move forward. This should be done quickly. o Leslie Daigle, Chris Weider, and a third person agreed to complete a draft Informational RFC on Uniform Resource Architecture for discussion in December 1995. o Klensin announced that an additional URI session could be scheduled for Thursday afternoon and used to continue the revision of the working group charter and possibly action on the finger and mailserver URL proposals. (It was thereafter announced as the UR: Next Generation BOF (URNG).) Note: At the subsequent URNG BOF, the URI Working Group was closed and proposals were made for several new working groups to carry on the work. A report of this action appears in the Applications Area Report. Additional Information about the Presentations Leslie's presentation on the SILK-based URA resolver noted that it is designed to be used to create sophisticated user decision-making and information presentation through use of the meta-data provided by URAs. It is intended to simplify the invocation of URAs, to create new objects through individually specified processing of meta-information and to access multiple URNs in order to obtain the meta-data needed to satisfy the users' needs, thereby going beyond the usual interaction of a client with a single server. It allows HTML display of information to be bypassed in preference to a user's specifications. Karen reviewed the ideas for ``URN Resolution Standards'' from her Internet-Draft, including extremes and intermediate positions about what to standardize regarding name assignment and resolution. She noted that resolution services must be designed to accommodate a wide variation in requirements (locality vs. ubiquity, wide variations in the speed required for resolution, etc.) depending on the nature of the data or other object being retrieved, the availability and the validity of the information being located, policy controls, pricing, etc. Karen suggested that client development represents the major cost for retrieval services and that clients need to be able to use a large variety of services and servers, which implies the need for stability in the client interface to resolution services, modularity, and independence of service implementation. Karen concludes from these ideas that we should: o Standardize on client-service protocols. o Standardize on the form of URNs. (Needed quickly!) o Standardize on how client/application might learn about resolution service suggestions -- meta-information. o Not standardize on a single inter-server protocol (but perhaps write several server-to-server protocols, each of which might become standardized). Keith discussed the resolution server, ``SONAR'' server, which point to ``best'' resolver, and the Web client which he and his colleagues are developing. They use LIFNs, make relative URLs work correctly, are fast, and are available now for experimentation. See: http://mobile.netlib.org Dirk reviewed ``Harvester'', a ``search and choice'' tool. He noted that, from the perspective of Harvester, it does not really matter what URNs are, they are just like a handle to point to metadata, unique keys into databases. His services are based on negotiation between client and resolution service. The URN looks like the X-DNS URN. Relevant URLs for this work include: http://elect6.jrc.it/ dirux/alibrooker.html http://ewse.jrc.it/. http://www.ceo.org/. x-dns-2 on port 4500 @elect6.jrc.it