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 33rd IETF on Tuesday, 18 July. Agenda Review/Changes The agenda was reviewed and accepted without changes. Review/Discuss Revised Charter The proposed charter previously sent to the list was reviewed and accepted without changes. Tim will submit it to the Applications Area Directors for approval. [Reporter's note: Subsequent to this decision, the responsible Area Director expressed a desire to form a separate working group to do the common indexing protocol work, which is currently in the ASID charter. If this happens, the ASID charter will need revising again.] LDAPv2 Bob Cooney of the US Navy presented their design and implementation of MDAP, the Minimal Directory Access Protocol. MDAP is full DAP run directly over TCP, without the OSI stack. This allows digital signature information to be carried end-to-end from LDAP client to X.500 server to ensure operation integrity. MDAP messages are packaged within newly defined LDAP messages to provide some compatibility with existing LDAP implementations. SLDAP is the Navy's implementation of MDAP, and is based on the freely available U-M LDAP distribution. John Myers presented his proposal for adding strong authentication to LDAPv2 based on the IMAP authentication work. A new Bind2Request LDAPMessage is defined to hold an IMAP4 authentication mechanism as defined by RFC 1731. Two new operations, a Bind2Response and a Bind2Continuation are also defined, allowing different authentication mechanisms to be negotiated as well as protection mechanisms (i.e., integrity or privacy), to be used subsequently on the session. There was some discussion of this approach and how it might or might not map onto X.500 strong authentication. Tim Howes gave a brief report of the approach taken by the Zoomit company to implement a 93-like paged results feature in LDAP. There was general agreement that this feature should be supported in a more standard way in LDAPv2. Tim also gave a brief report of the stand-alone LDAP work going on at U-M (LDAP without X.500). The work currently avoids orphaning stand-alone LDAP servers by using the existing LDAPResult error message field to return a ``referral'' to knowledgeable clients. The clients can then chase the referral to an X.500-aware LDAP server, another stand-alone server, etc. The group agreed that the referral capability was useful and should be incorporated in LDAPv2 in a more standard way. There was a short discussion of how to handle multiple character set and language issues in LDAPv2, though no conclusion was reached. Proposals should be sent to the list. At Danvers, various people promised to help produce an LDAPv2 draft by this meeting. But for various reasons, the work was not done, a fact the chair could not complain about too loudly, since he was one of the main culprits. The group agreed to redouble their efforts and produce a draft by Dallas. WHOIS++ Patrik Falstrom led a discussion of the WHOIS++ portion of the agenda, first describing the recently-released Bunyip implementation of WHOIS++, called DIGGER. The two WHOIS++ RFCs (query language and architecture) have been progressed to Proposed Standard. The remaining WHOIS++ RFC on the centroid indexing mesh is being held back pending the resolution of issues raised by the Area Director and others. The issues raised included: 1. The document does not address scaling issues well enough. Experiments are ongoing, and the group proposed to produce a document by the Dallas meeting documenting the results of these experiments. 2. The meaning of ``word'' is not clear. The group proposed that a word be defined using the reserved WHOIS++ tokens. 3. The character set issue was not addressed adequately. The group proposed to limit character sets to unicode and ISO-8859-1, with every implementation required to support both. The proposed MODE command was also discussed. The MODE command allows a WHOIS++ session to temporarily escape to another protocol. The group expressed some misgivings about the need for this command, though some situations in which it would be useful were raised. The current WHOIS++ server handle syntax was proposed to be replaced by an object identifier (OID). OIDs already have a distributed registration procedure. The group agreed this was a good idea. Patrik is to produce a draft by Dallas detailing results of the ongoing WHOIS++ pilot's scalability. CIP The WHOIS++ discussion led into the common indexing protocol discussion, where several issues were raised. First, the group felt that the current CIP draft still has some WHOIS++ dependencies that should be removed. These include the QUERY part of the centroid selection, which allows a WHOIS++ query, and the tuple used to identify the server from which a centroid came. It was suggested, and the group agreed, that this tuple be replaced by a URL, pointing to the server. On the subject of CIP use in non-WHOIS++ protocols, the group felt that a separate draft should be produced for each protocol specifying how it should use CIP. There was some discussion of scaling issues with CIP, and the consensus of the group was that the only way to resolve the issues is to pilot the service and gain some experience with it as it grows. A draft should be produced detailing the results of these experiments. Chris Weider is to revise the CIP draft by Dallas X.500 Roland Hedberg presented his draft for storing PGP information in the X.500/LDAP directory. There was general agreement that this was a good thing to do, and the group agreed, based on discussion on the list, that the syntax for the pGPKey should be IA5String, which would allow ASCII-armored PGP Keys to be stored in the directory exactly as they are produced by the PGP software. Roland is to revise his draft and experiment with the new format. Ed Reed of Novell was not able to attend the meeting and raise the X.500 issues he wanted addressed. But the group did have a brief discussion on the problem of storing 93 schema information in the tree. Ed had found the administrative area restriction too confining. The group suggested creating sub-administrative areas that could, in turn, have their own sub-schema definitions. Without Ed there, it was not clear if this addressed his needs. He needs to post his questions to the list again if he wants more discussion. Any Other Business There was no other business, and we ran a little over, so the meeting was adjourned. The next meeting of ASID will be at the December IETF in Dallas, Texas, USA. Summary of Action Items o Tim to submit a charter to the Applications Area Directors for approval. o LDAPv2 volunteers to get cracking and produce a draft by Dallas. o Patrik is to produce a draft by Dallas detailing results of the ongoing WHOIS++ pilot's scalability. o Chris Weider to revise the CIP draft by Dallas. o Roland to revise his draft, for storing PGP information in the X.500/LDAP directory, and experiment with the new format. o Ed to post his questions, concerning X.500 issues, to the list again if he wants more discussion.