I have reviewed draft-legg-ldapext-component-matching-10.txt and,
aside from a few nits (see attachment), find the I-D suitable for
publication as a Proposed Standard.
The OpenLDAP Project are implementing both client and server side
support for this specification and find no issue with the specification
that prevents our completion of this work. We do have a couple of
implementation-specific issues to resolve, such as our server not
being ASN.1 aware, but these our problems not this specification's.
As far as leveraging ASN.1 here, I believe that is the only reasonable
way this specification could have produced a flexible and complete
solution to the general problem. I note that other LDAP features
also require ASN.1 awareness to implement, for example the ;binary
feature [RFC2251] requires such to implement in any general way.
I note as well that GSER hopefully will lead to fewer LDAP-specific
encoding rules. One of the problems with LDAP is that implementors
need to implement lots of special encoders/decoders. GSER allows
implementors to use general purpose encoders/decoders while not
preventing other implementors from hand jamming encoders/decoders
as they choose (ABNFs can easily be generated for any GSER encoding).
I believe that the introduction of component matching and GSER
will lead to an revolution of sorts. That is, LDAP will actually
take advantage of ASN.1. (Today LDAP has all the drawbacks of
ASN.1 with few of its benefits.)
Regards, Kurt