Subject: Partially suppported supportedControl/supportedExtension

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 13 Aug 2004 15:21:38 +0200

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: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 14 Aug 2004 10:45:07 +0200

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).

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Aug 2004 22:30:59 +0100

>unwillingToPerform, not unavailableCriticalExtension.
Another question that follows: does this give the client enough 
information to gracefully handle the error?
I.e. can the client assume that the unwillingToPerform error means that 
the client should retry the operation without the control and it may 
then succeed?
If RootDSE hasn't advertised support for the control, the client 
wouldn't have tried to use it in the first place.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Aug 2004 22:41:16 +0100

>supported by the entire server, not values that are supported for only
I actually disagree, I think that a server should list values that are 
supported by any part of the server.
Imagine a situation when certain SASL mechanisms are only available for 
certain users. If root DSE doesn't advertise a SASL mechanism which is 
available for a particular user, a well behaved LDAP client will not try 
this mechanism. Now, if this is the only available SASL mechanism for 
the user, the client will be unable to bind using SASL.

I think the same argument applies to controls and extended operations.

Unfortunately I know of no mechanism to advertise a particular feature 
as available for a user, a subtree, etc.

Alexey

---

From: Michael Ströder <[email-masked]>
Date: Tue, 24 Aug 2004 09:06:51 +0200

> as available for a user, a subtree, etc.

I'm pretty sure you know such a mechanism:
(Sub schema) sub entries.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 24 Aug 2004 09:04:31 +0200

> information to gracefully handle the error?

I think it does not give any information.

> the client should retry the operation without the control and it may 

No, the client can't. IMO unavailableCriticalExtension is the more 
appropriate error code to be returned to give the the client a vague chance 
to detect that something is wrong with an extended control.

unwillingToPerform as the dummy error code for nearly everything is not 
helpful at all.

> wouldn't have tried to use it in the first place.

That's a really bad situation. It means that everything still is matter of 
proprietary local client configuration which makes LDAP client 
implementation and deployment harder.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 24 Aug 2004 09:17:50 +0200

> operation extended by the control is serviceable.

Gee...yet another

oh-yes-it-is-announced-by-the-server-but-the-client-cannot-rely-on-it

feature.

This reminds me of quite a few other this-is-optional-features discussed 
here such as unsupported schema elements which are present in sub schema.

> 	Indicates a critical control is unrecognized

Kurt, this issue is not just a matter of language in the standard. It's a 
LDAPv3 design flaw. Such issues should be fixed instead of defined away with 
an even more general error code.

So I suggest to add the following note for RootDSE attributes supported*:

   The attribute values herein are completely useless. You have to
   implement a proprietary local client configuration for defining
   whether such a feature is available or not.

Still expect things to be even more weird...

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 24 Aug 2004 12:59:56 +0200

>oh-yes-it-is-announced-by-the-server-but-the-client-cannot-rely-on-it

The client can rely on the server being able to recognize the
extension.  The client has to issue the operation to know whether
or not the server can service it.  This is same with any other
LDAP operation.  For instance, supportedLDAPversion of 3 implies
the server will recognize a newSuperior element in the rename
request, however it doesn't imply that any particular rename
request (with or without newSuperior) is servicable.

I think the problem here is that some folks think that a
client can somehow discover serviceability of an operation
prior to issuing it.  That's generally not feasible.  Instead
LDAP provides discovery of whether the server recognizes
select optional features.  We need to be clear to this point
in [Protocol] (and, likely, [Models]).

>This reminds me of quite a few other this-is-optional-features discussed here such as unsupported schema elements which are present in sub schema.

Yes.  And, if I recall correctly, we concluded that advertisement
of a operational subschema element did not necessarily mean that
the server could service a request making use of that subschema
element.  Advertisement means only that the server recognizes
that particular element.

>Kurt, this issue is not just a matter of language in the standard. It's a LDAPv3 design flaw.

Well, if you think LDAP was actually trying to provide
'servicability' discovery, then I would agree that it doesn't.
But I argue that LDAP never (except as extended by the no-op
control) has provided 'servicability' discovery, so I don't
view it as a design flaw. 

>Such issues should be fixed instead of defined away with an even more general error code.

A server can return a more specific service error when appropriate.

>  The attribute values herein are completely useless.

I disagree.  Or, let me say that I concur that they are
useless for serviceability discovery.  But I think they
are useful for recognization discovery.

>You have to

Or use the no-op control to determine servicability.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 24 Aug 2004 13:19:46 +0200

At 09:06 AM 8/24/2004, Michael Ströder wrote:
>Alexey Melnikov wrote:
>>Unfortunately I know of no mechanism to advertise a particular feature as available for a user, a subtree, etc.
>

You and Alexey may be disagreeing as to what 'available' means
(and, likewise, what 'supported' means).

It my view that 'supported' does not mean 'servicable'.  A
server can support version 3 of LDAP without being able to
service all LDAP operations.  Likewise, a server can
support an extension without being able to service all LDAP
operations make use of that extension.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Aug 2004 12:32:13 -0700

After review of [Protocol] and [Models], I believe this issue
has already been adequately addressed by describing each of
the "supported" attributed attributes as naming "recognized"
elements.  However, I would not oppose adding additional
clarification.  Specifically, I suggest replacing the term
'supported' with 'recognized' (or 'implemented') in the prose
([Models, 5.1.x]) which describes values of these attributes.

Kurt