Subject: IETF ldapbis WG Last Call: draft-ietf-ldapbis-filter-01.txt

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 11 May 2001 16:59:20 -0700

This message initiates a LDAPbis Working Group Last Call on the
document:

          The String Representation of LDAP Search Filters
                <draft-ietf-ldapbis-filter-01.txt>

The purpose of this WG Last Call it to ensure that the Working Group
has achieved consensus that the document is suitable for publication
as an IETF Draft Standard.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list.  Editorial issues
may be sent to the document editor.

The Last Call period will end on Monday, May 28, 2001.

Upon completion of the last call, the WG chair(s) will take action
based upon the consensus of the WG.  Possible actions include:

  1) recommending to the IETF Application Area Directors that the
     document, after possible editorial or other minor changes, be
     considered by the IESG for publication as a Draft Standard
     (which generally involves an IETF-wide Last Call); or

  2) requiring that outstanding issues be adequately addressed prior
     to further action (including, possibly, another Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

 - Kurt Zeilenga
   LDAPbis co-chair

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 23 May 2001 16:05:43 +1000

Some comments on draft-ietf-ldapbis-filter-01.txt.

> 3.  LDAP Search Filter Definition

The text in RFC2251 and the ABNF for <filterlist> both require that
an LDAP "and" or "or" filter choice have at least one filter element,
in which case it would be appropriate if the ASN.1 for the Filter type
in both RFC2251bis and RFC2254bis contained a SIZE constraint.

Instead of:

>        Filter ::= CHOICE {
>                and                [0] SET OF Filter,
>                or                 [1] SET OF Filter,
                 ...

I suggest:

        Filter ::= CHOICE {
                and                [0] SET SIZE (1..MAX) OF Filter,
                or                 [1] SET SIZE (1..MAX) OF Filter,
                ...

Similarly for the SubstringFilter ASN.1 type.

>        SubstringFilter ::= SEQUENCE {
>                type    AttributeDescription,
>                -- at least one must be present
>                substrings    SEQUENCE OF CHOICE {
>                        initial        [0] AssertionValue,
>                        any            [1] AssertionValue,
>                        final          [2] AssertionValue
>                }
>        }

The comment "at least one must be present" applies to the substrings
SEQUENCE OF type, in which case the following definition would be more
appropriate.

                substrings    SEQUENCE SIZE (1..MAX) OF CHOICE {
                        initial        [0] AssertionValue,
                        any            [1] AssertionValue,
                        final          [2] AssertionValue
                }

> 4.  String Search Filter Definition

The following excerpt isn't strictly ABNF, and the referencing is a
bit loose.

>      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>

>   The attr and matchingrule constructs are as described in the
>   corresponding section of [RFC2251bis] given above.

There is an <AttributeDescription> rule in RFC2251 but there isn't a
<MatchingRuleId> or <AssertionValue> rule. The better reference for
the ABNF of a MatchingRuleId is the <oid> rule from RFC2252.

I would present it all like this:

      attr           = AttributeDescription
      matchingrule   = oid
      assertionvalue = valueencoding

   The <AttributeDescription> rule is defined in Section 4.1.5 of
   [RFC2251bis]. The <oid> rule is used to encode a matching rule
   OBJECT IDENTIFIER, and is defined in Section 4.1 of [RFC2252bis].
   The <valueencoding> rule is used to encode an AssertionValue (see
   Section 4.1.7 of [RFC2251bis]).

The paragraphs describing the <valueencoding> rule make sense if the
AssertionValue is a human readable UTF8 *character* encoding but leave
something to be desired when the AssertionValue is arbitrary *octet* data
or a BER encoding. For example, if a series of arbitrary octets happens
to look like a multi-octet UTF8 character must all of the octets be
escaped ? I don't think so. The notion of a multi-octet character
doesn't apply to arbitrary octet data.

Separate paragraphs describing how UTF8 string data and octet string data
are encoded might be the way to go. The deciding factors are whether the
";binary" option has been used and whether the syntax is marked as human
readable in the table of syntaxes in RFC2252. So, if the AssertionValue
is a UTF8 character string the characters "*", "(", ")", "\" and NUL are
escaped as described. Non-ASCII UTF8 characters have all their octets
escaped. If the AssertionValue is an arbitrary OCTET STRING or a BER
encoding then we can say that all octets are escaped, or that at least
the octets with the values 0x2a, 0x28, 0x29, 0x5c, 0x00 and 0x80 - 0xff
are escaped.

Regards,
Steven