LDAP filter document loose ends (draft-ietf-ldapbis-filter-01.txt)

[Mark Smith <mcs@netscape.com>]

"Kurt D. Zeilenga" wrote:
> 
> The Filter I-D WG Last Call concluded last week.  The following
> issues were raised and should be resolved as indicated:
> 
> 1) Steve raised an issue that the ASN.1 for and/or filter SETs
> are not limited to one or more elements per text of RFC 2251
> and ABNF of RFC 2253 and suggested the ASN.1 be modified to
> include SIZE (1..MAX) restrictions.  MarkS agreed but noted
> that this is primarily an protocol I-D issue, not a filter I-D
> issue.  ACTION: JimS to review protocol issue and make
> recommendation for WG consideration.  Once resolved, MarkS
> should update the ASN.1 fragments provided in the filter I-D.

No changes have been made to 2251bis to address this issue.  So I am not
going to change the filter document yet.  But I believe these changes
should be made to the ASN.1 in 2251bis.



> 2) Steve raised an issue regarding the clarity of ABNF and text
> associated with <MatchingRuleId> and <AssertionValue> and
> suggested some changes.  MarkS agreed that some changes was
> needed.  ACTION: Further discussion is needed.

I recommend that we adopt Steve's new text.  I suggest we include the
descriptive text as comments within the ABNF though.  Here is a specific
proposal:

Subset of ABNF from draft-ietf-ldapbis-filter-01.txt:
 attr           = <AttributeDescription from Section 4.1.5 of
[RFC2251bis]>
 matchingrule   = <MatchingRuleId from Section 4.1.9 of [RFC2251bis]>
 assertionvalue = <AssertionValue from Section 4.1.7 of [RFC2251bis]
                   encoded using the valueencoding rule>

Proposed ABNF:
 attr           = AttributeDescription
                    ; The <AttributeDescription> rule is defined in
                    ; Section 4.1.5 of [RFC2251bis].
 matchingrule   = oid
                    ; The <oid> rule is defined in Section 4.1
                    ; of [RFC2252bis] and is used to encode a
                    ; matching rule OBJECT IDENTIFIER.
 assertionvalue = valueencoding
                    ; The <valueencoding> rule is used to encode an
                    ; <AssertionValue> from Section 4.1.7 of
[RFC2251bis].


> 3) Steve raised an issue regarding the clarify of the value
> encoding when the value is not UTF-8 and made some general
> suggestions.  Mark agreed that clarity should be improved
> here.  ACTION: Further discussion is needed.

I am not quite sure what to do here.  I would like to change the text to
remove the inappropriate and confusing "character" references while
maintaining clarity that there is only one escaping mechanism.  Here is
a specific proposal; please critique it, because I am sure it could
still use improvement:

Old text from draft-ietf-ldapbis-filter-01.txt:

   The valueencoding rule provides that the characters "*" (ASCII 0x2a),
   "(" (ASCII 0x28), ")" (ASCII 0x29), "\" (ASCII 0x5c), and NUL (ASCII
   0x00) are represented as the backslash "\" character (ASCII 0x5c)
   followed by the two hexadecimal digits representing the ASCII value
   of the encoded character.

   This simple escaping mechanism eliminates filter-parsing ambiguities
   and allows any filter that can be represented in LDAP to be
   represented as a NUL-terminated string. Other characters besides the
   ones listed above may be escaped using this mechanism, for example,
   non-printing characters.  Each octet of the character to be escaped
   is replaced by a backslash and two hex digits, which form a single
   octet in the code of the character.

Proposed text:

   The <valueencoding> rule provides that the octets that represent the
   ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
   0x29), "\" (ASCII 0x5c), NUL (ASCII 0x00), and all octets greater
   than 0x7f are represented as a backslash "\" (ASCII 0x5c) followed by
   the two hexadecimal digits representing the value of the encoded
   octet.

   This simple escaping mechanism eliminates filter-parsing ambiguities
   and allows any filter that can be represented in LDAP to be
   represented as a NUL-terminated string. Other octets that are part of
   the <normal> set may be escaped using this mechanism, for example,
   non-printing ASCII characters.


> 4) Implementation report needs to be produced.  Further
> changes may become necessary to remove any feature for which
> we do not have two independently developed interoperable
> implementations of.  ACTION: Chair(s)/Editor to prepare
> report based upon WG input.

We have not worked on this yet (at least I have not).

-Mark Smith
 Netscape