Editor's note: These minutes have not been edited. Access and Searching of Internet Directories WG Meeting Meeting Minutes Wednesday, June 26, 1530-1730 - Agenda review/changes The proposed agenda was accepted with minor reordering of some items. - application/directory MIME type drafts - application/directory framework Tim reported that the application/directory framework draft had received several minor comments which would be incorporated into the next version. The group agreed that after these changes are incorporated, the draft should go forward as a proposed standard. ACTION: Tim to produce a new version of the draft and submit it for proposed standard. - versit/pdi vcard profile Patrik Falstrom led the discussion of a number of problems/changes he has encountered with the vcard profile and application/directory framework. The issues included: - Character set: The default is currently 7-bit ascii. The group agreed that this default could safely be changed to UTF-8, since it is a superset of 7-bit ASCII, and since there were alternate methods of selecting character set within the specification already. - Encoding mechanism: The default is currently 7-bit clean encoding. The group agreed to change the default to 8-bit encoding, with the appropriate MIME or application/directory field-specific encoding to be used if a 7-bit encoding was required. - Linebreaks: The current versit vcard draft states that CR, LF, and CRLF sequences should all work as line break sequences. Frank Dawson confirmed that the intention here was to do the same thing RFC 822 does by allowing whatever end-system representation was natural, but using a canonical representation on the network. Frank, Patrik, John Myers, and Dave Crocker agreed to come up with clarifying wording for the draft. ACTION: Frank, Patrik, John, and Dave to clarify wording in the vcard draft. In the course of the discussion, Dave Crocker volunteered to write up a separate Internet Draft describing how to handle the linebreak problem in the general case, since it appears to be something many people have run into before. ACTION: Dave to produce "how to handle linebreaks" draft. - Timezone representation: The current draft allows a number of timezone representations. The group agreed to standardize on always using the single format defined in RFC 822. ACTION: Frank and Tim to produce a new version of the vcard draft with above revisions. - Brief status of standards track documents - WHOIS++ documents Patrik Falstrom reported that revisions to the WHOIS++ documents are on hold pending the outcome of the FIND group, to determine how the indexing portion of WHOIS++ will change when using the common indexing protocol. - LDAPv2 documents Revised drafts have been submitted. One issue was raised regarding the language describing how T.61 strings are encoded in the attribute draft. Harald was volunteered to come up with some better language. It was also noted that the protocol version number (2) was not mentioned in the attribute draft. Tim volunteered to fix this. ACTION: Harald to produce revised T.61 language. ACTION: Tim to revise drafts and resubmit. - labeledURI objectclass/attribute The IESG objected to the definition of two attributes in the draft. The group agreed to revise the draft as the IESG requested, standardizing on only one attribute (labeledURI), mentioning the other as historical. After this revision, the draft will be put forward for proposed standard. ACTION: Mark Smith to revise the labeledURI draft and resubmit. ACTION: Harald to submit revised labeledURI draft for proposed standard. - PGP objectclass/attribute Roland reported that he had received no comments on the latest version this draft, except from David Chadwick, who pointed out that the draft does not allow storage of multiple certificates. Roland and David volunteered to work this out offline and submit a new version of the draft. The group agreed that once these changes are made, the draft should go forward for proposed standard. ACTION: Roland and David to revise the pgp draft to handle multiple values and resubmit for proposed standard. - WHOIS++/WHOIS/RWHOIS URL formats The group agreed that each scheme deserved its own URL prefix, and decided on the following three prefixes: whois:, rwhois:, whois++:. There was some discussion of whether the "++" in the whois++ prefix would break any existing implementations. The characters are URL- legal, and the only problem people could think of was with some C++ preprocessors, which the group doubted were in wide use as HTML- parsing or generating tools. ACTION: Martin to submit a revised whois++ URL draft. - LDAPv3 - Summary of changes from version 00 to version 01 Mark Wahl presented a summary of changes between version 00 and version 01 of the drafts. Changes include: - subschema subentries: Addition to allow schema elements to be stored in the tree itself, accessible as a group or from individual entries. - manageDsaIT service control: Allows knowledge references within a server to be manipulated, rather than the entries they reference. - preferredLanguage service control: Allows the client to select a preferred language. There was some discussion of the scope of this service control, and the group agreed it should apply to attribute values as well as error messages. An issue was raised on the list that language was not enough to solve this problem. One also needs to know the representation of the language (e.g., Kanji or Roomaji for Japanese). - multi-stage binds: Allows a general challenge-response bind mechanism. There was discussion as to why LDAPv3 did not use SASL (Simple Authentication and Session Layer) for authentication. Discussion focused on two issues: 1) Does the LDAPv3 bind mechanism support the same functionality as SASL? John Myers thought not, but Mark Wahl thought yes, with the use of other credentials in the LDAPv3 bind. 2) Is SASL appropriate for inclusion in the LDAP protocol? There was much discussion, and the group agreed to continue discussion on the list. ACTION: John Myers to send a summary of his concerns to the list to stimulate discussion. - binary attributes requested with ";binary": Allows a client to request that any attribute be sent back in binary (BER-encoded) mode. Servers are only required to support some attributes in this format (certificates and the like). If a server does not support ;binary for an attribute, it should act as if the attribute does not exist. - paged results from search: Allows a client to request search results a page at a time, and to move around arbitrarily within the result set. - modifyRights: This is currently a protocol addition. The suggestion was made on the list that this be an operational attribute rather than protocol extension. There was much debate over this, but in the end the group agreed that this was marginal functionality and should just be removed. - add entry target system: From X.500, an extra parameter to the add request that allows an entry and its knowledge reference to be added to separate DSAs in a single operation. There was much discussion over whether this was needed. There were two objections: 1) The current form was X.500-specific, and included a presentation address; 2) The same functionality could be provided by multiple operations using the manageDsaIT service control. On the pro side, it was pointed out that X.500 already uses this feature to solve a problem and why can't we use the same thing? The group agreed to continue discussion on the list. ACTION: Tim to revive discussion on the list. - mapping onto SSL: A short section of the document was added describing how to map LDAP onto an SSL connection. There was some discussion as to whether SSL or TLS (Transport Layer Security) was the appropriate thing to be mentioning here. The group agreed that TLS should be added as soon as a stable document was produced that we could reference. - Discussion of dynamic directory support There was much discussion on this topic, which involves whether LDAP should be extended to support dynamic directories. A dynamic directory is one whose data changes frequently, and must be refreshed often. The prototypical application for this is a directory containing the current IP address of users who dial in or are otherwise mobile. There were several issues raised during the discussion. First, does support for this belong in LDAP? Several people at the meeting had implemented separate dynamic directory schemes only to find that they ended up duplicating much of the functionality already found in LDAP. Based on this experience, they felt that the small extensions necessary to LDAP to support the required functionality were a good idea and well worth the price. Arguments against include the fact that LDAP is based on the X.500 models, which define a static directory, and the added complexity that dynamic directory support would introduce. Second, how should this functionality be included? There were three proposals, with variants, put forward. The first was to extend the protocol with a new "refresh" operation allowing a client to continually tell a server that it is still alive. Responses would also be extended so the server could tell a client how often to refresh. Information from a client that does not refresh would be deleted from the directory. The second was to use the existing modify operation to maintain dynamic directory information. In this scheme, the "refresh" operation is accomplished by a normal LDAP modify operation. The server could communicate the refresh time to the client in an operational attribute the cient reads using the search operation. The third was to define extended operations using LDAP's extensible operation capability to handle this situation. Objections to the first scheme were primarily related to the added protocol complexity it introduces. Objections to the second scheme centered around the abuse of the LDAP modify operation. Third, how often must refresh occur? The answer to this question depends in part on the application, how many clients are using the directory, etc. The wide variety of answers to this question led to the requirement that the server be able to tell clients how often it would tolerate refreshes. Much discussion ensued, which had to be cut short for lack of time. The group agreed to continue the discussion on the list. ACTION: Tim to revive dynamic directory discussion on the list. - Discussion of typeless DN support This discussion item had to be cut due to lack of time. The group agreed to discuss it on the list. ACTION: Tim to revive typeless DN discussion on the list. ACTION: Mark to revise the drafts to reflect consensus reached at the meeting and during subsequent mailing list discussion. - Any Other Business The meeting concluded, slightly late, with an agreement to meet again in San Jose.