NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Kurt Zeilenga <kurt@openLDAP.org>
RL Morgan <rlmorgan@washington.edu>
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Patrik Faltstrom <paf@cisco.com>
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/
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 RFC 2251-2256,2829-2831.
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 |
Dec 00 |
|
Submit LDAP Overview / Data Model I-D |
Done |
|
Submit LDAP Protocol I-D |
Dec 00 |
|
Submit LDAP Attribute Syntaxes I-D |
Done |
|
Submit LDAP DN I-D |
Done |
|
Submit LDAP Filter I-D |
Done |
|
Submit LDAP URL I-D |
Dec 00 |
|
Submit LDAP User Schema I-D |
Done |
|
Submit LDAP Authentication Methods I-D |
Dec 00 |
|
Submit LDAP Start TLS I-D |
Dec 00 |
|
SASL DIGEST-MD5 I-D |
Done |
|
Submit LDAP Applicability Statement I-D to the IESG for consideration as Proposed Standard |
Jun 01 |
|
Submit Implementation Report as I-D |
Jul 01 |
|
Submit LDAP Revised Specification I-Ds and Implementation Report to the IESG for consideration as Draft Standard |
· Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
· Lightweight Directory Access Protocol (v3)
· Lightweight Directory Access Protocol (v3):Technical Specification
· The String Representation of LDAP Search Filters
LDAPBIS meeting notes
50th IETF, Minneapolis, March 21, 2001
Kurt Zeilenga and RL "Bob" Morgan, co-chairs
Kurt called the meeting to order at 9 AM, then reviewed the status of the work.
* Six documents have been submitted for review.
* One (attribute syntax) will have a change of editor.
* The security documents will be reorganized.
* The implementation report needs a fresh start.
* The Digest-MD5 document should be handled by a new SASL working group which is starting up.
* draft-ietf-ldapbis-ldapv3-ts-00.txt is in IETF Last Call.
Kurt noted that overall, good progress has been made but we need to keep up the pace.
Q: Are there known issues with Digest-MD5?
Kurt: Some have been raised regarding security layers. The document should be able to move to Draft Standard.
Jim Sermersheim led a discussion of outstanding issues with the Protocol document.
Section 4.1.11 on Referral says that "All the URLs MUST be equally capable of being used to progress the operation". What does the server have to ensure that all URLs are "equally capable"? Must the server check to make sure all referred to servers are up, accessible, etc? Mark Wahl proposed a definition of "equally capable": if a client picks one of the referrals at random, the client would receive the same information as if it picked any other of the referrals. Several people noted that "equally" implied more knowledge at the server than is necessary, so simply "capable" might be better wording. "Capable" in the data-model sense means "has the necessary data". Kurt asked whether this is necessary for interoperability; perhaps the text should be about how to choose good referrals. This issue will be taken to the list.
Section 4.1.2 says that when a server doesn't recognize a critical control, it "MUST ... return the resultCode unavailableCriticalExtension". But the unbind and abandon operations don't have responses. Should these operations not be performed? Can these operations have critical controls? Kurt proposed that the doc clarify what servers should do: ignore the abandon operation, but perform the unbind. Mark Smith said the doc should note that well-behaved clients SHOULD NOT use critical controls on these operations; many agreed.
The current language in section 4.5.1 regarding use of "subordinates" with "derefInSearching" is consistent with X.511 but may be confusing. The name should be "derefSubordinatesInSearching" to be precise. It was agreed that clarification is needed. It may be appropriate to submit a defect report to X.500.
The terms "anonymous" and "unauthenticated" are apparently used as synonyms; is there a distinction between them? The issue appears to be about interpretation of the simple bind when either the name or password field is empty. It was noted that use of name without password is common so this should be supported. There was dispute about whether such a connection is "anonymous" or not. Bob Morgan noted that this has to be considered in the context of the access control factors discussion in 2829. A four-entry table was presented. There was agreement that the doc should use one term, not two, and that terms should probably be "anonymous". The information from the four-position table should be included.
Section 4.1.5 deals with attribute options and subtypes. There is a need for clarification of these concepts. Are some options, like ";binary", not subtypes? After much discussion there appeared to be consensus that there are two types of options, subtypes and non-subtypes. Skip Slone noted that the X.500 "contexts" concept probably applies here. Do multiple options form a subtype hierarchy? For example, is cn;a;b subservient to both cn;a, cn;b, and cn or is it just subservient to cn? Kurt claimed that language tags depend on the former interpretation. It was suggested that language tags might have to change to avoid this. An engineering team was to be convened to consider the issues in more detail. This issue might be substantive enough to recycle the specification as a Proposed Standard, but we don't know yet.
Language in section 3.4 on subschemaSubentry should be reworded to indicate that it is a single-valued attribute pointing to the schema entry for the Root DSE. There was discussion of the poor state of schema discovery in today's clients. Ed Reed noted that LDUP has a concrete requirement for schema discovery prior to replication; but that subschema administration needs to be done some other way. Mark Wahl proposed removing subschemaSubentry from the RootDSE text in the protocol document and leave this problem to future work (eg the proposed ELSE WG) on schema evolution and administration.
Roger Harrison discussed work on the security documents. He proposed to combine material from RFC 2829 and 2830 with the bind-related text from the protocol document into a comprehensive security document. There was agreement on this approach. There was discussion of "tutorial" material from 2829 and whether it was better in the main text of the document or an appendix; opinions varied. Jeff Hodges suggested including the security state-transition diagram (in text form) that was developed alongside 2830. Roger also suggested adding boilerplate text to the beginning of each ldapbis document tying the set of documents together.
Kurt discussed issues with the DN document. One issue is defining when name strings and when OIDs can be used as AttributeType, in section 2.3. Kurt proposed a "liberal in what you accept, conservative in what you send" principle; this would imply limiting use of name strings to those types listed in that document. Mark Smith noted that some servers just store what's given to them; how can they be "conservative"? Kathy Dally suggested that deployers should be free to use name strings if they agree to do so. Following other discussion, it was suggested that another engineering team be convened for this issue.
In another DN issue, Kurt proposed removing all syntaxes that not specified in the attribute syntax document. Kathy argued that this is a profile of X.500 syntaxes and they should be defined so people can base new syntaxes on them, and that we should be able to clarify without adding new material to the standard. Mark Wahl noted that one syntax was an error and should be removed; others should have been documented in another LDAP RFC that never happened; he suggested removing them. Harald Alvestrand noted that DHCP had similar issues about a standard referring to non-standard items; he recommended removing them also.
Mark Smith led discussion of issues with the filter and URL documents. The filter ABNF needs updating to use AssertionValue instead of LDAPString for SubstringFilter, conforming to the protocol change. Following this it should be ready for Last Call. It was noted that documents can proceed through WG and IETF Last Call prior to adding boilerplate text that will happen when all docs are finished. ABNF cleanups were also done for the URL document. Mark proposed, and there was consensus, that extensions dealing with TLS or SASL or userinfo@host:port or various search parameters were out of scope since they would be new work. This document also appears to be ready for Last Call following a little cleanup.
Kurt noted that the Implementation Report still must be done.
Document authors are encouraged to scan their documents for features for which no implementations exist, for likely removal.
Q: What happened to the glossary/dictionary document?
Mark Wahl: It timed out; this material will be included in data model document.
The meeting adjourned at 11:30.