[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: RFC2251: RootDSE subschemasubentry issue



At 11:07 PM 2/8/00 -0000, David Chadwick wrote:
>> 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?

Yes.

RFC 2252, 5.1.5. subschemaSubentry 
   
   The value of this attribute is the name of a subschema entry (or
   subentry if the server is based on X.500(93)) in which the server
   makes available attributes specifying the schema.

    ( 2.5.18.10 NAME 'subschemaSubentry'
      EQUALITY distinguishedNameMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
      SINGLE-VALUE USAGE directoryOperation )

>This is surely wrong, as the definition must 
>allow for multiple values.

I believe SINGLE-VALUED is appropriate as an entry can only
have one controlling subschema subentry.  I believe the
use of this attribute type when the RootDSE to list available
subschema subentries is inappropriate as it imparts no
knowledge to the client as to which value controls which
entries.

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

Which implies that the subschema controlling an
entry may not be listed in the RootDSE whilst other
subschemesubentries are listed, such as when the
entry is not mastered by the server (and subschema
not published this slaves), yet other name contexts
are.

>Again, this is ambiguously worded, as "may be any 
>number of values" should really be "will be an 
>equivalent number of values"

In the Root DSE, which subschemasubentry value(s) belongs to
which namingContexts value(s)?

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

Something must... a client should be able to determine the
schema of attributes provided in the RootDSE and should
have some mechanism to determine which schema controls
the RootDSE.

>Rather it controls the 
>schema of a naming context.

Which naming context?

A server can support multiple naming contexts each with
different controlling subschemas.  The subschemasubentry
values of the RootDSE are fairly worthless without knownledge
of which value controls which naming context.