Last Modified: 2004-02-02
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)
| 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 |
| RFC | Status | Title |
|---|---|---|
| RFC3377 | PS | Lightweight Directory Access Protocol (v3):Technical Specification |
| RFC3383 | BCP | Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
IETF ldapbis WG meeting notes IETF 59, Seoul, South Korea 2004-03-02 submitted by: RL "Bob" Morgan also thanks to Alexey Melnikov for Jabber scribing 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 case. 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 |