[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



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