randolf.werner@sap.com writes:
Active Directory. You look at the ldap_create_page_control API spec (developers oftern use API specs and not protocol RFCs) and notice page size to be an usinged integer. Since you are not really interested in pages you specify the largest possible value 2**32-1.
So that API spec is bogus, it should have specified the range. Which data type is being used is not relevant to what the protocol accepts, in particular since the width of data types sometimes change. E.g. if you move from a 32-bit to a 64-bit host.
I am not interested in discussing who is right and who is wrong, i am just interested in making as much as possible working together in the real world with as little as possible customer pain.
Notice however that your first problem happened because AD breaks the standard, and your second problem because you rewrote it by bogus Microsoft documentation and it worked because of another way AD breaks the standard. (Though less seriously in the second case, it follows the "be liberal in what you accept" way.)
If OpenLDAP is changed to accept wider limits, it might also encourage more people to write bogus code like you did. OpenLDAP has been going in the other direction over the years, doing ever more strict error checking.
That said, pretending that Microsoft does not exist isn't always a winning strategy, so it might make sense to implement a "relaxed" mode which accepts common ways to break the standard. But I don't think it should be turned on by default.
Therefore i am almost 100% sure Active Directory will not break existing clients by using signed instead of unsigned integer page size just to be more RFC 2696 compliant.
In addition to fixing the doc, they they could fix that in API by reducing a passed value >= 2**31 to the max valid value. Not that they seem to care much about standards anyway.
One note - I'm curious why you did not use page size 0, which the Microsoft API pages you posted say overrides such page sizes. Though maybe I misunderstood and that doesn't actually help.