[Combining several replies]
Howard Chu wrote:
Marc Chantreux wrote:
On Thu, Nov 15, 2007 at 12:30:09PM -0800, Quanah Gibson-Mount wrote: Imagine I just want to know what's the max uidNumber used in my directory. actually, i ask the server to give all the uidNumbers and my client sort them. isn't it an horrible waste of bandwidth ?
(...) The server side sorting feature is an extremely indirect (and inefficient) route to answering this particular question; you get the answer you're looking for as a side-effect of a non-standard query.
Or you *don't* get the answer you are looking for, if the server first picks <sizelimit> entries to return and then sorts them.
In fact, section Security Considerations of RFC 2891 (the server-side sorting RFC) points out that it is a security problem if this works when also more entries match than the administrative (server-side) limit.
Does it work with some existing implementations - (a) when there are fewer matcing entries than the server-side limit and (b) when there are more matching entries than that?
Matt Smith wrote:
I see one valuable use for SSS - guaranteed search return order.
Yes, that could be useful. To get that from SSS you need: - an attribute to which you can apply some ordering rule (or several attributes, in case sorting by one isn't enough), - each entry must contain a *unique* value of the attribute (entryUUID would be OK for _some_ OpenLDAP backends), - no access controls protecting the attribute(s), - not to run into size/time limits.
Howard Chu wrote:
(...) In fact OpenLDAP has an RFC-compliant implementation of SSS which is a pure no-op; this is perfectly compliant because the SSS spec is so utterly useless in real directories.
I don't think that's a fair argument, it's like using the null backend to demonstrate why the spec of the LDAP search operation is useless.
A related point: The LDAP spec leaves large parts of LDAP unspecified or optional, and vendors disobey mandatory parts of it too. I said Jeff might need to examine RFC 4513 features in greater detail, but might just as well have said it about the entire LDAP spec. E.g. does the server support attribute inheritance (can you search for 'name' and find 'cn')? Object class extensibleObject? Does case-insensitive match handle lowercase vs. uppercase non-ASCII letters? Does the server normalize Unicode strings before comparing? Howard mentioned other examples, regarding the X.500 model.
That can be a problem if the implementation you move _from_ lacks features too. If you move your data to a server which does stricter error checking (e.g. it requires exactly one structural class per entry), you may need to rewrite your schema and/or LDAP data so the new server will accept it.