[Discussion of over-riding the binding info]

I don't think this is consistent with the model used for ZSQLMethods, and would just increase the confusion. We can re-examine the need for this when there's an exact product that needs some other behaviour. You could of course then bind at a lower layer and not use THIS abstraction.

[Access to lower-level controls]

These can definately be added as necessary, but I fear that too many knobs will make for bizarre performance problems. Having worked with LDAP for the past couple years in pretty heavy usage environments, I find that programmers often create MORE problems by twiddling the knobs, and it's better for the application to choose more sane defaults.

* It seems to me the document spends a lot of time talking about LDAP search filters, but not how to fill in parameters, which would be like ZSQL docs talking about SQL syntax, but not explaining how to put in #sqlvar tags.

That's because they don't exist :-) As is noted, at some point we will create new tags to deal with LDAP, but we're trying not to polute the name space too badly, and looking at genericising the existing tags. Until then, #var is all you get :-)

[LDAP over SSL]

I forget not everyone uses this since my pervious employer wrote the spec for it. This is mandetory for future use with PKI which is one of the reasons this is being written. At that point, bindDN information is replaced by X.509 certs. This will be non-functional in the initial release.

* The subject of multi-valued attributes appears to have been completely overlooked, as well as delete and modify-rdn operations. I realize these may all be outside the scope of your current project, but it might be good to explicitly list what things are out-of-scope.

I will add these as "out of scope" right now. Thanks for the input. Chris -- | Christopher Petrilli Digital Creations | petrilli@digicool.com http://www.digicool.com