[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