Re: Partially suppported supportedControl/supportedExtension

["Jim Sermersheim" <jimse@novell.com>]

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 <h.b.furuseth@usit.uio.no> 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