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

Re: subschemaSubentry within the root DSE



A couple of minor changes to suggestion:

>The 3.4 text:
>  - subschemaSubentry: subschema entries (or subentries) known by this
>    server.
>
>be replaced with:
>  - subchemaSubentry: the name of the subschema entry containing the
>       schema controlling the root DSE.

s/subchema/subschema/ 
s/entry/entry (or subentry)/


>The 3.4 text:
>  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.
>
>be deleted.
>
>Section 6.2 text:
>  The client can retrieve the subschema entries referenced by
>  the subschemaSubentry attribute in the server's root DSE or
>  in entries held by the server.
>
>be replaced with:
>  The client can obtain the name of the subschema entry (or
>  subentry) controlling a particular entry by retrieve that
>  entry's subschemaSubentry attribute.

s/controlling/containing the controlling schema of/

>These changes make the use of subschemaSubentry attribute consistent
>throughout the LDAP technical specification and with X.500.
>
>The addition of a note that LDAP does not address the subschema
>chicken and egg problem (discovery of schema controlling a yet
>to be added entry at the root of a subschema administrative
>area) might be also be appropriate.

Of course, the problem with adding such a note is that it would
beg the question "What's an administrative area?"... and I don't
think we want/should/can to go there.

Kurt