Re: Protocol: control specifications.

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

Kurt D. Zeilenga writes:
> Though I think you might have misunderstand some of my points,
> I likely some of yours, and that we're not exactly seeing eye to
> eye on the "why", I think we've converging on acceptable
> replacement text.

I don't:-(

> Here is my latest offering:
> 
> - guidance as to what value the sender should provide for the
>   criticality field

That still has the problem that it removes the server's license to
treat the 'unadvised' criticality as an error.  In that, it goes
exactly in the opposite direction of what I want.  My preference is
this text from protocol-19:

   - whether the criticality field should be always set to TRUE,
     always set to FALSE, or sender's choice

Failing that, my second suggestion would be to revert to RFC 2251's
text:

   - whether the control is always non critical, always critical, or
     optionally critical, 

which at least won't introduce any incompatibility.
(Or s/optionally critical/sender's choice/, I liked the new phrase
better.)

Also, I'm still hoping for:

  If the criticality field for a supported control does not match
  the value required by the control specification, the server SHOULD
  NOT perform the operation, but instead return protocolError in the
  resultCode if the operation has a response.
    
or s/required by/in/ if we use the RFC 2251 text above.

>   (note: the processing semantics of the
>   criticality field, which are defined above, should not be
>   altered in any way by the control's specification),

I'd strengthen that:  s/should not/can not/.  Remove '(note: )'.
(Yes, I know.  Nobody is as fanatic as a convert:-)

-- 
Hallvard