Re: Protocol: control specifications.

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

>>> John McMeeking jmcmeek@us.ibm.com> 1/13/04 9:48:22 AM >>
>>
>> Also, a client implementation could receive either protocolError or
>> success (or other) in the resultCode of an operation containing
such
>> a control by two compliant servers. It may even receive these
>> different results from the same server, depending on configuration
>> state and control architecture.
>
>I don't follow this part. If the control spec says the control
critcality
>MUST be TRUE, and the client follows this, how would it get
protocolError?

I mean in the case where there is a misbehaving client (which sets
criticality to FALSE).
 
>I would hope that the current control architectures allow the
"control
>implementation" to access criticality, as controls now certainly can
be
>inappropriate (must be able to return unavailable critical extension
if
>criticality is TRUE), 
 
Yes.
 
>and implementations should be able to return protocol
>error if the control value is in error.

Current implementations likely only do this iff the criticality field
is malformed.
 
>I would suggest, then, that if we do not choose to enforce
criticality,
>that
>"always set to TRUE, ... FALSE, or sender's choice" does not add
anything
>and has been the source of questions that folks have received as to
what it
>means
>when a control is "always critical". If the server does not enforce
>criticality,
>a control is, by definition, critical at sender's choice. X.511 just
has a
>table
>with a column labeled "recommended criticality" (critical or not
critical).
>Limit
>the control specification guidance in 4.1.11 to:
>
>- a recommended control criticality,

Yes. I think this is the direction we are likely headed.

Jim