Evaluation: draft-legg-ldapext-component-matching-10

[Harald Tveit Alvestrand <harald@alvestrand.no>]

Secretariat,
please record me as a YES on this one.

please record the following as COMMENTS from me:
-------------------------------------------------
section 4.2.1.1 is the critical one about string matching - it punts the 
whole thing off as "someone else's problem".

this appears to be consistent with the general thrust of LDAP development - 
that one needs to redefine the caseIgnore and caseExact matching rules (and 
their friends), and that all other docs should just refer to these 
definitions. "get it right once".

Editorial nits:

section 1: unusual to number the TOC.

section 2: superfluous comma after "define"

  the specifications in sections 4 to 7 of this document make it
  possible to fully and precisely define, the LDAP-specific encoding,
  the LDAP and X.500 binary encoding

section 4: "formally" should be "formerly"

  MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
  rule.  MATCHING-RULE.&AssertionType is an open type (formally known
  as the ANY type).