RE: Protocol: control specifications.

["Jim Sermersheim" <jimse@novell.com>]

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

(1) has been argued abck and forth, and it seems consensus is to not do
that.
(2) in my mind is still allowed by the new text.

Let me know if there is something I'm not considering.

Jim


>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 3/8/04 11:44:15 AM
>>>
Ramsay, Ron writes:
> I can't help feeling that you have answered your own question.

I'm not sure which question you are referring to. You are just
describing some of the semantics of the current draft. I'm asking for
responses to my arguments against the change from rfc2251 to that
semantics. The original change I suggested in the other direction has
been discussed to death, but the change which was actually made has
not.

> The server response is (...)

Yes, that's what the current text says. It's not what rfc2251 said.