RE: Protocol: control specifications.

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

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 3/9/04 1:03:48 PM
>>>
>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.

ok

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

yuk

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

I would just add that a MAY will cause differing implementations, and
it would seem better in this scenario to have consistent implementations
and lose the benefit of having the server validate. Also, adding the MAY
will cause rewrites of other text (Regardless of the value of the
criticality field, if the server recognizes the control type and it is
appropriate for the operation, the server is to make use of the control
when performing the operation.)

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

Does it help to explicitly state that a spec can mandate criticality?
If so, we can add it, but I worry about getting too far into the realm
of writing a 'specification for control specifications' (as if we're not
already too far into that realm already). Frankly, I feel that the
community's experience in writing control specifications is still very
limited, so I hesitate to add anything here that's not very general in
nature.

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

True, the current wording neither explicitly allows nor disallows it.

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

My feeling in general is to push as much of this as possible to the
guidelines for control specifications document.

Jim