Re: draft-ietf-ldapbis-protocol - controls

I'm pretty sure this topic was discussed before, but I need to raise it 
again. The current language regarding the treatment of non-critical 
controls is somewhat ambiguous; it does not define what is "appropriate" 
for a control and this definition is essential for interoperability.

The specific problem I'm seeing is with OpenLDAP slapd being accessed by 
(ex-CA) JXplorer. slapd advertises all the controls that it 
recognizes/supports in the rootDSE, as expected. However, not all 
controls are supported in all the contexts that the server holds. For 
example, the PagedResults control is only supported by the OpenLDAP 
back-bdb backend, other backend types don't handle it. And the slapd 
server can be configured with an arbitrary number of backends and an 
arbitrary number of types of backends.

The first problem is that there is no way to indicate that a control is 
only supported within specific contexts, as opposed to server-wide. 
Since there is only the single rootDSE to use for advertising features, 
it would be reasonable for clients to assume those features are 
server-wide but in this case they are not.

When JXplorer connects to slapd it queries the rootDSE and reads the 
subschemaSubentry before examining any user data. If it sees that 
certain controls are supported, it attaches those to the requests it 
issues, marked non-critical. (In this case, it's the manageDSAit control.)

When slapd receives this request and determines that the control is not 
actually supported in the target context, it fails the request with 
LDAP_UNWILLING_TO_PERFORM. Kurt tells me this behavior is mandated by 
the spec:

 >>If the server recognizes the control it MUST make use of it.
 >>If it is unwilling or unable to, it is obligated to return
 >>an error.

However there is no explicit statement in the spec that actually says 
this. It only says in 4.1.11 "if the server recognizes the control and 
it is appropriate for the operation, the server is to make use of the 
control when performing the operation." (Note the absence of a MUST here.)

It later says "If the server does not recognize the control type or it 
is not appropriate for the operation, and the criticality field is 
FALSE, the server MUST ignore the control."

So, the first issue with this text is that it does not explicitly say 
what the server MUST do if all of these conditions are true:
   1) the server recognizes the control
   2) the server is unable to use the control on the given operation
   3) the control's criticality is FALSE

My view is that the definition of "appropriate" covers this case - the 
server recognizes the control but it is not appropriate for the 
operation because the target context doesn't support the control. And so 
it should be silently ignored. Kurt tells me my interpretation is not 
what the WG intends. I believe for interoperability reasons it is 
necessary to adopt my interpretation, and regardless of that decision, 
it is necessary to provide more explicit language around what 
"appropriate" means in this section.

On a slightly related topic, which I only noticed while investigating 
this issue, I see that there is a specific exception noted for 
criticality on controls attached to an Unbind operation. I don't see any 
explanation of why, but I will assume it is because
   1) controls with Criticality TRUE may cause an otherwise valid 
request to fail with an error response
   2) the Unbind request is defined to have no response

The interesting points I draw from this are:
   3) contrapositive to (1), controls with Criticality FALSE may NOT 
cause an otherwise valid request to fail with an error response
   4) the Abandon request is also defined to have no response, and thus 
should have the same exception.

If (3) is true then the problem that prompted me to write this message 
is solved. Regardless, (4) probably ought to be clarified.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support