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:

       Additional LDAPBIS Web Page

Last Modified: 2003-07-03

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-11.txt
  • - draft-ietf-ldapbis-protocol-16.txt
  • - draft-ietf-ldapbis-filter-04.txt
  • - draft-ietf-ldapbis-authmeth-06.txt
  • - draft-ietf-ldapbis-url-03.txt
  • - draft-ietf-ldapbis-user-schema-06.txt
  • - draft-ietf-ldapbis-syntaxes-06.txt
  • - draft-ietf-ldapbis-roadmap-03.txt
  • - draft-ietf-ldapbis-models-08.txt
  • - draft-ietf-ldapbis-strprep-01.txt
  • - draft-ietf-ldapbis-bcp64-00.txt
  • Request For Comments:
    Lightweight Directory Access Protocol (v3):Technical Specification (RFC 3377) (9981 bytes)
    Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) (RFC 3383) (45893 bytes)

    Current Meeting Report

    ldapbis meeting notes
    IETF 57, Vienna, Austria
    submitted by:  RL "Bob" Morgan
    The co-chairs, Kurt Zeilenga and RL 'Bob' Morgan, called the meeting to 
    order at 14:15.
    Kurt noted that the WG charter has been updated to reflect current plans, 
    which call for all remaining documents to go through WG Last Call in 
    July/August, and (assuming consensus) for revised documents to be 
    submitted to the IESG by September.  It is expected that the WG will not 
    need to meet at IETF in Minneapolis.
    Jim Sermersheim spoke about the protocol document.  The "attribute 
    descriptor length" issue has received much discussion on the WG list, and 
    was discussed at length at this meeting.
    Ted Hardie, the WG's Area Director, spoke for ("channeled") Chris Apple, 
    saying that the issue is that designers of LDAP-based applications and 
    schema need interoperable LDAP implementations to support them, and need to 
    know what limits they can design to.  
    Kurt responded that there are two separable issues.  One, the one that 
    started the email thread, is that an implementation was observed to 
    truncate short names; this is just a bad implementation, it may be useful to 
    clarify the doc to make it clear this isn't permitted.  The other is that 
    LDAP can be used in many contexts, so not all features are required or 
    appropriate for all contexts.  Applicability statements are the IETF 
    documents that say which features are required for particular 
    Rick Huber observed that the problem is a protocol 
    interoperability problem, hence should be addressed by the protocol spec.  
    John Strassner observed that lots of schema designers are writing schema 
    with long attribute descriptors (names), and are depending on 
    implementations supporting this.  Kurt observed that other 
    requirements like matching rules will lead to a need for 
    application-specific AS.
    Ted said applicability statements would be fine, and suggested a "basic" one 
    on which variations can be based.
    Leif Johansson asked if implementation-specific limits need to be 
    discoverable?  Ted said that would follow but isn't necessary.
    Rick observed that requiring an application statement per app is a lot of 
    work for app developers.  Kurt said it might be feasible to define a 
    "general-purpose" LDAP AS, but might be hard to get consensus.
    Ted said it seems byzantine to have protocol limits defined 
    separately from the protocol.  Kurt responded that it seems 
    inappropriate to clutter a general-purpose protocol spec with 
    considerations of only one application scenario.
    It was observed that this discussion needs to move back to the mailing 
    Jim requested that people look at the protocols and models documents 
    together for potential overlaps or gaps.  He also encouraged a review of the 
    use of MUST/SHOULD/MAY in the docs.
    Kurt said that since it now appears that our documents will have to be 
    again at Proposed Standard level, interoperability reports can wait until 
    after this, when we prepare to go to Draft Standard.
    Vithalprasad Gaitonde presented for Roger Harrison regarding the 
    authmeth document.  Draft -06 was produced.  It lists various fixes since 
    the previous version in its appendix.  Some issues were discussed.
    Is password protection needed regardless of the use of authzid?
    Is the SASL PLAIN method prohibited in LDAP?  No, just "not typically 
    In the TLS server name check function, should the use of the CN RDN in the 
    Subject DN to hold the server DNS hostname be documented?  RL "Bob" 
    observed that other app-TLS specs have not done this, even though the 
    method is commonly used, because it is such a clumsy mechanism.
    Must the SASL EXTERNAL operation immediately follow completion of 
    STARTTLS?  No, the first operation after STARTTLS should be another check of 
    server capabilities.  The TLS-complete-but-not-bound state may not be in the 
    authentication state diagram.
    Use of derived DNS names OK in the TLS server name check function?  RL 
    "Bob" said that this would be a change from the current RFC, but is 
    consistent with the original intent.
    It was observed that the description of DIGEST authentication in the 
    authmeth doc is too detailed, and may conflict with other specs, so it was 
    suggested to modify it to reduce this.
    Kurt wrapped up the session by noting that once all documents have been 
    through Last Call, there will be a Last Call on the Roadmap document and one 
    more pass over the whole document set for consistency.
    The session concluded at