[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RFC2251: RootDSE subschemasubentry issue
Date forwarded: Mon, 7 Feb 2000 09:40:11 -0800 (PST)
Date sent: Mon, 07 Feb 2000 09:40:04 -0800
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RFC2251: RootDSE subschemasubentry issue
Forwarded by: ietf-ldapext@netscape.com
> As previously noted <8525679B.003DD02B.00@D51MTA04.pok.ibm.com>,
> RFC 2251 states subschemaSubentry attribute type within the
> Root DSE may contain multiple values though the attribute type
> is single valued.
Sorry, I dont follow this. What do you mean by "THe attribute type is
single valued." Do you mean the attribute type definition mandates a
single valued attribute? This is surely wrong, as the definition must
allow for multiple values.
>
> I do not believe it necessary to provide a mechanism to allow
> clients to obtain a complete list of subschema entries (or
> subentries) known to this server.
This is part of the confusion, and is due to poor wording in 2251.
What the RFC is trying to say is "subschema entries known to be
controlling the entries held in this server". It does not mean
subschema entries anywhere in the world that this server happens to
know about. If you read further in the RFC you will find some
limited clarification about subschema subentries for master and
copy entries viz:
If the server does not master entries and does
not know the locations
of schema information, the subschemaSubentry
attribute is not present
in the root DSE. If the server masters
directory entries under one
or more schema rules, there may be any number
of values of the
subschemaSubentry attribute in the root DSE.
Again, this is ambiguously worded, as "may be any
number of values" should really be "will be an
equivalent number of values"
> This list could be quite
> large and, IMO, rather useless. Applications need to known
> which subschema controls which entries.
Agreed. This is due to a wrong interpretation of the RFC (due to
ambiguous wording)
>
> I suggest that applications obtain the DN of the subschema entry
> (subentry) from either the entry(ies) they intend to access or
> from the entry at the root of the naming context.
In general a client may not know the root of the naming context, but
will know the root of the DIT, hence the ability to find the subschema
entry from the root.
>
> To resolve this issue, I suggest:
>
> RFC 2251, 3.4 "--subsubschemaSubentry" subsection be removed
> and that a note be added to the end of the section:
I disagree, but a better wording should be used.
>
> Note: the subsubschemaSubentry attribute type, if
> present, contains the Distinguished Name of the
> subschema entry (or subentry) which controls the
> schema for the Root DSE.
This is wrong. The subschema subentry does not control the
schema of the root DSE - nothing does. Rather it controls the
schema of a naming context.
David
>
> Comments?
>
> Kurt
>
>
>
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************