[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: Summary of proposed changes to [Protocol]

To: "Jim Sermersheim" <jimse@novell.com>
Subject: Re: Summary of proposed changes to [Protocol]
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Date: Thu, 26 May 2005 09:15:24 -0700
Cc: <ietf-ldapbis@OpenLDAP.org>
In-reply-to: <s28d1e1f.082@sinclair.provo.novell.com>
References: <s28d1e1f.082@sinclair.provo.novell.com>
It is my opinion as WG co-chair that these suggested
changes are supported by WG consensus.  Hence, I direct
the Editor to prepare and submit a revision of [Protocol]
with these changes, as well as any necessary editorial
changes.  Upon publication, I intend to advise our AD
that the revised I-D is ready for further IESG consideration.

Kurt

At 10:15 PM 5/19/2005, Jim Sermersheim wrote:
>All,
>
>I have made updates to the Protocol document according to my judgement of Working Group consensus and according to reviews given during the IETF Last Call. Because there are some substantial changes, Kurt suggested I summarize the changes so they can be fully reviewed by the Working Group prior to submitting the document.
>
>Below is the summary of changes, followed by a series of the exact before and after language for each non-trivial change. If a topic needs more discussion, let's start a new thread, otherwse this will get really messy.
>
>Issues proposed to be addressed in the next protocol document include:
>- Solutions to the thread "Outstanding operations after TLS closure/renegotiation" starting here <http://www.openldap.org/lists/ietf-ldapbis/200502/msg00070.html> and ending here <http://www.openldap.org/lists/ietf-ldapbis/200503/msg00041.html>  The proposed text changes are listed in the last message of the thread. I also propose to update the relevant Changes sections in Appendix C
>- Solution to the thread "protocol: searches and subtypes" starting here <http://www.openldap.org/lists/ietf-ldapbis/200502/msg00071.html> and ending here <http://www.openldap.org/lists/ietf-ldapbis/200503/msg00051.html>. The proposed changes are below titled "changes for searches and subtypes"
>- Update for the message "[Protocol][Authmeth][Syntaxes] application of SASLprep" <http://www.openldap.org/lists/ietf-ldapbis/200503/msg00059.html>. The proposed changes are below titled "changes for application of SASLprep".
>- Changes for the thread "draft-ietf-ldapbis-protocol - controls" starting here <http://www.openldap.org/lists/ietf-ldapbis/200503/msg00078.html> and ending here <http://www.openldap.org/lists/ietf-ldapbis/200504/msg00018.html>. The proposed changes are below titled "changes for controls".
>- Update the normative reference for [ABNF] to refer to draft-crocker-abnf-rfc2234bis-xx.txt
>- Change to the semantics of the present search filter item. The proposed wording is this: "A present filter is TRUE when there is an attribute or subtype of the specified attribute description present in an entry, FALSE when no attribute or subtype of the specified attribute description is present in an entry, and Undefined otherwise."
>- Addition of this sentence to the first paragraph of 10. IANA Considerations: " It is also noted that one resultCode value (strongAuthRequired) has been renamed (to strongerAuthRequired)."
>- Move Editor's Address after the changes (after appendix C))
>- Reword Section 1.1 due to suggestions during IETF Last Call. The proposed changes are below titled "changes to relationships"
>- Changes to fix minor inconsistencies with the terms messages and PDUs
>
>
>_____changes for searches and subtypes:_____
>4.5.1.7.1 SearchRequest.filter.equalityMatch
><current>
>The matching rule for equalityMatch filter items is defined by the EQUALITY matching rule for the attribute type.
><proposed>
>The matching rule for an equalityMatch filter is defined by the EQUALITY matching rule for the attribute type or subtype. The filter is TRUE when the EQUALITY rule returns TRUE as applied to the attribute or subtype and the asserted value.
>
>4.5.1.7.2 SearchRequest.filter.substrings (second paragraph)
><current>
>The matching rule for an AssertionValue in a substrings filter item is defined by the SUBSTR matching rule for the attribute type. Note that the AssertionValue in a substrings filter item conforms to the assertion syntax of the EQUALITY matching rule for the attribute type rather than the assertion syntax of the SUBSTR matching rule for the attribute type. Conceptually, the entire SubstringFilter is converted into an assertion value of the substrings matching rule prior to applying the rule.
><proposed>
>The matching rule for an AssertionValue in a substrings filter item is defined by the SUBSTR matching rule for the attribute type or subtype. The filter is TRUE when the SUBSTR rule returns TRUE as applied to the attribute or subtype and the asserted value.
>
>Note that the AssertionValue in a substrings filter item conforms to the assertion syntax of the EQUALITY matching rule for the attribute type rather than the assertion syntax of the SUBSTR matching rule for the attribute type. Conceptually, the entire SubstringFilter is converted into an assertion value of the substrings matching rule prior to applying the rule.
>
>4.5.1.7.3 SearchRequest.filter.greaterOrEqual
><current>
>The matching rule for the greaterOrEqual filter item is defined by the ORDERING and EQUALITY matching rules for the attribute type.
><proposed>
>The matching rule for a greaterOrEqual filter is defined by the ORDERING matching rule for the attribute type or subtype. The filter is TRUE when the ORDERING rule returns FALSE as applied to the attribute or subtype and the asserted value.
>
>4.5.1.7.4 SearchRequest.filter.lessOrEqual
><current>
>The matching rule for the lessOrEqual filter item is defined by the ORDERING matching rule for the attribute type.
><proposed>
>The matching rules for a lessOrEqual filter are defined by the ORDERING and EQUALITY matching rules for the attribute type or subtype. The filter is TRUE when either the ORDERING or EQUALITY rule returns TRUE as applied to the attribute or subtype and the asserted value.
>
>4.5.1.7.5 SearchRequest.filter.present
><current>
>The present match evaluates to TRUE where there is an attribute or subtype of the specified attribute description present in an entry, and FALSE otherwise (including a presence test with an unrecognized attribute description).
><proposed>
>A present filter is TRUE when there is an attribute or subtype of the specified attribute description present in an entry, and FALSE otherwise (including a presence test with an unrecognized attribute description).
>
>4.5.1.7.7 SearchRequest.filter.extensibleMatch (third bullet)
><current>
>-       If the type field is present and the matchingRule is present, the matchValue is compared against entry attributes of the specified type.
><proposed>
>-       If the type field is present and the matchingRule is present, the matchValue is compared against the specified attribute type and its subtypes.
>
>4.5.1.7.7 SearchRequest.filter.extensibleMatch (fourth bullet)
><current>
>-       If the dnAttributes field is set to TRUE, the match is additionally applied against all the AttributeValueAssertions in an entry's distinguished name, and evaluates to TRUE if there is at least one attribute in the distinguished name for which the filter item evaluates to TRUE. The dnAttributes field is present to alleviate the need for multiple versions of generic matching rules (such as word matching), where one applies to entries and another applies to entries and DN attributes as well.
><proposed>
>-       If the dnAttributes field is set to TRUE, the match is additionally applied against all the AttributeValueAssertions in an entry's distinguished name, and evaluates to TRUE if there is at least one attribute or subtype in the distinguished name for which the filter item evaluates to TRUE. The dnAttributes field is present to alleviate the need for multiple versions of generic matching rules (such as word matching), where one applies to entries and another applies to entries and DN attributes as well.
>
>4.5.1.7.7 SearchRequest.filter.extensibleMatch (last paragraph)
><current>
>The matchingRule used for evaluation determines the syntax for the assertion value. Once the matchingRule and attribute(s) have been determined, the filter item evaluates to TRUE if it matches with at least one attribute in the entry, FALSE if it does not match any attribute in the entry, and Undefined if the matchingRule is not recognized, the matchingRule is unsuitable for use with the specified type, or the assertionValue is invalid.
><proposed>
>The matchingRule used for evaluation determines the syntax for the assertion value. Once the matchingRule and attribute(s) have been determined, the filter item evaluates to TRUE if it matches at least one attribute type or subtype in the entry, FALSE if it does not match any attribute type or subtype in the entry, and Undefined if the matchingRule is not recognized, the matchingRule is unsuitable for use with the specified type, or the assertionValue is invalid.
>
>4.5.1.7 SearchRequest.attributes (first paragraph)
><current>
>A selection list of the attributes to be returned from each entry which matches the search filter. LDAPString values of this field are constrained to the following Augmented Backus-Naur Form ([ABNF]):
><proposed>
>A selection list of the attributes to be returned from each entry which matches the search filter. Attributes which are subtypes of listed attributes are implicitly included. LDAPString values of this field are constrained to the following Augmented Backus-Naur Form ([ABNF]):
>
>
>_____changes for application of SASLprep_____
>4.2. Bind Operation (last paragraph)
><current>
>Textual passwords (consisting of a character sequence with a known character set and encoding) transferred to the server using the simple AuthenticationChoice SHALL be transferred as [UTF-8] encoded [Unicode]. Prior to transfer, clients SHOULD prepare text passwords by applying the [SASLprep] profile of the [Stringprep] algorithm. Passwords consisting of other data (such as random octets) MUST NOT be altered. The determination of whether a password is textual is a local client matter.
><proposed>
>Textual passwords (consisting of a character sequence with a known character set and encoding) transferred to the server using the simple AuthenticationChoice SHALL be transferred as [UTF-8] encoded [Unicode]. Prior to transfer, clients SHOULD prepare text passwords as "query" strings by applying the [SASLprep] profile of the [Stringprep] algorithm. Passwords consisting of other data (such as random octets) MUST NOT be altered. The determination of whether a password is textual is a local client matter.
>
>
>_____changes for controls_____
>4.1.11. Controls (first three bullets)
><current>
>-       If the server does not recognize the control type or it is not appropriate for the operation, and the criticality field is TRUE, the server MUST NOT perform the operation, and for operations that have a response message, MUST return with the resultCode set to unavailableCriticalExtension.
>
>-       If the server does not recognize the control type or it is not appropriate for the operation, and the criticality field is FALSE, the server MUST ignore the control.
><proposed>
>-       If the server does not recognize the control type, determines that it is not appropriate for the operation, or is otherwise unwilling to perform the operation with the control, and the criticality field is TRUE, the server MUST NOT perform the operation, and for operations that have a response message, MUST return with the resultCode set to unavailableCriticalExtension.
>
>-       If the server does not recognize the control type, determines that it is not appropriate for the operation, or is otherwise unwilling to perform the operation with the control, and the criticality field is FALSE, the server MUST ignore the control.
>
>-       Regardless of criticality, if a control is applied to an operation, it is applied consistently and impartially to the entire operation. 
>
>4.1.11. Controls (last paragraph)
><current>
>Controls SHOULD NOT be combined unless the semantics of the combination has been specified. The semantics of control combinations, if specified, are generally found in the control specification most recently published. When a combination of controls is encountered whose semantics are invalid, not specified (or not known), the message is considered to be not well-formed, thus the operation fails with protocolError. Additionally, unless order-dependent semantics are given in a specification, the order of a combination of controls in the SEQUENCE is ignored. Where the order is to be ignored but cannot be ignored by the server, the message is considered not well-formed and the operation fails with protocolError.
><proposed>
>Controls SHOULD NOT be combined unless the semantics of the combination has been specified. The semantics of control combinations, if specified, are generally found in the control specification most recently published. When a combination of controls is encountered whose semantics are invalid, not specified (or not known), the message is considered to be not well-formed, thus the operation fails with protocolError. Controls with a criticality of FALSE may be ignored in order to arrive at a valid combination. Additionally, unless order-dependent semantics are given in a specification, the order of a combination of controls in the SEQUENCE is ignored. Where the order is to be ignored but cannot be ignored by the server, the message is considered not well-formed and the operation fails with protocolError. Again, controls with a criticality of FALSE may be ignored in order to arrive at a valid combination.
>
>C.1.11 Section 4.1.12 (Controls)
><add this bullet>
>-       Specified that non-critical controls may be ignored at the server's discretion. There was confusion in the original wording which led some to believe that recognized controls may not be ignored as long as they were associated with a proper request.
>
>
>_____changes to relationships_____
>1.1. Relationship to Other LDAP Specifications (second third, and fourth paragraphs)
><current>
>This document obsoletes all of RFC 2251 except the following:
>Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) are obsoleted by [Models].
>Section 3.3 is obsoleted by [Roadmap].
>Sections 4.2.1 (portions), and 4.2.2 are obsoleted by [AuthMeth].
>
>Appendix C.1 summarizes substantive changes to the remaining sections.
>
>This document obsoletes RFC 2830, Sections 2 and 4 in entirety. The remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes substantive changes to the remaining sections.
><proposed>
>This document, together with [Roadmap], [AuthMeth], and [Models], obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by [Roadmap]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by [AuthMeth].  Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) are obsoleted by [Models].  The remainder of RFC 2251 is obsoleted by this document.  Appendix C.1 summarizes substantive changes in the remainder.
>
>This document obsoletes RFC 2830, Sections 2 and 4. The remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes substantive changes to the remaining sections.
References:
- Summary of proposed changes to [Protocol]
  - From: "Jim Sermersheim" <jimse@novell.com>
Prev by Date: RE: Protocol: control combinations
Index(es):
- Chronological
- Thread