[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Defaults for Compound Entries
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email D.W.Chadwick@salford.ac.uk *NEW*
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************
Defaults for compound entries.
At the Oslo meeting the issue of what should be the appropriate default for dealing
with compound entries was raised. There are of course 4 cases to consider, where
?old? refers to an LDAP component that does not understand compound entries and
?new? refers to one that does, viz:
i) old client, old server
ii) old client, new server
iii) new client, old server
iv) new client, new server
Case i) is uninteresting and refers to the situation we have today, where neither client
nor server support compound entries.
Case iv) is likewise uninteresting as the issue of default action is immaterial, it purely
affects compactness of encoding in the protocol.
Case iii) is similarly uninteresting, as the existing LDAP control mechanism allows
the client to say whether compound entries are critical or not to its operation.
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.
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.)
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.
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.
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.
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.
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).
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.
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.
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.