On Jan 26, 2011, at 9:15 AM, masarati@aero.polimi.it 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.