[Ietf-not43] Re: Requirement 3.1.8

[Eric A. Hall]

> I agree.  Solution 2 seems to be the easiest thing to do.  I'm not sure 
> why it is so difficult.

Something more comprehensive than "act like rsynch" will probably get a
more direct solution.

Right now, the mechanism is modelled after the CAPABILITY output in the
various email protocols. The server returns a list of suported features,
and which can vary based on the user identity (this is returned after
auth). Clients don't have to burn session-setup time by probing for the
server's feature set ("do you support F1? how about F2?"), but instead can
just look at the list of features in the CAPABILITY output. It's faster
since it eliminates round-trips for distinct probes, and it's cumulatively
easier on the server than having to issue errors for every failed command
from every distinct client.

> People will be attempting to mine data from these servers.  That is a
> fact of life.  I know our service will not allow somebody to do a
> subtree search in the contacts DIT.  For RLDAP, we excluded any partial
> string matching if they didn't give use the first three letters of the
> name (e.g. cn=*, cn=b*, and cn=bob*).  Therefore matching rules, search
> filters, and scope will be allowed and disallowed depending on what the
> person is attempting to do.

One thing I've been considering is changing the list output to reflect
available query types instead of or in addition to object class versions,
and this seems to indicate a desire for similar effect. Perhaps an
additional bind control (instead of overloading this one) can do that the
best while still preserving the efficiencies of the CAPABILITY model.

I'll start looking into this.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/