Re: Protocol: control specifications.

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

No recommendation - just some observations...

X.511 has a similar notion of recommended criticality.  And it is just
that, a recommendation.  As far as I could tell, doing the equivalent of
modifyDN with new superior is done via an extension that the DUA may, or
may not mark as critical.  If the DUA does not mark this as critical and it
goes to a DSA that does not support this extension, the result will most
likely not be what was intended.  If the operation specifies a new RDN and
new superior, the result could be that the entry is renamed but left with
the same superior.  Weird, but...

I'm not saying that this doesn't have any risks.  I sympathize with
Hallvard's view that we ought to leave leeway for a server to discourage
such risky practices.

I'm tempted to suggest  "A server MAY reject a control that has a
criticality that violates the recommended criticality defined in the
control specification."

That doesn't introduce an incompatibility with older servers, and it gives
leeway to implementations with Hallvard's perspective on control
criticality.

However, it does introduce the possibility that a [popular or critical]
application that works great with servers that do not enforce recommended
criticality will not work with some servers.

You're going to make someone unhappy either way -- the user whose
application is doing bad things because it didn't specify the proper
criticality, or the user whose application works on other vendor's servers,
but not on his.


John  McMeeking


owner-ietf-ldapbis@OpenLDAP.org wrote on 01/09/2004 12:15:08 PM:

> Hallvard,
>
> I believe you are missing a few aspects of the RFC 2251 text:
>    This document does not define any controls.  Controls may be defined
>    in other documents.  The definition of a control consists of:
>      ...
>      - whether the control is always noncritical, always critical, or
>        critical at the client's option,
>
> Note that the bullet is part of a statement of practices to be followed
> in writing extension documents.  That is, this bullet is not stating a
> requirement upon implementations of LDAP (including those implement
> any control).  Someone implementing LDAP can completely ignore this
> paragraph as it simply does not pertain to implementations.
>
> Second, your interpretation of this text as an implementation requirement
> is counter to the previous text detailing the protocol:
>    The criticality field is either TRUE or FALSE.
>
>    If the server recognizes the control type and it is appropriate for
>    the operation, the server will make use of the control when
>    performing the operation.
>
> This text, as been interpreted by most implementors as meaning that,
> regardless of the value of criticality presented, a server is to make use
> of a control when they recognize the control type and that control type
> is appropriate for the operation.
>
> You suggested text is also problematic for a number of reasons:
>         1) servers don't, as far as I know, don't behave in the manner
you
>         describe,
>         2) the suggestion is counter to "be liberal in what
>         they accept" principle, and
>         3) the suggestion hinders changes to guidance given (based upon
>         operational experiences or otherwise).
>
> Your primary argument to make the change is that servers should check
> user input.  I think it can be reasonable be argued that checking user
> input in this case is primarily the responsibility of the client (under
> the clients "should be strict in what they send" principle).
>
> I oppose the direction you suggest we take.
>
> A few additional comments below.
>
> At 09:17 AM 1/9/2004, Hallvard B Furuseth wrote:
> >Kurt D. Zeilenga writes:
> >> Though I think you might have misunderstand some of my points,
> >> I likely some of yours, and that we're not exactly seeing eye to
> >> eye on the "why", I think we've converging on acceptable
> >> replacement text.
> >
> >I don't:-(
> >
> >> Here is my latest offering:
> >>
> >> - guidance as to what value the sender should provide for the
> >>   criticality field
> >
> >That still has the problem that it removes the server's license to
> >treat the 'unadvised' criticality as an error.
>
> Again, the RFC 2251 text which this replaced does not specify any
> implementation "license" as it simply did not pertain to implementors.
> Was a profiling statement for extension specifications, as is the
> replacement text.
>
> >In that, it goes
> >exactly in the opposite direction of what I want.  My preference is
> >this text from protocol-19:
> >
> >   - whether the criticality field should be always set to TRUE,
> >     always set to FALSE, or sender's choice
>
> As previously noted, this language could be viewed as limiting the
> kinds of guidance which an extension specification could give.  For
> instance, it does not allow an extension from saying:
>         Criticality should be TRUE when X is TRUE.
> or
>         Criticality should be FALSE when Y is FALSE.
>
> The intent of this original text was to encourage extension authors
> to discuss the circumstances of when particular criticality values
> are appropriate.  The text I proposes attempts clarify the text
> to that intent while removing ambiguity that some have raised that
> the text could be viewed as stating an implementation requirement
> (instead of a document profile).
>
> >Failing that, my second suggestion would be to revert to RFC 2251's
> >text:
> >
> >   - whether the control is always non critical, always critical, or
> >     optionally critical,
> >
> >which at least won't introduce any incompatibility.
> >(Or s/optionally critical/sender's choice/, I liked the new phrase
> >better.)
>
> The original text has most of the same problems as your suggested
> text.
>
> >Also, I'm still hoping for:
> >
> >  If the criticality field for a supported control does not match
> >  the value required by the control specification, the server SHOULD
> >  NOT perform the operation, but instead return protocolError in the
> >  resultCode if the operation has a response.
>
> It would be inappropriate to make such a statement in text intended
> to detail a document profile.  When considers this as an addition
> to the technical specification, absent the document profile, it becomes
> clear that you are asking for a change in protocol semantics.
>
> >or s/required by/in/ if we use the RFC 2251 text above.
> >
> >>   (note: the processing semantics of the
> >>   criticality field, which are defined above, should not be
> >>   altered in any way by the control's specification),
> >
> >I'd strengthen that:  s/should not/can not/.  Remove '(note: )'.
> >(Yes, I know.  Nobody is as fanatic as a convert:-)
>
> I think it clearer as suggested.
>
> Kurt
>