Re: Supported RFC's and "features"

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

[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.

-- 
Hallvard