[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: subschema clarifications (Was: I-D ACTION:draft-ietf-ldapbis-models-01.txt)
Kurt,
I think that this issue of "server capabilities" is becoming more and more
important. I also think it extends beyond what schema elements are or
aren't supported by the server.
I agree (in principle) with the notion that a server should not
include/advertise schema elements that it does not support all the
"semantics" of ... but this can get "dicey" in practice with deployments
adding schema elements (a server can't know what new schema elements MIGHT
be defined in the future that bring along other "semantic" requirements ...
thus a server would hard-pressed to disallow the schema elements from being
added into the server's "advertised" schema.)
I would like to see some "standard" way for servers to identify the set of
features/functions that they support - e.g.: acl model, replication model,
password policy, alias support, etc. Some of these imply server-based
processing that is "over and above" just allowing the associated schema
elements to be stored/retrieved to/from the server.
More and more reasons for looking hard at some "admin model" so that these
features can be constrained to "areas of the namespace" rather than
focussed on server instances.
Regards,
Tim Hahn
Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388 tie-line: 8/852.6388
fax: 607.752.3681
"Kurt D. Zeilenga"
<Kurt@OpenLDAP.org> To: ietf-ldapbis@OpenLDAP.org
Sent by: cc:
owner-ietf-ldapbis@O Subject: subschema clarifications (Was: I-D ACTION:draft-ietf-ldapbis-models-01.txt)
penLDAP.org
05/31/2002 01:36 AM
At 07:47 AM 2002-05-30, Kurt D. Zeilenga wrote:
>Summary of technical changes made:
> - clarified schema publishing / discovery;
A little elaboration...
This revision includes clarifications aimed at resolving a
couple of subschema discovery issues.
Over the years, a number of questions have been raised
regarding how clients determine that a server supports
capabilities associated with elements of schema, in
particular, operational attributes. For example, how
does a client determine whether a server supports
DIT Content Rules.
I've taken statements in Section 4.1.4 of RFC 2251 that
the attributeTypes attribute is used to indicate "support"
for an attribute type. In -00 revision of the I-D, a
server indicated support for a number of capabilities
(such as DIT Content Rules) by publishing the definition(s)
of attribute type(s) associated with the capability.
But for this to be a clear indication of support, it is
necessary to disallow servers which don't support the feature
from publishing the defintions associated with that feature.
Hence, the -01 revision includes the statement:
A server SHALL only publish schema definitions for
elements it supports.
Without this, the discovery mechanism would be fundamentally
broken.
However, the added statement can be viewed as inconsistent
with other statements made in existing "core" technical
specification. So, it might be appropriate to clarify
that the subschema mechanism is not capability discovery
mechanism. If so, do we need one or can we live with
trial and error discovery mechanism? (Personally, I can
live with trail and error, that's what most clients will
do anyways.)