RE: Protocol: control specifications.

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

Jim Sermersheim writes:
> Regarding the current text:
>  
> direction as to what value the sender should provide for the
> criticality field (note: the semantics of the criticality field are
> defined above should not be altered by the control's specification)
>  
> versus the old text:
> 
> whether the control is always noncritical, always critical, or critical
> at the client's option
> 
> These can either be read to have the same or very similar meanings, or
> they can be read to have at least two different meanings:
> 
> 1) the old text can be read to imply that the control spec can mandate
> the criticality, and the server should validate the criticality

Not quite.  I thought - and still think - this meant a wrong criticality
is an error, so server MAY validate it, and thus a good quality server
would do so.  I asked for a SHOULD, but have lost that argument.

> 2) the old text can be read to imply that the control spec can mandate
> the criticality, but it's the clien't responsibility to validate it.

There was also a significant confusion about the criticality which is
used by the server vs. the criticality protocol field.  E.g., for the
old text,

  3) If the control is implemented, the server uses the criticality
     given in the control specification and ignores the criticality
     protocol field.

or variants like using either (3) or (2) depending on the wording of the
control spec.

I even seem to remember someone (Kurt?) said (3) was common to
implement.  However, after the debate shifted to client-specified
criticality, I don't remember anyone arguing to keep (3).  I may be
wrong.

> (1) has been argued abck and forth, and it seems consensus is to not
> do that.

(1) as in "SHOULD", yes.

(1) as in "MAY" - the arguments against the "SHOULD" seem to have become
the reason for even removing the "MAY".  I've argued against that, but
the change happened without response to my arguments, except some
misunderstandings about why I thought it said that.

> (2) in my mind is still allowed by the new text.

It can be read that way, but "direction" can also be seen as saying the
spec may recommend a criticality, but that it does not say anything
about allowing the spec to mandate a criticality.  So I've asked
for a clarification.

Also, note John's point that unlike LDAP, X.500 does not let the control
spec to mandate a criticality of FALSE.

Finally, the old text did not allow the control spec to mandate a
specific criticality only in some circumstances.  I like that, but I
think that too differs from X.500.

-- 
Hallvard