[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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