Editor's Note: These minutes have not been edited. Access and Searching of Internet Directories WG Meeting Meeting Minutes Wednesday, April 9, 1545-1800, 2000-2100 Reported by: Tim Howes and Patrik Faltstrom - Introduction of new co-chair Patrik Faltstrom was welcomed as the new co-chair of ASID. - Agenda review/changes The proposed agenda was accepted without change. - Hour 1 1545-1700: LDAPv3 core documents The following documents were discussed, with the goal of making any minor changes needed, issuing a last call, and putting the documents forward for proposed standards status. draft-ietf-asid-ldapv3-protocol-04.txt draft-ietf-asid-ldapv3-attributes-04.txt draft-ietf-asid-ldapv3-dn-00.txt draft-ietf-asid-ldapv3-filter-00.txt draft-ietf-asid-ldapv3-url-00.txt There was some discussion of the master/slave designation added to the LDAP url draft draft-ietf-asid-ldapv3-url-00.txt. The group felt that this was not a good thing, in the absence of a replication model, and since it did not fit well into the general URL concept. ACTION: Tim to revise the URL draft to remove this feature. There were no revisions proposed to the filter draft draft-ietf-asid-ldapv3-filter-00.txt. Chris Newman commented that the string dn format draft draft-ietf-asid-ldapv3-dn-00.txt needed some revision of its ABNF. ACTION: Chris to send proposed ABNF revisions to Mark (DONE). ACTION: Mark to produce a new DN draft. The following comments were made on the attributes draft draft-ietf-asid-ldapv3-attributes-04.txt. The draft needs a keyword index, to make it easier to find things. The keyword index, though thought generally useful, was not a must-have at this time. The userPassword syntax should be deprecated and discussed in the security considerations section. The audio syntax, which currently refers to the "SunOS 4.x format" should either be updated to reference audio/basic, or removed. ACTION: Mark to produce a new attributes draft with these changes incorporated. There was a fair amount of discussion on the protocol draft draft-ietf-asid-ldapv3-protocol-04.txt. Most of the discussion centered around the use of SASL in the document and whether it was correct. The following concensus was arrived at: - The SASL credentials should be OPTIONAL - No SASL mechanism name should be included on the BindResponse - Some language was needed advising that changing the SASL authentication layer during an LDAP session is allowed, but changing the SASL security layer is not allowed. An additional point was raised by Nick Emery about the handling of unknown filter components in searches. The current draft says such components are to be treated as though they match no entries. This leads to the undesirable result that a filter searching for (!(unknown component)) returns all entries. After some discussion, the group agreed to adopt the tri-state logic used by X.500. Jeff Hodges suggested a number of clarifications in the text describing subschema subentries and extensible matching. Another discussion topic involved the lack of protocol encoding examples in the draft. Examples of on-the-wire client/server interactions were thought to be very useful, and a pretty standard part of many other Internet protocol specifications. Mark Wahl stated that he is working on a separate document explaining the basics of BER encoding needed by LDAP. This document will contain somewhere between 8 and one hundred examples. Since BER encoding is (unfortunately) more complicated than many of the simple text encodings used by other protocols, a separate document (or perhaps appendix to the protocol document) was thought to be the best approach. To avoid holding back LDAPv3 at this time, the group agreed that the document should go forward, with examples being added when the document goes from proposed to draft. The group also discussed the fact that the LDAPv3 drafts referenced the SSL specification, which is not an Internet standard. The group agreed that the goal is to reference the TLS specification when it becomes available. The status of TLS was not known, but it was thought that it should be moving forward soon. The group agreed to change the LDAPv3 reference to TLS in anticipation of the TLS specification being progressed along with LDAPv3. There was further discussion of the relationship between SASL and TLS, and that the lack of clarity on that relationship is contributing to the slow progression of SASL. The group agreed that this relationship should be clarified ASAP. There was also discussion about the fact that the LDAP documents reference the X.500 standard in many places, and that X.500 is not freely available on the net. The question was whether this would prevent the drafts from progressing. Based on precedents set by SNMP and other IETF work, the group did not feel this should be a problem. ACTION: John Myers to work with the security area director and the TLS group to clarify the SASL and TLS specs. ACTION: Mark to produce a new protocol draft with these changes incorporated. ACTION: Tim and Patrik to ensure that examples are included before LDAPv3 goes to draft standard. The group agreed that after the documents were revised (estimated time to revise: 1 week), last call should be issued on the ASID list. At the conclusion of a successful ASID last call, the documents should be given to the area directors for approval of the IESG. ACTION: Tim and Patrik to issue last call to ASID on revised documents. ACTION: Tim and Patrik to request progression of the documents pending successful ASID last call. - Hour 2 1700-1800: MIME-DIR and WHOIS++ - WHOIS++ drafts Patrik reported that new WHOIS++ drafts have been produced with no protocol changes, only revisions and clarifications from operational experience implementing the protocol. One example of a such clarification is the addition of a grammar for the output from a Whois++ server to the existing grammar for the input to a Whois++ server. The group agreed that a last call should be issued on the revised documents, after which they should be put forward for draft standard status. ACTION: Patrik and Tim to issue last call on the revised WHOIS++ documents and progress to the area directors. - application/directory framework There was much fruitful discussion of the application/directory framework document. The first issue discussed was whether the content-type should be changed to text/directory. The argument for is that the information is primarily textual in nature and the desired behavior is to have the content-type displayed to users even if the type is unknown. After a brief struggle, the group agreed to change the content-type to text/directory. A more conetentious issue surrounded the use of the "lang" parameter defined in the draft. The values of the "lang" parameter are currently defined to be language tags from RFC 1766. Patrik argued that an additional tag (he proposed calling it "default") was needed to support the use of text/directory in WHOIS++. The tag is needed so that applications (like WHOIS++) may determine which (if any) attributes to return in the event that the language requested by the client is not present. After much debate, misunderstanding, and confusion, it was decided not to add this to the spec. The argument was made that 1) the default solution is not entirely correct, since it does not also provide a way to determine the type of the default language returned, and 2) the parameter set is already extensible, so something could be defined later to solve this problem. The final issue discussed was the use of the "charset" attribute parameter, allowing the character set to be set on individual values within a text/directory content-type. This was felt to be a Bad Thing and contrary to the MIME way of doing things and contrary to the IAB character set proclamation (thou shalt use UTF-8) by several people. After a bit of debate, the group decided to remove the "charset" attribute parameter and require the UTF-8 "charset" MIME header parameter be specified by default on text/directory content-types. The result of this is the loss of ability to switch charsets on a per-value basis within a text/directory component, but this was thought to be a good thing. ACTION: Tim to produce a new MIME-DIR draft with the agreed on changes. ACTION: Tim and Patrik to progress the revised draft to the area directors. - vcard profile One comment received prior to the meeting was the use of English as the default language in the vCard profile. The group agreed that this statement should be removed, and that there should be no default language associated with the vCard profile. Two additions to the vCard profile had been proposed to the ASID list by the MOPA consortium (Mobile Office Promotion Association). The additions were for a CLASS attribute and a PCS property on the TEL attribute. The CLASS attribute would identify the class of the information contained in the profile (e.g., PRIVATE or PUBLIC). The PCS property would identify a TEL attribute as referring to a PCS telephone. The group considered these additions useful, but there was some discussion of where we should draw the line before putting vCard forward as a proposed standard. After a bit of discussion, the group agreed to allow these two additions and then progress the draft to proposed standard. ACTION: Frank Dawson to revise the vCard draft with these changes. ACTION: Tim and Patrik to progress the revised draft to the area directors. - Hour 3 2000-2100: Various LDAP documents This hour began with the daunting task of listing the 15 (count them 15) documents submitted for the group's consideration. The documents were: draft-ietf-asid-ldapv3-lang-00.txt use of language codes in LDAPv3 draft-ietf-asid-ldapv3-strong-00.txt SASL authentication mechanism for X.500 authentication draft-ietf-asid-ldapv3schema-x500-00.txt LDAPv3 definitions of X.500 schema draft-ietf-asid-schema-pilot-00.txt LDAPv3 definitions of pilot schema draft-ietf-asid-ldapv3-simple-paged-01.txt LDAPv3 extension for simple paged results draft-ietf-asid-ldapv3ext-03.txt LDAPv3 extension for dynamic directories draft-ietf-asid-replica-selection-00.txt How to use SRV records to select LDAP servers draft-ietf-asid-ldapv3-sorting-00.txt LDAPv3 extension for sorting results draft-ietf-asid-ldapv3-referral-00.txt referrals and knowledge references in LDAPv3 draft-ietf-asid-ldapv3-api-00.txt Update of RFC 1823 for LDAPv3, etc. *draft-ietf-asid-ldap-mult-mast-rep-00.txt Multi-master replication proposal *draft-ietf-asid-ldif-00.txt LDAP text directory interchange format *draft-ietf-asid-changelog-00.txt LDAP text changelog format draft-ietf-asid-email-routing-su-00.txt draft-ietf-asid-email-routing-ns-00.txt Two email routing using LDAP proposals The group started by agreeing not to try and discuss all the documents, but rather to spend the first part of the meeting deciding what to discuss. The group first decided that the two email routing documents were outside the scope of ASID, so they were crossed off the list. The group next decided that replication was the topic of most interest, with replica selection a close second. So, discussion began on replication with an attempt to answer three questions: 1) Should we be working on directory replication? 2) What group should do the work? 3) What should be the scope of the work? There was much debate on these topics, mixed together with debate about the future of the ASID group. The latter topic was raised with the idea (put forward off-line by the area directors) of splitting ASID into two groups: one for LDAP and one for text directory stuff (WHOIS++, MIME-DIR, etc). The group thought this was basically a good idea. Debate on question 1) quickly consensized on a decision that replication is definitely a problem that we should be tackling. Debate on question 2) was somewhat tangled up with the scope of the work. Some people felt that replication was a big and separable enough problem that a separate working group was required. Others felt that replication would soon drag in other problems (e.g., access control, schema) that really need to be considered by the entire group. Consensus on this issue was rough, at best, but the group seemed to be leaning towards handling replication in ASID (or the as-yet-unformed LDAP group), for the reasons given above. Question 3) generated lots of discussion. The proposals ranged from a general replication solution, to a general LDAP-only solution, to an LDAP-only solution specific to either multi-master or single-master models. There was much concern that to make any progress we should try to focus the problem as narrowly as possible. After much discussion, the group consensificated that we should narrow our focus to LDAP replication, and not try to solve the more general problem. After much further debate with little progress, the group decided to switch gears and discuss one of the other documents. The replica selection document was chosen. Paul Leach described the draft briefly, which defines a method of locating LDAP servers, given a domain name, based on SRV records. The group thought the concept useful, but very similar to a general procedure outlined in a draft from the DNS group for using SRV records. The group agreed that Paul should talk to the DNS group to ensure that they two documents did, in fact, overlap, and that everything needed in Paul's document was present in the DNS SRV record document. ACTION: Paul Leach to follow-up with the DNS group. ACTION: Tim and Patrik to chase the group-splitting issue with the area directors. - Any Other Business Noting the lateness of hour, the general glazed look of the participants, and the fact that another meeting's attendees begain filing into the room, the ASID meeting concluded, about on time. The next ASID meeting will be in August in Munich, Germany.