RE: Protocol: control specifications.

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Well, I think the question was more about what use scenarios server-side
enforcement of a particular criticality value would be useful.  In the
past, the use scenario discussed was so that client developers would,
if they tested against a server which implemented such checks, receive
a diagnostic (a protocolError) that would tell them that they didn't
provide the particular criticality value called for.  The question was
whether this wether or not there were other (non-diagnostic) use cases.


At 01:11 PM 3/8/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>
>> In discussing this issue at IETF#59, one of the questions that came up
>> was whether there were any non-diagnostic use case for criticality
>> behavior (where control specifications mandate client send a
>> particular value that servers are to verify the value and return error
>> if not).  Do you have any?
>
>I'm not sure what is the question and what is not, but I hope you find
>the answer here:
>
>- While I think control specs should be able to mandate the
>  criticality protocol field, they should not mandate that servers check
>  it.  That is a [Protocol] issue.  It would just add to the mess if one
>  could trust a server to catch wrong criticality for some controls, but
>  not for others.

Problem here is that any mandated value is control-specific.  The [protocol]
discusses criticality handling which is not control-specific.  While a control
specification can certainly say "servers implementing this control are to
verify its critical field is TRUE", just as that control specification could
mandate that a search scope be baseObject, or a target DN be empty, etc.),
this is a control specific semantic and not part of the control-neutral
criticality processing discussed in [Protocol].  Whether or not such
statements are or aren't appropriate can be left to discussions regarding
particular control specifications which attempt to make them (as any
such verification is part of the control-specific processing).

Instead of saying the control specifications may require such a verification
(or verification of any number of other things), it would like be better
to clarify that the scope of any LDAP extension is only limited by what
can be supported in a truly optional manner. 

>- I thought (and still suspect) rfc2251 said wrong criticality was an
>  error,

I do not believe your view is supported by the consensus of the WG
nor by existing implementations (many of which implement controls
whose specifications mandate clients provide particular criticality
values).

At present, I am inclined to either treat your request as a new feature
(and hence out-of-scope) or as a clarification to an un-implemented
interpretation (which we should avoid), or simply as a change which
is not supported by WG consensus.  However, to ensure the WG fully
considers all issues, it seemed appropriate to see if there were
other use scenarios.

Kurt