Subject: Re: Protocol: control specifications.

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 09 Jan 2004 18:41:07 -0700

So, what I think is being asked is this:
 
If a control specification states: The criticality of the XYZ control
is always TRUE, and some client sends the XYZ control with criticality
of FALSE, what is the server to do?
 
Similar but more explicitly, if the control specification says: The
criticality of the XYZ control SHALL be TRUE, and some client sends the
XYZ control with criticality of FALSE, what is the server to do?
 
If in either of these scenarios, it seems correct for the server to
always fail the operation (in order to ensure some aspect of
interoperability), then somewhere there should be language to that
effect. Personally, I think such language would belong in the specific
control specification, and likely, the appropriate resultCode is
protocolError.
 
On the other hand, if it always inappropriate for any specification to
mandate behavior when a client violates an imperative regarding
criticality, then I guess it's always server-defined.
 
And on yet some other hand, maybe it is inappropriate for a control
specification to use imperatives. I think that's a discussion to be had
on its own. Certainly RFC 2251 reads as though the control
specifications will contain imperatives (implied through the term "is
always").
 
Jim
 
>>> "Kurt D. Zeilenga" <[email-masked]> 1/9/04 5:30:22 PM >>>
At 01:05 PM 1/9/2004, Hallvard B Furuseth wrote:
>Kurt, I'm suddenly wondering if I've misunderstood you completely,
>and if so I don't know where. So I need a bit of clarification
>before replying to your latest message:

After a couple of draft responses, I've concluded that there
isn't a good way to clarify my reply without taking a (big)
step back.

LDAP provides, in controls, a mechanism for extending the
semantics of an existing operation. The extended semantics
are associated with the type of control (an OID) and
associated type-specific data (an octet string).

This mechanism also provides a facility by which a client
can indicate to the server that the extended semantics
associated with any particular control instance is critical.
That is, by marking a control critical, the client demands
that server not process the operation if it cannot make
use of the control.

Criticality was intended to be in the eye of the client
(based upon user input and/or guidance in the specification
of the particular control), not the server.

Also, the criticality field was not intended to have any
other semantic. That is, the performance of the operation
as extended by the control is not intended to be dependent
on the criticality value.

I believe that most implementations behave as I describe
above, which I content is as intended. I also believe
this section needs clarification to ensure future clients
and servers implement the technical specification in
a manner consistent with today's implementations. My
suggestions are intended to do this.

I object to your suggestions are numerous grounds:
1) that wasn't what was intended,
2) that isn't what is implemented,
3) that violates interoperability principles on
which Internet is built on (be strict in what you
send, be liberal in what you accept),
4) that hinders subsequent revision of extension
specifications, and
5) it will limit how one control could extend
an operation extended by other control(s).

(The last one is new. For now, I'll leave it as something
for you and others to think about.)

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Jan 2004 19:58:29 -0800

At 05:41 PM 1/9/2004, Jim Sermersheim wrote:
>If a control specification states: The criticality of the XYZ control is always TRUE, and some client sends the XYZ control with criticality of FALSE, what is the server to do?

   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.

otherwise, the control is to be ignored.

>Similar but more explicitly, if the control specification says: The criticality of the XYZ control SHALL be TRUE, and some client sends the XYZ control with criticality of FALSE, what is the server to do?

   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.

otherwise, the unsupportedCriticalExtension is to returned.

>If in either of these scenarios, it seems correct for the server to always fail the operation (in order to ensure some aspect of interoperability), then somewhere there should be language to that effect.

Exactly, if RFC 2251 had intended this, the text:
   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.

would have be qualified as only apply when the criticality had a value
consistent with the control's specification.

>Personally, I think such language would belong in the specific control specification, and likely, the appropriate resultCode is protocolError.

Authors of such documents should be very careful in including such
language as it likely to cause far more problems that it will ever
solve.  (As many of us have learned already.)  In particular, one
should consider whether there will ever be a need to change that
language and what impact such a change would have on forwards/backwards
compatibility.  Also, one should not assume that such a check would
be trivial extension to the servers existing code handling criticality
checks (given that the check is likely in a different code path).
(Yada, yada, yada.)

>On the other hand, if it always inappropriate for any specification to mandate behavior when a client violates an imperative regarding criticality, then I guess it's always server-defined.

My suggestion is worded as a strong recommendation, not a mandate.  It's also
worded as a requirement upon the document defining the control, not as a
restriction upon extent of which control can extend the operation.

>And on yet some other hand, maybe it is inappropriate for a control specification to use imperatives. I think that's a discussion to be had on its own. Certainly RFC 2251 reads as though the control specifications will contain imperatives (implied through the term "is always").

I believe it is assumed that control specifications will use imperatives
where appropriate.

>that server not proc! ess the operation if it cannot make
>use of the control.
>
>which Internet is b! uilt on (be strict in what you
>send, be liberal in what you! accept) ,

---

From: Mark Ennis <[email-masked]>
Date: Mon, 12 Jan 2004 09:48:42 +1100

I agree with Kurt that a server implementation should be flexible in 
what it receives. The criticality flag is not intended to check that 
client implementations are behaving correctly. It is a tool for clients 
  to indicate whether they wish to be informed on whether extension 
behaviour is available or not. A control specification should only be 
recommending the setting of this flag to the client implementation.

If a server supports a requested control, then the criticality flag is 
of no interest and should be ignored.

If the server supports a requested control, but the client supplies the 
control for an inappropraite operation type, it should be ignored unless 
the control specification indicates a specific action in this case.

- Mark Ennis.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 12 Jan 2004 03:00:58 +0100

I really should digest the implications of the control RFCs I just
posted before replying to some of this, but anyway:

Kurt D. Zeilenga writes:
>> is always TRUE, and some client sends the XYZ control with
>> criticality of FALSE, what is the server to do?
> 
>> criticality of the XYZ control SHALL be TRUE, and some client sends
>> the XYZ control with criticality of FALSE, what is the server to do?
> 
> (...)

I don't like to make a difference between these two cases:

I hope you do not wish to give the control spec the same right to
override criticality=TRUE sent by the client.  I haven't quite
thought through the consequences of that, but it feels a lot more
dangerous.

If not, then figuring out whether the effective criticality is TRUE
or FALSE gets rather complicated, and I'm not sure I see the
justification for that.

Also, the difference between these two texts is very small.  An
control spec author might choose one when he meant the other, and a
reader of the spec might assume one when the author meant the other.
It's just like the disagreement in this tread about the wording in
RFC2251.  So we'd have to demand that the specs are worded very
carefully, and perhaps go through existing control specs and update
them to clarify this.

>> effect.

Not so, because that text is about how to perform the operation when
it _is_ performed, not about whether or not to perform it.

>> Personally, I think such language would belong in the specific
> solve.  (...)

I agree.

It should be possible to put such additional semantics in the
controlValue instead, if one needs to.

Also, I don't see much benefit from giving control specs this
freedom, when it's all about an error anyway so the correct thing to
do is to fix the client.

>> On the other hand, if it always inappropriate for any specification
>> to mandate behavior when a client violates an imperative regarding
> My suggestion is worded as a strong recommendation, not a mandate.

But if we keep the text which lets the spec mandate criticality, the
spec is still free to give recommendations.  Or we could mention
that explicitly in [Protocol].

> It's also
> worded as a requirement upon the document defining the control,

That's no advantage, if I understand the context correctly:-)

> not as a

I didn't understand that.  Can you rephrase?

>> specification to use imperatives. I think that's a discussion to be
>> had on its own. Certainly RFC 2251 reads as though the control

I read both your suggested text and your arguments up to now as
denying them that possibility.  If you wish to allow the spec to
mandate criticality, please add it to your suggested text.  Also,
are you talking about client-supplied criticality, the criticality
which the server assumes, or both?  If the former, is it possible
that we actually agree about something - that even if we take your
suggested text, you would allow servers to treat wrong criticality
as an error if they wished?

-- 
Hallvard