On Jan 26, 2011, at 9:15 AM, [email protected] wrote: > The complexity of handling this nonsense in libldap seems not worth = the > effort;
Ando, you are too kind to refer this extension as 'nonsense'. It's = worse than nonsense, it's crap. The spec you pointed at says: "LDAP servers often place limits on the = maximum number of attribute values that can be retrieved in a single = query." The spec fails to say why would a server want to do that. I = cannot think of any good reason to do precisely that. While I can = understand a desire to place limits on what clients can retrieve, I = don't see why one would distinguish between a single query and a set of = queries. I can also see it desirable to allow a client to page through = results (but that's a different matter, this is about forcing paging = onto clients). It is incredibly stupid to require clients to use multiple operations to = obtain information for which the protocol allowed to be fetched in a = single operation, and this is why I refer to this as "crap". A major problem with paging, whether server-forced or at client-option, = is result set coherency due to changes to the DIT between when various = page operations are obtain. This can lead to problems such a member of = a group not appearing in the results. While one might argue client = might be able to reasonable deal with coherency issues, most client = developers won't. This will lead to a range of security issues creeping = into directory applications. So while I don't generally oppose introduction of paging extensions at = the client option, I think the specifications should warn that the = clients using them need to be designed to handle data coherency issues. = However, most designers of such extensions seem to have put no thought = into this issue at all. I do generally oppose introduction of non-truly optional extensions in = LDAP (and in other application protocols). One would think that a = requirement that extensions to a protocol be truely optional would go = without saying, but in IETF we actually found it necessary to explicitly = state this in the BCP governing LDAP extensions. That BCP will effectively stop non-truly optional extension proposal as = this from gaining Standard Track status in the IETF. > I think we might consider working this around in proxy backends > (much like we did for unsolicited paged results response in back-meta, > ITS#6664, which could be added to back-ldap as well). I would think it easier to reconfigure AD not to have the limits which = cause this sort of paging. > I don't think implementing something that requires a theoretically > unbounded number of nested search requests for each attribute value = that > contains a range in each SearchResultEntry message makes sense. >=20 > The parallel with referrals is not appropriate, since referrals are = part > of LDAP specification; also, please note that automatic referral = chasing > is strongly discouraged unless the transport layer is protected = (Section 6 > of RFC 4511). >=20 > p.
