Re: Controls and criticality

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

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

-- 
Hallvard