CURRENT_MEETING_REPORT_ Reported by Tim Howes/University of Michigan Minutes of the Access, Searching and Indexing of Directories Working Group (ASID) ASID met once at the 32nd IETF on Wednesday, 5 April. Agenda Review/Changes The agenda was reviewed and accepted with the change that the group would discuss revising the charter at the end of the session. WHOIS++ The two WHOIS++ drafts, draft-ietf-wnils-whois-arch-03.txt and draft-ietf-wnils-whois-04.txt, have had minor changes made, been reviewed, and submitted for Proposed Standard to the area directors. A third draft, draft-ietf-wnils-whois-mesh-01.txt, is also ready and will be submitted as a Proposed Standard as soon as it passes last call on the ASID list. The WHOIS++ indexing draft was discussed under the next agenda item. Patrick Falstrom reported on a full WHOIS++ implementation by Bunyip, currently in a limited alpha test. Interested parties should contact Patrick. Jeff Allen (in absentia) reported on a client API and library he has implemented. Common Indexing Protocol Chris Weider gave an update on the common indexing protocol document (draft-weider-comindex-00.txt -- formerly the WHOIS++ indexing document). The document has been updated to reflect the discussions at the Paris indexing meeting last October, adding the ability to do weighting of terms, different methods of index generation, and removal of WHOIS++ dependencies. There was some discussion that the document was still not independent of the WHOIS++ protocol (e.g., the QUERY poll type, server handles, etc.). Chris agreed to incorporate changes to make it more independent which will be discussed on the list. SOLO Christian Huitema reported that progress on the SOLO draft has been stalled due to lack of time by the authors. Christian expects to have some time to work on it in the next couple of months, though. He will split the draft as discussed at the last IETF into two documents, one that describes the query protocol and one that describes the use of the common indexing protocol for navigation and distributed operation. There was also a report from Erik Huizer of a new implementation of SOLO by the University of Minnesota in their Minuet mail user agent. CLDAP At the last IETF, CLDAP was approved by the group to go to the IESG as a Proposed Standard. The IESG approved CLDAP as a Proposed Standard, but the draft never came out as an RFC. The area director speculated that it had gotten lost somewhere between the IESG and the RFC Editor and promised to track down the problem. LDAP LDAP and associated documents have been approved by the IESG as Draft Standards and published as RFCs 1777 (LDAP), 1778 (LDAP syntax) and 1779 (string dn). There were brief reports of new LDAP implementations by Zoomit and Marben and DEC. Tim Howes also reported on a new beta release of the University of Michigan LDAP implementation which includes a stand-alone LDAP daemon called slapd. slapd runs by itself, without an X.500 back-end. There was some discussion of why one would want an LDAP daemon that maintains its own database and does not just provide a front-end to X.500. Tim explained that the hope was in part to encourage more bottom-up growth of the X.500 directory. Sites can bring up slapd and provide a local directory service with little effort, upgrading to full X.500 easily and transparently when and if they choose. LDAPv2 The subject of a 93 X.500-compatible and more secure version of LDAP came up at the last IETF. This time, it was agreed that the current LDAP DS be allowed to go forward while work begins in parallel on LDAPv2, which will incorporate some 93 features. Discussion of the candidate 93 X.500 features included: o pagedResults: the ability to request search results a ``page'' at a time, rather than all at once. This feature is useful in various LAN environments which often produce scrollable lists of entries from which users select. o matchedValuesOnly: the ability to retrieve only those attribute values used to match a search filter. This feature is useful in situations where an entry contains a very large number of values for an attribute and the DUA is only interested in some of them. o dnAttributes: the ability to treat the attributes of an entry's DN as part of the entry during a search. This feature provides the ability to flatten the DIT, treating entries strictly as collections of attributes. o EntryInformationSelection: the ability to select which kinds of attributes to return (user, operational, etc.) Useful for removing crufty unwanted attributes from results. o EntryInformation: incompleteEntry flag. Useful for determining if a result comes from the full entry, or an incomplete copy of the entry. o serviceControls: new service controls such as copyShallDo, attributeSizeLimit, and subentries. o modifyRightsRequest: the ability to request modification rights to an entry via the Read operation. Since LDAP emulates Read with Search, this option is problematic. In addition, there have been several requests for better security in LDAPv2 in the form of strong authentication on the Bind operation, and signing and/or encryption of operations and results. Christian pointed out that strong authentication is not too useful without signed operations, given the ease with which connections can be hijacked. Encryption is not supported by X.500, but could be by LDAPv2. There appear to be three options for signing requests. o Make LDAPv2 PDU-compatible with DAP, so the signed requests can be passed directly to the DSA. This option lacks many of the advantages of LDAP, namely the string encoding of data types, and was therefore frowned upon by the group. o Make the LDAPv2 client pass its key to the trusted LDAPv2 server over a secure channel. The server can then sign operations as the client. The passing of the client's secret key, even in a protected way, is probably an increased risk. o Make the LDAPv2 server sign requests as itself. It is not clear whether this solves the problem or not. Volunteers were collected to begin work on an LDAPv2 proposal. LDAP URL Format Draft The draft-ietf-asid-ldap-format-00.txt document defines a URL format for accessing LDAP information via the WWW. Mark Smith has implemented the format in the libWWW client library and a version of Mosaic. The group agreed that the draft should be sent to the URI list for comment, and then submitted as a Proposed Standard (modulo URI-suggested changes) via the as-yet-undefined URI Working Group procedures for defining new URL formats. The prototype implementation is available from: ftp://terminator.rs.itd.umich.edu/ldap/url/ X.500 Schema Management Draft The draft-ietf-asid-schema-01.txt document was revised after the last IETF to clarify its relationship to the 1993 standard schema capabilities. There was some discussion on the list and in the group about the need for this document given the capabilities in the 1993 X.500 standard. The group agreed that the document should be submitted to the RFC Editor as an Experimental RFC. X.500/LDAP labeledURL Draft The draft-ietf-asid-x500-url-01.txt document was revised after the last IETF to incorporate URIs instead of just URLs. The group agreed that the document should go forward as a Proposed Standard and be incorporated into the Internet X.500 schema, after an appropriate experimentation period. ASID Charter Discussion The group has completed much of its assigned work, and this meeting set several new work items in the LDAPv2 and Common Indexing Protocol (CIP) work. The CIP work was originally proposed for another as-yet-uncreated working group. But given ASID has already begun doing some of the CIP work, and that it has finished some of its earlier work items, Erik asked, and the group agreed, to revise its charter and take on the new work. Given the additional focus on indexing, and the lack of any work items relating to directory synchronization, Erik suggested that the name of the group be changed to the more accurate ``Access, Searching and Indexing of Directories.'' The group agreed. AOB The group adjourned, with the next meeting scheduled for the summer IETF in Stockholm. Summary of Action Items o Area directors to progress the first two WHOIS++ documents to Proposed Standard. o Patrick to send the WHOIS++ mesh paper to the ASID and WNILS lists for last call. o Chris to update CIP document based on comments he receives. o Christian to split the SOLO draft. o Area director to track down CLDAP and submit it to the RFC Editor for publication. o Tim, Peter Whittaker, Ken Rossen, Mark Smith, Steve Kille (in absentia), and Eric Rosenquist to begin work on an LDAPv2 proposal. o Tim to send the draft-ietf-asid-ldap-format-00.txt document to the URI Working Group list for comment. o Glenn Mansfield to submit the draft-ietf-asid-schema-01.txt document to the RFC Editor as an Experimental RFC. o Tim to submit the draft-ietf-asid-x500-url-01.txt draft to the area directors for Proposed Standard. o Tim to revise the ASID charter and submit it to the list for review.