Subject: Re: draft-ietf-ldapbis-protocol - controls

From: Howard Chu <[email-masked]>
Date: Thu, 31 Mar 2005 21:02:29 -0800

Jim Sermersheim wrote:
>  >There is nothing in RFC2251 that suggests the current LDAPbis
>  >interpretation is either intended or correct. Call me crazy, but I'd say
>  >a behavior that is fundamentally useless doesn't belong in the spec.
> When I read RFC2251, I have to disagree.
...
> "If the control is not appropriate for the operation and criticality
> field is TRUE, the server MUST NOT perform the operation, and MUST
> instead return the resultCode unsupportedCriticalExtension."

> If "appropriate" means that the server found *any* reason in which the 
> control causes the operation to fail, this says it should return 
> unsupportedCriticalExtension (as opposed to something like 
> insufficientAccessRights) for critical controls.

OK. Some might view that as confusing, but I think that agrees with the 
principle of least disclosure. (E.g., not disclosing the existence of 
entries/attributes in a search result, if the user lacks permission to 
see them.)

> In your view, what would be the proper definition of "appropriate"? Or 
> if that's too limiting, what would you like the criticality to mean?

We are talking about non-critical controls, specifying that an optional 
feature be used if it is available. I'm fine with "appropriate" meaning, 
in part, that the control and operation are suitable for use together as 
defined in the control's specification. I'm fine with critical controls 
behaving as specified; clearly marking a control as Critical means the 
feature is mandatory and not optional.

One could make a case for returning an error (e.g. protocolError) if the 
server receives a non-critical control that is not appropriate for the 
accompanying request type. I wouldn't, because it's always possible for 
the control spec to be extended later, and the combination may be legal 
in the new spec. (Sure this is a bad example, and a new spec ought to 
get a new OID.) So even with the limited definition where "appropriate" 
only means "appropriate as defined by the control specification" I think 
it is wrong for a server to return an error for an improperly specified 
non-critical control.

If the request is handed off to some other agent/backend that does not 
support the control, then to me that should behave exactly the same as 
if the client had directly issued the request to that agent, i.e., the 
agent lacking support for the control would just ignore it. Really, 
whatever the frontend entity is should be acting as a transparent pipe 
here, it cannot accurately validate support for the control so it 
shouldn't ever try to.

The point is that the mere presence of a non-critical control should not 
be sufficient to cause the server to reject a request. By reject, I mean 
that the server returns an error before even beginning to execute the 
actual request. Once a server has accepted all the parameters of the 
request, including any controls it recognizes and supports, and started 
generating results, then the criticality consideration no longer 
applies, and the request succeeds or fails as it may.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 31 Mar 2005 21:04:00 -0800

The server has choose to either ignore the non-critical
control for the entire operation or make use of the
non-critical control for the entire operation.

If the server has different capabilities in different portions
of the DIT (due to chaining or whatever), the server has to
deal with that in some fashion that ensures the entire
operation is processed in a manner consistent with the above.

How to make use of the control over the entire operation
depends on the control and implementation choices.  In some
cases (for instance, likely w/ managedsait), the right answer
is to mark the control as critical when forwarding it and,
if unavailable, return a search continuation for that portion
of DIT.  In other cases, the server might leave the control
non-critical in chaining (for instance, possible with
sorted results... easier to merge sorted results than
to merge unsorted results).  And it other cases, it might
be best to strip the control and handle all the
operation semantics locally (for instance, possibly with
sorted results).

But the issue here shouldn't be how the server maintains
the semantics, but what semantics the client can rely on
the server to maintain.   The client be able to rely on
each non-critical control applying to all the results or
none of the results returned for the request.

Kurt

At 08:18 PM 3/31/2005, Jim Sermersheim wrote:
>>>> Mark Ennis <[email-masked]> 3/31/05 8:21:43 PM >>>
>>While I agree that the idea of testing the capabilities of the servers 
>>is not practical, I do think the idea of defining procedures for 
>>distributed operations which force controls to be critical and then 
>>process the results of distributed requests to form an appropriate 
>>response to the clients original request is potentially viable. This 
>>assumes that a control specification is not permitted to mandate that a 
>>control MUST be non-critical.
>>
>>That said, I do agree that non-critical controls should be ignored 
>>rather then result in an error code for the operation. And this would 
>>simplify procedures for distributed operations for LDAP.
>If it is not immediately known whether a control would cause an error, then at what point can a non-critical control be ignored? Prior to name resolution? Prior to operation evaluation? During operation evaluation? Before sending any responses to the client? After sending responses to the client?
> 
>Similarly, when does one know whether to return an error versus discarding an transaction which has begun and re-starting the operation sans the control?
> 
>Also, some controls define error codes to be returned for certain conditions (see VLV for example). When these conditions are met when the control is non-critical, should it also be ignored and the operation be re-applied without the control?
> 
>There are cases where allowing non-critical controls to be ignored doesn't simplify the distributed operation problem. When a control is paired with a response control which indicates whether or not the control was successfully applied, then the chaining server is still faced with having to deal with different behaviors of chained-to servers. Also, any non-critical control on search operations may succeed on an initial server, and be ignored when chained to another server. Meaning the control was partially supported. I think most people would agree that this is undesirable — a control should either be applied or ignored unless that control specification allows it to be partially applied. 
> 
>Also consider the tree delete control. A client may send this as non-critical, knowing (well, expecting) that if it's recognized and appropriate, it will be applied, and the subtree will be deleted. If it can partially fail (due to being chained or sent to multiple backends), the subtree may be partially deleted and the tree left with a hole in it.
> 
>Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 01 Apr 2005 09:09:34 -0700

>>> "Kurt D. Zeilenga" <[email-masked]> 3/31/05 10:43:16 PM >>>
<snip>

>I think s/appropriate/appropriate in the server's determination/
>would be appropriately vague.

If the WG is fine with the added behavioral differences (at the benefit of added service) this brings, then fine. We can update with this, and even add that the operation + any controls is not to be applied in a partial manner.
 
It's still confusing to implementors and clients. Does "appropriate for the operation in the server's determination" extend to include "and the server is willing to perform it"? Meaning, if the server can (at some early or pre stage) determine that the user has insufficient rights to perform the operation + non-critical control, can it ignore the control? "Appropriate for the operation" (whether determined by the server or not), still seems to me to indicate that the control specification named that operation as one valid for the control to be attached.
 
I'm not sure the reader is left with an any more clear understanding of how to implement or what to expect. If we want the behavior to be what you and Howard are suggesting, then I think replacing the word "appropriate" altogether is better. It should say "If the server is able and willing to support...". 
 
That's what you're really saying isn't it?