RE: Protocol: control specifications.

[John McMeeking <jmcmeek@us.ibm.com>]

I have already noted the X.511 statement that a DUA shall set the
corresponding bit of the critical extensions field when using extensions
that X.511 defines as critical.  Beyond that, no I am aware of no
"non-diagnostic" use.

Clearly, if a server recognizes the control and it is appropriate to use,
the RFC 2251 and ldapbis language both require the server to honor the
control independent of criticality.

I consider the existing language an improvement over RFC 2251.  The RFC
2251 language of "always critical" and "never critical" implies behavior
that does not exist; "critical at senders request" is the only thing that
is consistent with the servers' required behavior.  Its possible the
language was intended to mean more but lost something during editing, but
that is pure conjecture on my part.

I guess I'll accept any language that clearly states what the server is
supposed to do with control criticality, and uses consistent language for
guidance/requirements of control definitions.


John  McMeeking


owner-ietf-ldapbis@OpenLDAP.org wrote on 03/08/2004 02:02:53 PM:

> Hallvard, John,
>
> 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?
>
> It seems that this is not really a protocol interoperability
> issue (though requiring verification might actually lead to
> some protocol interoperability problems), but a client
> development/diagnostic issue.
>
> (Hallvard, you are likely correct that I have not responded to
> each of your points.  This is mostly likely due to my attempt
> to narrow discussion to key aspects of this issue.  We, of
> course, likely differ on what are key aspects of this
> discussion.)
>
> Kurt
>