Re: Defaults for Compound Entries

[rweltman@netscape.com (Rob Weltman)]

David Chadwick wrote:

> Case ii) is the really interesting case. We have several choices. If we decide (as in the
> current ID) that the default action is that compound entries are treated as a subtree of
> separate entries, then the following will happen for each operation:
>
> a) Assuming the client thinks the compound entry is a single entry, a Search on a
> base entry only (a read type operation) might fail because the filtered attributes are
> actually in child entries and not in the ancestor. Likewise, if the ancestor does pass
> the filter, only the ancestor will be returned and not the child entries so
> information might appear to be missing in the result. However if the client sees the
> whole family of entries (via browsing), Searches can be performed on each child
> entry individually, and individual children can be read and returned.

  Most clients (mail clients, for example) do subtree searches. They are not smart about
searching only for the person objectclass, for example, but just create a search filter that
includes a number or OR'ed clauses such as
"|(cn=*john*)(sn=*john*)(givenname=*john*)(mail=*john*))" if you type in "john". Depending on
how you have distributed cn, sn, givenname, and mail attributes among the ancestor and the
children, you may get one or many entries back, and the client will be confused.

>
> b) A one level Search (browse) operation on the immediate superior of the ancestor
> e.g. an organisation entry, would show that a person?s entry was not a leaf entry.
> The client would then need to ?list? the children of the person?s entry.
> Alternatively the one level Search might fail, because the attributes placed in the
> filter (eg mail = a particular mail address) are unexpectedly held in children of the
> ancestor. A one level Search operation on the ancestor would work by treating all
> the immediate children as separate entries and would therefore behave as expected
> (the client obviously knows that the ancestor is not a leaf entry otherwise it would
> not have issued the request.)

That's probably true in many cases. However, some clients may assume that entries with the
objectclass of person are leaf entries.

>
> c) A Compare operation is a bit like the base entry Search, and a Compare on the
> ancestor may fail because the attributes are actually in a child entry. Compares
> however, can be performed on each child entry individually.

That will not work well with most current clients, since they assume only entry with e.g. the
common name "John Johnson" or the uid "johnj". The attribute being compared may live in
another entry (within the family).

>
> d) A Remove Entry on the ancestor would fail because it is not a leaf entry.
> However, the client is able to delete the individual children one by one.
> e) ModifyEntry and ModifyDN always operate on individual child entries and since
> these are always visible to the client it is not a problem.

 It is most definitely a problem. The way most clients work is to present a list of entries
matching a particular search expression. Then a user can select an entry in the list and
request to delete it. The client gives no indication that an entry is a leaf node or not; as a
matter of fact it assumes that person entries are leaf entries and can be deleted. There will
be no way (that I can think of) for most clients to allow the user to discover that a person
entry has child entries which must be deleted first. Most clients I am aware of do not have a
list (one-level search or browse) function. If there are ten members of a family of entries,
and two of them match the search criteria in some way, then those two will show up as two
independent entries in the list of search results, and the other eight will not show up at
all. The user may be able to delete one of the entries if it happens to be a leaf node, but
may not be able to delete the other one, and will have no idea why not.

>
>
> If we decide that the default action is that compound entries are treated as a single
> entry then the following are the consequences.
> a) Assuming the client thinks the compound entry is a single entry, a Search on a
> base entry only (a read type operation) would always be more likely to succeed
> because the attributes in all the children would be merged before the filter was
> evaluated. The return of information poses a problem. Either multiple single
> family entries would be returned instead of the single ancestor that was expected
> (which might confuse or break the client); or if the family-information derived
> attribute was implemented, a complex formatted attribute would be returned.
>
> ***I need advice here from existing implementers as to whether or not this would
> break existing LDAP client implementations or would be no problem ***
>
> Assuming the client thinks the compound entry is a family of separate entries, i.e.
> the old server used to hold them like that and has recently been upgraded to a new
> server, then more hits than expected might be returned due to the merging of
> attributes prior to evaluating the filter. Worse than that, a lot more information
> would be returned than expected due to the reasons outlined above. Finally it will
> not be possible for the client to access each child entry individually, the whole
> compound entry must be accessed via the ancestor.

  What current servers return multiple entries for a single person? What current clients can
deal with a server like that?

  In the absence of clients and servers that understand families of entries, I would expect
all real-world DITs of today to include all attributes of a "person" in a single entry with
multi-valued attributes. In some cases, people use ugly tricks to enforce ordering or
association of attribute values, such as adding a subtype to the attribute names or an
identifier to the attribute values. But still, all data in a single entry.

  Of course, that may not be the case for systems using custom clients. I'm only talking about
common standard clients such as mail clients and LDAP gateways.

>
> b) A one level Search (browse) operation on the immediate superior of the ancestor
> e.g. an organisation entry, would show that a person?s entry was a leaf entry. This
> would be fine for most clients, except that it would confuse those old clients
> where the old server had held families as separate entries, and the server has now
> been upgraded. Child entries would appear to have disappeared. One level
> Searches on the immediate superior of the ancestor are more likely to succeed,
> because the attributes from the whole compound entry have been merged together
> prior to filter evaluation. More information would be returned that expected for
> the reasons given in a) above. Finally, it would not be possible to Search on
> separate entries within the family as they are not visible to the client.

  Again - this assumes that DITs today include families of entries to represent a single
person, and that clients understand and expect this. I don't think either assertion is true in
general.

>
> c) A Compare operation is a bit like the base entry Search, and a Compare on the
> ancestor is more likely to succeed because the attributes from the child entries are
> merged prior to operation evaluation. Compares cannot be performed on each
> child entries individually. This might be a problem if separate passwords are held
> in child entries, the client would not know if the correct password has been used
> (it would be equivalent to having a multi-valued password attribute in the ancestor
> entry, and the client only know that one from a set of passwords is known to the
> user).

  In most cases, clients do not care which password was used to authenticate.

>
> f) A Remove Entry on the ancestor would succeed and the whole family of entries
> would be deleted. The client would not be able to delete individual children. In my
> opinion this is a bad thing. Comments please.

  In my opinion this a good thing, because it makes the client program behave the way the user
expects it to behave. A search for "uid=johnj" returns a single entry; the user can select it
and delete it; the user is happy. The alternative: the user may or may not be able to delete
the entry/entries found and will not know how to go about deleting it/them.

>
> g) ModifyEntry always operates on single entries within a family. This might mean
> that old clients would no longer be able to update compound entries. (Otherwise
> there is a bit of a disconnect ? the compound entry appears to be a single entry
> except when it is updated.) Is this a problem or not. Comments please.

  Yes, this is a problem, for the same reason as the delete: how will the user know which of
the entries to modify? And how will the user even be sure he/she has found all the entries
associated with the family?

>
>
> My conclusion to all of the above is that the existing default (treat the compound entry
> as individual entries) causes less problems than changing it to always assuming that
> the compound entry is a single entry. We might decide to have a hybrid model i.e. that
> for Search, we treat the compound entry as a single entry, but that for updates they are
> treated as separate entries. Comments please.

  The more I think about it, the more I'm sure that treating the family members as individual
entries (for any operation) will confuse existing clients and cause users of said clients to
go ballistic.

  That said, I think there is value to families of entries; the trick is to make that value
available to smart clients without breaking many of the existing clients.

Robl