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

[mcs@netscape.com (Mark C Smith)]

Steven Legg wrote:
> 
> Some comments on draft-ietf-ldapbis-filter-01.txt.

Thank you for your comments.  Responses below, prefixed with [mcs].


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

[mcs] I agree.  This is really a 2251bis issue and an editorial issue
for 2254bis.  But I think these clarifications are useful.



> > 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]).

[mcs] I agree, except I am a little concerned about this one:

	assertionvalue = valueencoding

I like the more verbose text that currentlly appears in the BNF itself
because someone who is just reading the BNF will realize there an
assertionvalue is a more restrictive quantity than is implied by the
valueencoding rule along.  Other opinions?


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

[mcs] This is another good point.  I would prefer to make no reference
to the ;binary option in 2254bis (I don't think we need to do so).  I
actually think the escaping rules are general enough already, but the
use of the word "character" is misleading.  It may be clearer to have
two separate paragraphs as you suggested, but I think it is important to
make it clear that there is only one set of escaping rules.  Let me
think about this a bit more and send out some revised text (other
suggestions are welcome of course).

-Mark Smith
 Netscape