[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: unimplemented schema elements (was: models-09 comments)
Hallvard,
I note in your post that you don't distinguish between recognizing
the NAME of a schema element from otherwise supporting that schema
element. The language in [Models], which comes from the language
of RFC 2251 and RFC 2252, does.
[Models], like RFC 2252, says that implementations MAY support the
extensibleObject object class. [Models], unlike RFC 2251, says
that servers MUST recognize the name of the extensibleObject object
class.
At 09:23 AM 1/7/2004, Hallvard B Furuseth wrote:
>What is the reason for requiring servers to recognize schema elements
>they do not support anyway?
I always interpreted the language as requiring the server to
recognize that the NAME is an alias of a particular OID. I
can see a number of reasons to require this. For instance,
if a server is providing shadow/cache copies of entries and
the client asserts (objectClass=1.3.6.1.4.1.1466.101.120.111)
the server should be able to match copies which include the
objectClass value of 'extensibleObject'.
Also, I view the requirement to recognize the NAME as implying
the server is to prevent that NAME from being associated with
other OIDs. Also, I note, that to implement RFC 2252:
those (servers) which do not (implement extensibleObject) will
reject requests to add entries which contain this object class,
or modify an entry to add this object class.
requires the server recognize the name of the objectClass.
Otherwise it would not be capable of rejecting such requests.
That is, one could argue that servers which don't recongize
extensibleObject MUST instead implement special handling to
prevent incompatible use of extensibleObject. Otherwise
the feature is not truly optional as implied by the MAY.
>That is, [Models] 7.1 Server Guidelines:
>
> Servers MUST recognize all attribute types and object classes names
> defined in this document but, unless stated otherwise, need not
> support the associated functionality. Servers SHOULD recognize all
> the names of attribute types and object classes defined in Section 3
> and 4, respectively, of [Schema].
>
>As you said in this thread, schema elements that are recognized or
>published but unsupported cause problems for clients.
Especially where "support" implies some operational semantics
beyond that conveyed in the schema description.
>I would think it
>would make more sense if a server MUST NOT or at least SHOULD NOT
>recognize or publish schema elements which are defined to have
>functionality which the server does not support.
This is a discussion we've already had. I note that the
shadowing case above is a good example of where a server,
the shadow, may not support the feature associated with the
published schema element. However, being a slave, it doesn't
need (for interoperability sake) to support the feature, it
just needs to recognize the name. Of course, it would be
nice if administrators (using a client or other means) would
not add the extensibleObject description to any subschema
unless the server supports this functionality associated
with extensibleObject and requires the administrator to
add the description (to make use of this functionality).
Kurt