Re: draft-ietf-ldapbis-protocol - controls

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