CURRENT MEETING REPORT Access and Searching of Internet Directories Meeting Minutes Reported by Tim Howes <tim@umich.edu> Agenda review/changes o The Chair apologized for getting the agenda out so late, and for not producing a proper document archive. o The proposed agenda was reviewed and accepted without changes. WHOIS++ status o Patrik Falstrom gave a brief status report on the WHOIS++ query protocol documents. They have been submitted to the Area Directors for proposed standard status and should be reviewed at the next IESG meeting. o ACTION: Harald is to submit WHOIS++ documents for proposed at the next IESG meeting. CIP status o A new working group (FIND) is forming to define the Common Indexing Protocol and the BOF met just before the ASID meeting. ASID will drop this item from its charter. LDAP status LDAP has been at draft standard status since last March and the group discussed whether LDAP is ready to progress to full standard. There are multiple independent interoperable implementations. There was a question raised as to whether the Kerberos BIND credentials were supported by any implementation other than the one from University of Michigan. The group agreed that this question should be resolved before LDAP goes forward and Tim agreed to try and find out. There was another question raised as to whether LDAP had seen enough operational experience. The consensus of the group was that it has. There was some confusion in the group about the difference between the LDAP protocol and the widely--used University of Michigan implementation of LDAP. The LDAP protocol has had one version change. It went from version 1 to version 2 when the MODRDN operation changed. There have been several versions of the U--M implementation of LDAP released, the most recent of which is version 3.2. Earlier UM releases had some bugs in the BER encoding that were hampering interoperability with conformant LDAP implementations. These bugs have been fixed and the implementations now interoperate, though there are still some old implementations out there. There was also some confusion as to what exactly was being proposed for full standard. Again this appeared to stem from confusion between the LDAP protocol as a front--end to the X.500(88) directory as defined in RFC 1777 and RFC 1778, and the University of Michigan implementation of LDAP, which includes some experimental extensions transparent to existing LDAP clients for doing stand--alone LDAP, passing back referrals, indexing information, etc. It is only the former that is being considered for standardization. The latter are only useful experiments that will hopefully feed into the design of the next version of LDAP. ACTION: Tim is to check on implementations of kerberos LDAP BIND credentials and put LDAP up for full standard if there are others that interoperate. LDAP URL format draft At the last meeting, the LDAP URL format draft was approved by the group, provided that it be passed by the URI Working Group for review. This was done, to little comment, and the group now suggests that the draft, after it is passed by Harald's URI checklist, be progressed as proposed standard,. ACTION: Tim is to submit LDAP URL format draft to the Area Directors for progression as proposed standard. labeledURI draft At the last meeting, changes to Mark Smith's labeledURI draft were discussed. The group consensus was that both labeledURI and labeledURL attributes were useful. Mark changed the draft to incorporate both attributes. The group agreed that with these changes the draft should be progressed as proposed standard. ACTION: Tim is to submit labeledURI draft to the Area Directors for progression as proposed standard LDAP/X.500 caching draft The group agreed that the caching draft was useful, but that the function would be better served by creating an operational attribute, rather than a user attribute to hold the TTL information. Some reservation was expressed about the work, since this is an area the X.500 standard has intentionally avoided. The group agreed that this draft should be revised and progressed as experimental. ACTION: Tim is to revise caching draft and circulate to the list for comment. application/directory MIME type draft Several comments on the application/directory MIME type draft since the last meeting have been incorporated, but a new version of the draft has not yet been submitted. Changes include the addition of a home fax number and a change to using multipart/related rather than multipart/mixed. There was some discussion of potential uses for this draft, from the straightforward carrying of directory information in email from a simple directory query responder, to use as a method of carrying directory synchronization information, to the provision of directory information over HTTP. There was general agreement the draft was useful. Concern was expressed that the draft defines both a general framework for carrying directory information and the specific content relating to a person. The issue is that the person information implies some schema which should be harmonized across all directory services, if this draft is to be useful as a general mechanism for carrying information. This schema harmonization is already being tackled by the IDS group. The suggestion was made, and the group agreed, that the draft be split into two. One draft would define the MIME type and general framework for carrying directory content of different types. The other draft would define the content for person directory information. A third draft was proposed to define the necessary content for handling directory synchronization applications. ACTION: Tim is to split the application/directory MIME type draft into two drafts (one framework, one person information). ACTION: Greg Vaudreil and Ed Reed are to write an application/directory MIME type content draft for directory synchronization. leaf/nonleaf draft This draft was withdrawn by the authors (with the blessing of the group), since it had been pointed out on the list that the main function of distinguishing leaf from non--leaf objects could be done by using an already defined X.500(93) operational attribute. String encoding of presentation address draft The string encoding of presentation address draft has been revised by Steve Kille to support the new IPv6 addressing scheme. The group agreed that the draft should go forward, provided that it be circulated to the ASID list for comment. The document is a product of the TOSI groupand is not in the ASID charter. ACTION: Steve is to circulate the presentation address draft to the list. Storing PGP attributes in the directory draft Roland Hedberg gave a brief presentation on his draft defining an object class and attributes for storing PGP certificates in the LDAP/X.500 directory. The presentation prompted much discussion. The debate focused on whether it is better to store certificates in the directory directly, or to store a URL pointing to the certificate in a PGP key server. The primary advantage of the latter method is one of easier maintenance. If the user needs to maintain their key(s) in a PGP key server anyway, the added administration and potential for inconsistency introduced by storage in the directory is a bad thing. On the other hand, storing only a pointer in the directory places an extra burden on clients, which will have to implement an additional access protocol to retrieve the key from the PGP key server. The group was fairly evenly divided between the two approaches, prompting the suggestion that the draft be changed to define attributes appropriate for both solutions. The market could then decide which was better. ACTION: Roland is to revise the PGP draft to incorporate both solutions, and post the revised draft to the list. SUM500 draft Vincent Berkhout gave a brief presentation of his SUM500 draft, which defines a method of mining the Web and other information services for X.500 information. Vincent's idea involves using standard HTML pages that, if present on an organization's web server, could be read and parsed to produce organization and people entries for the X.500 directory. The group thought the draft useful, and there was discussion of Vincent's proposal to rewrite the draft to use the application/directory MIME type as the standard format. ACTION: Vincent to revise the draft to reference the MIME type draft, and post the revised draft to the list. LDAP API RFC 1823 Tim announced that informational RFC 1823, which documented The University of Michigan LDAP API, was available. The information was presented to the group for informational purposes only, though a short discussion ensued about the appropriateness of doing API work in the IETF. LDAPv2 presentations and discussion Dave Horvath of Chromatix gave a presentation on the US Navy's work to produce a secure version of LDAP. The Navy's approach was to implement MDAP (Minimal DAP--essentially full DAP PDUs over some other transport mechanism) as extensions to LDAP. Their implementation is called SLDAP (Secure LDAP), and it supports strong authentication and end--to--end digital signing of search operations and results. Dave described how they produced a new Windows LDAP DLL that implemented the protocol extensions and used the Fortezza card for signing. The DLL approach means that existing Windows LDAP clients can be used unmodified with the new DLL and still receive the benefits of strong authentication and signed operations. Kevin Jordan gave a brief description of the extensions that CDC has made to their implementation of LDAP to support some X.500(93) operations. The extensions include the addition of a ModifyDN operation, an operation to add a context prefix, and the ability to set new operational parameters, such as the dontUseCopy service control. There were general apologies from the Chair and several other working group members because of the general lack of progress made since the last meeting on the LDAPv2 document. More promises were made for a draft by the next meeting. ACTION: LDAPv2 volunteers to get cracking and produce a draft by the next IETF. AOB No other business was presented, so the group adjourned almost on time, agreeing to meet again at the next IETF in Los Angeles.