Subject: Re: Partially suppported supportedControl/supportedExtension

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 13 Aug 2004 11:09:04 -0600

It gets worse than this.

What about a server which chains requests? The server has no idea what
the capabilities of remote servers are, and can't know unless it
interrogates all DSAs listed in locally held knowledge information. Even
if one attempted this, there are lots of complications that arise (what
if two DSAs are listed for a reference object, and one supports the
extension in question?). Alternately, I suppose locally held knowledge
information could be enhanced to hold supported* data for each remote
DSA.

Currently, for supported* attributes, we (at Novell) have limited the
list to the local DSA. It could be argued that a single DSA fronting
multiple backends is not much different from a single DSA which chains
to other DSAs.

Maybe we should say that the supported* attributes indicate possible
support, or support (subject to access control, administrative, and
other factors).

Jim

>>> Hallvard B Furuseth <[email-masked]> 8/13/04 7:21:38 AM
>>>
Should the root DSE's supportedControl, supportedExtension and maybe
supportedSASLMechanisms be defined to only list values that are
supported by the entire server, not values that are supported for only
part of the server?

An OpenLDAP user has reported a problem because an OpenLDAP server can
have several naming contexts served by different backends, which may
support different controls.  I think supportedControl reports the
controls that are supported by any of the backends.

So the client found pagedResults in supportedControl, and issued a
paged
results request with a baseDN which was served by a backend which did
not support pagedResults.  That failed, of course.

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 17 Aug 2004 12:23:22 -0600

I agree with the proposed clarification to Protocol A.2

>>> "Kurt D. Zeilenga" <[email-masked]> 8/14/04 2:45:07 AM >>>
First, let me clarify the particular problem case:
  The client provided an advertised critical control to a
  search operation.  The server responded with
  unavailableCriticalExtension.

I would argue that advertisement implies the server
recognizes and understands the control (that is,
it is 'supported') BUT that the advertisement
doesn't necessarily imply that any particular
operation extended by the control is serviceable.
However, if not serviceable (for whatever reason),
the server should return a service error, such as
unwillingToPerform, not unavailableCriticalExtension.

This problem is likely the result of language in some
control specifications which suggests returning
unavailableCriticalExtension in cases where the
server cannot service the operation as extended
by the controls.  I view these specifications
to be flawed.

Anyways, I think [Protocol, 4.1.12] is fine here.
However, the description of unavailableCriticalExtension
in [Protocol, A.2] needs a bit of work as "unable or
unwilling to perform" implies a service error.
Instead,
   unavailableCriticalExtensions
	Indicates a critical control is unrecognized
	(see Section 4.1.12).