Tim Howes <howes@netscape.com>
Patrik Faltstrom <paf@swip.net>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
General Discussion: ietf-asid@umich.edu
To Subscribe: ietf-asid-request@umich.edu
Archive: ftp://terminator.rs.itd.umich.edu/ietf-asid/archive
There is a clear need to provide and deploy a well managed Directory Service for the Internet. A so-called White Pages Directory Service providing people and organizational information is especially long overdue. While the ultimate goal is a general Directory Service for the Internet, this is too ambitious a goal to be tackled by a single working group. Therefore ASID will keep a tight focus on access and synchronization protocols for an Internet White Pages Directory Service. Other related working groups will be formed in the Applications Area that will deal with other aspects of the Internet Directory Service.
Currently there are various protocols under development in the Internet that aim to provide such a service: Internet X.500, WHOIS++, NETFIND, CSO, RWHOIS, etc. To allow these services to evolve to a ubiquitous Internet Directory Service, a hybrid system that allows interaction between the various different services is a requirement.
The ASID Working Group will define, evolve, and standardize protocols, algorithms and access methods for a White Pages Directory Service on the Internet.
The following protocols (some still under development, some completed by other IETF working groups) will be considered by the working group:
· Lightweight Directory Access Protocols (LDAP and Connectionless LDAP) · User Friendly Naming (UFN) and User Friendly Searching (UFS) · The SOLO directory access and searching system · The WHOIS++ directory service
The following work items are handled by other groups, and as such are outside the scope of this group. However their results are important to the development of a White Pages Directory Service, and will be taken into account:
· The Hypertext Transfer Protocol (HTTP) · The UR* definitions · The NETFIND directory service
The group will focus on harmonizing, evolving and developing protocols and algorithms that deal with access to and synchronization of Directory Service, both ad hoc and standards-based, with a goal of converging where possible towards a hybrid system that ties together various forms of Directory Service. Clearly, protocol-level integration is only part of the solution. To keep this group tightly focused, other working groups will tackle harmonizing directory information and service models.
Goals and Milestones:
· A MIME Content-Type for Directory Information
· Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
· Lightweight Directory Access Protocol (v3)
· vCard MIME Directory Profile
· Lightweight Directory Access Protocol: Extensions for Dynamic Directory Services
· Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
· An Approach for Using Domains in LDAP Distinguished Names
· A String Representation of LDAP Search Filters
· Use of Language Codes in LDAPv3
· Definition of the inetOrgPerson Object Class
· The LDAP Data Interchange Format (LDIF)
· Architecture of the WHOIS++ service
· Definition of an Object Class to Hold LDAP Change Records
· Selecting a server from among many replicas
· LDAP Control Extension for Simple Paged Results Manipulation
· Lightweight Directory Access Protocol: Schema for Storing RPC Entries in a Directory Service
· LDAP Multi-master Replication Protocol
· The String Representation of LDAP Search Filters
· LDAP-based Routing of SMTP Messages: Approach Used by Netscape
· LDAP-based Routing of SMTP Messages: Approach at Stanford University
· X.500 Strong Authentication Mechanisms for LDAPv3
· A Summary of the Pilot X.500 Schema for use in LDAPv3
· A Summary of the X.500(93) User Schema for use with LDAPv3
· An Approach for Using LDAP as a Network Information Service
· LDAP Control Extension for Server Side Sorting of Search Results
Request For Comments:
Minutes of the Access and Searching of Internet Directories Working Group
Reported by: Tim Howes and Patrik Faltstrom
Patrik Faltstrom was welcomed as the new co-chair of ASID.
The proposed agenda was accepted without change.
I. Hour One: LDAPv3 Core Documents
The following documents were discussed with the goal of making any minor changes, 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 discussion of the master/slave designation added to the LDAP URL draft (draft-ietf-asid-ldapv3-url-00.txt). The group felt that this is not a good thing, in the absence of a replication model, and since it does 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) needs 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, although thought generally useful, is not a must-have at this time. The user Password syntax should be deprecated and discussed in the security consideration 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 discussion of the Protocol draft (draft-ietf-asid-ldapv3-protocol-04.txt). Most of the discussion centered on the use of SASL in the document and whether it is correct. The following consensus was arrived at:
· The SASL credentials should be OPTIONAL
· No SASL mechanism name should be included on the BindResponse
· Some language is needed advising that changing the SASL authentication layer during an LDAP session is allowed, but changing the SASL security layer is not allowed.
Nick Emery raised an additional point 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 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) is 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 as soon as possible.
There was 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 is whether this will 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 are revised (estimated time to revise: one 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.
II. Hour Two: MIME-DIR and WHOIS++
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 such a 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 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 contentious 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 is 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 debate, the group decided to remove the "charset" attributes 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 is thought to be a good thing.
ACTION: Tim to produce a new MIME-DIR draft with the agreed changes.
ACTION: Tim and Patrik to progress the revised draft to the area directors.
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 identifies 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 discussion of where we should draw the line before putting vCard forward as a proposed standard. After further 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.
III. Hour Three: Various LDAP Documents
This hour began with the daunting task of listing the 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 change log 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 attempt discussing all the documents, but rather to spend the first part of the meeting deciding what to discuss. The group decided that the two email routing documents are outside the scope of ASID, so they were crossed off the list.
The group next decided that replication is 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 a great deal of 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 offline 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 one quickly consensized on a decision that replication is definitely a problem that we should be tackling.
Debate on question two was somewhat tangled up with the scope of the work. Some people felt that replication is a big and separable enough problem that a separate working group is required. Others feel that replication will 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 three generated much 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 is concern that to make any progress we should try to focus the problem as narrowly as possible. After much discussion, the group agreed that we should narrow our focus to LDAP replication and not try to solve the more general problem.
After 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 the two documents did, in fact, overlap, and that everything needed in Paul's document is present in the DNS SRV record document.
ACTION: Paul Leach to follow-up with the DNS group.
ACTION: Tim and Patrik to follow-up the group-splitting issue with the area directors.
Noting the lateness of hour, the general glazed look of the participants, and the fact that another meeting's attendees began filing into the room, the ASID meeting concluded. The next ASID meeting will be in August in Munich, Germany.