2.1.5 LDAP (v3) Revision (ldapbis)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.openldap.org/ietf/ldapbis/ -- Additional LDAPBIS Web Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-02

Kurt Zeilenga <kurt@openLDAP.org>
RL Bob Morgan <rlmorgan@washington.edu>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ted Hardie <hardie@qualcomm.com>
Mailing Lists:
General Discussion: ietf-ldapbis@openldap.org
To Subscribe: ietf-ldapbis-request@openldap.org
In Body: (un)subscribe
Archive: http://www.openldap.org/lists/ietf-ldapbis/
Description of Working Group:
The LDAPv3 "core" specification is RFC 2251-2256 and 2829-2831. The purpose of this working group is to shepherd these RFCs through the Internet Standard process.

The group will deliver revised LDAPv3 specifications suitable for consideration as a Draft Standard. This work will be based upon RFCs 2251-2256, 2829-2831.

The group will deliver a document detailing IANA considerations for LDAP suitable for consideration as a Best Current Practice.

The group will deliver an applicability statement defining LDAPv3. This work will be based upon draft-hodges-ldapv3-as-00.txt.

The following areas are out of scope: - "LDAPv4"

- All LDAP Extensions (LDAPext) excepting StartTLS.

- LDAP Replication (LDUP)- LDAP non-"core" Schema

- Connection-less LDAP (LDAPext)

Goals and Milestones:
Done  Submit LDAP Applicability Statement I-D
Done  Submit LDAP Overview / Data Model I-D
Done  Submit LDAP Protocol I-D
Done  Submit LDAP Attribute Syntaxes I-D
Done  Submit LDAP DN I-D
Done  Submit LDAP Filter I-D
Done  Submit LDAP URL I-D
Done  Submit LDAP User Schema I-D
Done  Submit LDAP Authentication Methods I-D
Done  Submit LDAP Start TLS I-D
Done  Submit LDAP Applicability Statement I-D to the IESG for consideration as Proposed Standard
Done  Submit IANA Considerations for LDAP I-D to IESG for consideration as BCP
Sep 03  Deliver revised LDAP
Sep 03  Deliver revised BCP 64 I-D to IESG for consideration to the IESG as a BCP
Oct 03  ubmit Interoperability Report I-D
Apr 04  Deliver Interoperability Report to IESG with recommendation that revised LDAP
  • - draft-ietf-ldapbis-dn-13.txt
  • - draft-ietf-ldapbis-protocol-22.txt
  • - draft-ietf-ldapbis-filter-06.txt
  • - draft-ietf-ldapbis-authmeth-10.txt
  • - draft-ietf-ldapbis-url-05.txt
  • - draft-ietf-ldapbis-syntaxes-07.txt
  • - draft-ietf-ldapbis-roadmap-04.txt
  • - draft-ietf-ldapbis-models-10.txt
  • - draft-ietf-ldapbis-strprep-03.txt
  • - draft-ietf-ldapbis-bcp64-02.txt
  • Request For Comments:
    RFC3377 PS Lightweight Directory Access Protocol (v3):Technical Specification
    RFC3383BCPInternet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)

    Current Meeting Report

    IETF ldapbis WG meeting notes
    IETF 59, Seoul, South Korea
    submitted by:  RL "Bob" Morgan also thanks to Alexey Melnikov for Jabber 
    The meeting was called to order at 1545 by the chairs, Kurt Zeilenga and RL 
    "Bob" Morgan.
    The first agenda item was WG status.  Kurt noted that only two 
    documents are still being worked on.  The protocol document 
    (draft-ietf-ldapbis-protocol-22.txt) is very close to being done.  Its 
    editor, Jim Sermersheim, will submit one more revision, and a last call 
    will be done.  The authmeth document 
    (draft-ietf-ldapbis-authmeth-10.txt) still needs review and revision.
    Jim Sermersheim talked about items regarding the protocol document.  A 
    number of items have had discussion on the WG list.  The issue about 
    "attributes with no equality matching rule" should be handled by an 
    update to the draft-ietf-ldapbis-models document.
    There was discussion about the "server-enforced control 
    criticality" issue raised by Hallvard Furuseth, which has seen lots of list 
    discussion: what does a server do if a client sends a control with its 
    criticality flag set differently than specified in the control's 
    definition?  Hallvard has said (on the list) that the server should 
    return an error.  It was asked whether this is useful in real 
    operations or only in debugging.  Hallvard will be requested to supply a 
    real-life use case.  It was noted that if Hallvard's suggestion is 
    adopted some existing servers will have to change their behavior; 
    whereas there are no known implementations that work in the way 
    Hallvard is suggesting.
    Jim said that another remaining change is that some text is still 
    planned to move from the protocol doc to the authmeth doc.  A 
    last-callable version of -protocol- can be published as soon as the 
    criticality issue is resolved.
    Jim went on to talk about the authmeth document, for Roger Harrison who 
    couldn't attend.  Outstanding items include: clarifying that password 
    considerations apply only to plaintext passwords being sent in the clear; 
    moving language about mandatory-to-implement features to its own 
    section; and removing the statement that anonymous authentication is 
    typical when not updating.  Another item is about STARTTLS 
    sequencing: the logical requirement is that clients have to wait for all 
    operations to finish before sending STARTTLS, but some clients are known not 
    to.  The current spec has language saying what might happen in this case, 
    but the proposal is to clarify the situation by saying simply that 
    clients MUST wait.
    Another clarification is proposed regarding choice of SASL mechanisms 
    (section 8.5).  New language would say that client and server must 
    confirm that negotiated security level meets their requirements before 
    proceeding to use the connection.
    Roger is working on a new version, and should publish soon.  Kurt 
    emphasized that the document needs good review from the WG before it can be 
    taken to last call, so please review!
    In other issues: Kurt proposes that the LDAP handling of missing equaity 
    matching rules conform to the X.501 approach.  This is a change from 
    current LDAPv3 spec, but appears to be what is done by known 
    implementations.  It was asked whether the models document needs another 
    last call, and noted that some other 
    already-through-last-call documents have had minor tweaks to them.  There 
    will be an all-documents last call before they are sent to IESG in any 
    Kurt also asked whether matching rules that are in RFC 3698 should be 
    added to the syntaxes document.  These are in X.520, and have been in use.  
    JimS asked whether any of these will be mandatory to implement.  In 
    response it was asked whether the current doc says that any syntaxes are 
    mandatory; this will be looked at.
    Lastly milestones were discussed.  The intent is to finish the protocol 
    document in March, the authmeth document in April, and to finish the 
    roadmap and final last call for all in May, and submit the package to the 
    IESG.  Then an interop report could be prepared for 6 months following 
    approval of the documents as RFCs.
    The meeting was adjourned at 


    LDAP Protocol
    LDAP Authentication Methods