CURRENT_MEETING_REPORT_ Reported by Tim Howes/University of Michigan Access/Synchronization of the Internet Directories Working Group (ASID) Introduction and Agenda Review The first official meeting of the group was called to order and the proposed agenda was reviewed and accepted without changes. Discussion proceeded on the following topics. RWhois Protocol Presentation Mark Kosters gave a presentation on the RWhois protocol, developed by the InterNIC and other network service providers in response to the operational problem of providing contact information for sites, networks, and domains. RWhois provides the means to delegate authority for data in a hierarchical configuration, and for then retrieving that data given a hierarchically structured key (like an IP address, domain name, network number, etc.), using a system of referrals designed to keep getting clients ``closer'' to the data. It is compatible with the existing WHOIS query protocol. RWhois borrows ideas from several existing directory service protocols, including WHOIS++, X.500, DNS, and others. The RWhois developers intend to continue their development outside the IETF for the moment, with an eye toward bringing RWhois into the IETF standards process at a later date, when the protocol is more complete and their operational problems are not as pressing. SOLO Update Christian Huitema presented an update on the SOLO protocol work, including some experience gained with the SOLO centroids implementation. In SOLO, a server can respond to a centroid poll operation with a ``*'' value, meaning that it wishes to be contacted for any search involving the attribute for which it might have data. This functionality is necessary to support more restrictive privacy requirements that may prevent servers from exporting a centroid of all names in their database, but can cause operational problems (the * tends to defeat the pruning purpose of the centroid). Other possible solutions to this problem were discussed, including sending a centroid containing hash values of the data rather than the data itself. This method is attractive because it limits the amount of information transferred, maintains privacy of the data, and could make searching the data in the centroid server more efficient. It has the disadvantage of not easily allowing more complicated queries (e.g., substring match) to be processed by the centroid server. There was much discussion, particularly between the SOLO and WHOIS++ developers on these points. Chris Weider took an action to update the centroids paper to contain some of the ideas discussed, and to generalize the centroids concept so that it is usable by multiple protocols. WHOIS++ Update Joan Gargano gave a short update on the WNILS Working Group, which had its last meeting the previous day. WNILS approved the three WHOIS++ papers, on architecture, query language and centroids, respectively, for submission as RFCs. A fourth paper on how to use a centroids mesh when answering queries, will continue its development in the ASID Working Group. Chris Weider and Patrik Falstrom gave an overview of the paper, which describes how to use WHOIS++ referral responses and polled-by commands to narrow or broaden a search. Also described, and soon to be included in the paper, was a potential ``Directory of Servers'' centroid, that, using the normal centroids polling methods on a server's ``describe'' template, could be built to provide ``short circuit'' referrals to clients based on information in the template. Finally, Kevin Gamiel gave a brief overview of the work being done at CNIDR with WHOIS++. CLDAP The remaining issue with Connectionless LDAP was resolved. The issue was whether authentication should be included in the CLDAP request, so that servers could provide access to protected data. The latest proposal, reflected in Alan Young's most recent CLDAP draft, includes no authentication. The arguments against authentication are that it would tend to defeat the connectionless nature of the protocol in the intermediate server implementation approach, and that the proposed clear-text password is contrary to the IAB's desire to rid the Internet of such schemes. The proposal was accepted by the group, and the CLDAP draft should now be submitted to the area directors for Proposed Standard status. LDAP Several small problems with the LDAP syntax and related RFCs were raised on the net by Elisabeth Roudier and Ascan Woerman. Most of these problems were BNF mistakes in RFC 1488, RFC 1485 and RFC 1558, or unclear language. All the problems are believed to have satisfactory solutions designed, either by Elisabeth and Ascan, or Steve Kille and Tim Howes. Steve took an action to produce a new version of RFC 1485. Tim took an action to produce new versions of RFC 1488 and RFC 1558. A second problem, with RFC 1487, the LDAP protocol document, had been raised on the net by Martijn Koster. The problem is with the Modify RDN operation. In X.500 DAP, a choice can be made as to the disposition of the old RDN attributes (either retained as undistinguished entry attributes, or deleted from the entry). LDAP requires the old RDN attributes to be deleted always, which can cause a problem if the attributes are required. Simply switching the choice to always retain the attributes can cause problems in the case of single-valued attributes. The only full solution to the problem is to add a bit to the protocol so that clients can make the choice as in DAP. Tim took an action to start a discussion on the OSI-DS list to resolve this issue. Finally, a suggestion was made that this might be a good opportunity to look at incorporating X.500 (1993) support into LDAP. Reactions were mixed. Tim took an action to start a discussion on the OSI-DS list about this issue. Schema Publishing in X.500 Glenn Mansfield gave a presentation on some work he and his colleagues have been doing to publish X.500 schema information in the X.500 directory. The problem to be solved is how a DUA can resolve an unknown object class or attribute it may come across in the directory. Their paper includes schema for representing attributes and object classes in the directory. It also describes where this information should be placed in the DIT, and outlines the procedure a DUA should follow when it encounters an unknown schema element. There was also a discussion of the Internet X.500 schema group (late of the OSI-DS Working Group), which has published an Internet-Draft on their plans to publish and keep up-to-date the Internet X.500 schema. The group has finished its work on the draft, and should now start accepting new schema and begin publishing them. The group will continue to track this work in the hopes that it could be used as an on-line publishing mechanism. Tim took an action to send the schema group's draft to the OSI-DS list for last call comments, after which the draft will be submitted to the area directors for RFC status. The X.500 schema group (Tim, Russ Wright, Ken Rossen, and Sri Sataluri in absentia) took an action to finalize the distribution methods described in the draft, and to begin accepting new schema elements immediately. The address for submission is schema@ds.internic.net. The Next Meeting The next meeting of ASID will be at the December IETF in San Jose, California.