Re: Models: modifying subschema subentry

[Steven Legg <steven.legg@adacel.com.au>]

Jim,

Jim Sermersheim wrote:
> In Section 4.4, there is: "To read schema attributes
>   from the subschema (sub)entry, clients MUST issue a base object search
>   where the filter is "(objectClass=subschema)" [Filters] and the list
>   of attributes includes the names of the desired schema attributes (as
>   they are operational).  This filter allows LDAP servers which gateway
>   to X.500 to detect that subentry information is being requested."
>  
> The last bit is interesting. This is so the LDAP server knows that the 
> client is reading a subentry as opposed to a directory entry. This 
> presumes that there are cases where the LDAP server needs to know the 
> difference, and this special filter is given as that way.

The case where the LDAP server needs to know the difference is when it
translates the LDAP search into a DAP or DSP search. A DAP/DSP base object
search of a subentry will return noSuchEntry if the subentries bit of the
ServiceControls options is not set (which seems to be an unnecessary
condition, but is there nonetheless). The LDAP server needs to have some
way of deciding whether or not to set the subentries bit. The filter on
objectClass is that way.

>  
> Earlier in Section 4.2 it says "Servers MAY allow subschema 
> modification.  Procedures for subschema modification are discussed in 
> Section 14.5 of [X.501]."
>  
> This is new text (was not in RFC 2251). This does not consider the case 
> where the LDAP server needs to know the difference (as above) and 
> doesn't provide a way for the client to convey the difference.

The subentries bit is ignored for DAP/DSP operations other than search
and list, so a DAP/DSP modify will operate on the base object regardless of
whether it is a subentry or entry.

It would have been nice if X.500 ignored the subentries bit for base
object searches as well.

Regards,
Steven

>  
> Jim