Re: Partially suppported supportedControl/supportedExtension

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 09:17 AM 8/24/2004, Michael Ströder wrote:
>Kurt D. Zeilenga wrote:
>>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.
>
>Gee...yet another
>
>oh-yes-it-is-announced-by-the-server-but-the-client-cannot-rely-on-it
>
>feature.

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.

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

>So I suggest to add the following note for RootDSE attributes supported*:
>
>  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
>  implement a proprietary local client configuration for defining
>  whether such a feature is available or not.

Or use the no-op control to determine servicability.

>Still expect things to be even more weird...