Pierangelo Masarati writes:
Kurt Zeilenga wrote:
On Nov 2, 2008, at 11:00 AM, Pierangelo Masarati wrote:
Kurt Zeilenga wrote:
Some controls specifications are simply broken. No part of the 'making use of the control' should depend on the value of criticality.
Is this stated anywhere now? I seem to misremember those ldapbis discussions. E.g. this message http://www.openldap.org/lists/ietf-ldapbis/200403/msg00058.html where you say the control spec _can_ require a criticality and the server can check it. It's about this RFC 4511 statement, I think: "note: the semantics of the criticality field are defined above should not be altered by the control's specification" but I'm not sure how much that implies. Certainly it means the spec can't tell the server to e.g. ignore the criticality in a request and treat criticality as TRUE regardless.
It was not stated anywhere when those controls were written (to RFC 2251). On the contrary, RFC 2251 said control specs include: "whether the control is always noncritical, always critical, or critical at the client's option". So RFC 2251 was talking both about the criticality sent in the LDAPMessage and the one in the spec. RFC 4511 switched to the one in the message only, making the spec advisory.
In any case, when the control spec does say the result depends on criticality, the two correct options are to implement the control that way or to not implement the control at all.
The server shouldn't even consider criticality in its processing until after deciding not to make use of a control, whether to fail due or ignore the control.
Well, almost never. If a request contains several possibly-conflicting controls, "Controls with a criticality of FALSE may be ignored in order to arrive at a valid combination".
About client-provided criticality FALSE when spec says TRUE:
To me, slapd should reject those cases with protocolError.
This kind of breaks the separation between the controls criticality processing and control processing.
Yes. But this is a consequence of the fact that some controls' specs seem to overload the criticality flag with some additional semantics.
I tend to prefer 'be liberal in what you accept'.
I'd agree (I do, in principle) but I'd limit liberality to data integrity and security.
I would too. But that was a huuuge discussion which I'm still nervous about dipping my toes into again:-)
However, if I were to redesign LDAP from scratch, I'd remove the concept of a non-critical control in favor of requiring the client to fall-back. At present, most clients don't provide any fall-back. But I digress.
Another digression: If I were to redesign LDAP from scratch, I'd call it "X.500".