Re: Defaults for Compound Entries

[David Chadwick <d.w.chadwick@salford.ac.uk>]

Date forwarded: 	Sat, 17 Jul 1999 13:09:39 -0700 (PDT)
Date sent:      	Sat, 17 Jul 1999 13:28:57 -0700
From:           	rweltman@netscape.com (Rob Weltman)
Organization:   	Netscape Communications Corp.
To:             	ietf-ldapext@netscape.com
Subject:        	Re: Defaults for Compound Entries
Forwarded by:   	ietf-ldapext@netscape.com

> 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.

I dont understand why the client will be confused. If you do a full
subtree search of any LDAP server anywhere in the world today
and simply enter the keyword *john* you are bound to get back
hundreds of entries (unless you hit the admin limit of the server). SO
I dont see why you say a client will be confused, since they should
have already been built to cater for this. Each entry is returned with
its full distinguished name, remember, so it easy to differentiate
between them. I admit you may have a problem with clients that only
display the last RDN, but this is a bug with the client and it will also
be apparent today, for example if you have a John Smith in OU=1,
and a John Smith in OU=2, the client will not display the difference
to the user, they will look like the same entry containing different
attributes, and this will be confusing.
(In fact, there is a problem today with Netscape when you view
X.509 certificates, as it does not properly display the subject DN
field)

>
> >
> > 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.

But this is a bug in the client, especially given the fact that each
entry should hold an operational attribute saying whether it is a leaf
or not (X.500 model) or the count of subordinates (Netscape
proposed model for LDAP as discussed in Oslo)

I agree however that clients are usually built with a particular DIT
structure in mind, and they dont work too well when they hit an
unusual (to them) structure. This is why many organisations
purchase clients specifically tailored to their DITs. In fact the best
client that I have used that can cater for any DIT structure is a
standard web browser e.g. Netscape, using HTTP to the web500
gateway product from University of Chemnitz. It is much more
flexible than the typical built in LDAP client.

Several clients actually have quite a long way to go yet in producting
a good LDAP client that retrieves just the information you want it to.
(The sort of blunderbuss OR filter you described above is quite
appalling actually - it aims to maximise the number of hits to ensure
the entry you want is buried there somewhere in the hundreds
returned. Whereas what you should be trying to do is minimise the
number of hits and still ensure the entry you want is in this small
number.) You and other client designers would do well in reading
Paul Barker's PhD thesis on white pages searching, available from

 ftp://cs.ucl.ac.uk/dirpilot/pbthesis/

>
> >
> > 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).
>

Do most clients today support Compare? I am not aware that I can
perform this operation with MS or Netscape clients can I? RSVP

> >
> > 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

I dont know who "most" refers to here? Do you mean MS and
Netscape? I have two clients on my PC that can modify entries
(neither MS or Netscape can that I am aware of) and both of these
allow me to browse the tree and pick the specific entry I want. I
suspect that Novell's client can do this as well. So I question your
assertion that most clients work the way you say.

> matching a particular search expression.

This seems like a pretty dumb way to target an entry if you ask me.
If I type in Salford and it returns the org entry for University of
Salford would you expect me to be able to delete it? Obviously not. I
have to pick up leaf entries from browsing the tree. So not
identifying leafs in this sort of search seems to be an important
omission from those clients.

>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;

poor client implementation if you ask me

>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.

Come on Rob. Didn't someone from your company give a
presentation in Oslo about an operational attribute you have defined
that counts the number of subordinates (including referral and glue
DSEs that dont have any entry information in them.) So counting the
number of children in a family wont be difficult will it. Furthermore
there is the parent object class defined in the ID that tells the client
that the entry is not a leaf, but part of a family and it has children.
Therefore there are at least 2 easy ways to determine if an entry is
a leaf or not.

>Most clients I am
> aware of do not have a list (one-level search or browse) function.

This will definately pose a problem I agree. But then a car with an
engine but no gearbox will have difficulty in travelling fast on the flat
and going up steep hills as well. Half an LDAP client will have more
problems that a full client. Fortunately the client I use most and like
best has all the features.

>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.

I agree with you that this is a problem for "half" an LDAP client i.e.
one that only supports half of LDAP. If you remember Roland's
presentation at the LSD2 BOF in Oslo, he said that the problem with
running a multi-organisational directory service today is not that the
LDAP protocol is short of features, but the fact that suppliers  have
only implemented part of the protocol, and this is not yet sufficient
for a good service. (Apologies to Roland if I have misquoted him)

However, even half an LDAP client should allow the user to enter
any distinguished name and perform a full subtree search on that,
should it not? Otherwise it is not even half a client. So, why cant I
put in the name (DN) of the person and do a full subtree search with
a simple * as the filter (i.e. return all entries). I can do this with
Netscape by setting the Search Root parameter.

>
> >
> >
> > 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 ***
> >

Rob you made comments on lots of my message, but did not make a
comment on the bit that I specifically asked for comments on. Could
you comment on the above please. Ta


> > 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?
>

Answer, all of them. Servers today return as many entries as match
the filter, and clients today deal with this (some better than others,
admittedly)

>   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.

Exactly. This is what we are trying to move away from before it gets
too embedded. Having to parse all attribute values to get at
embedded information in order to understand the relationships
between different attibute values is more than ugly. It is inefficient as
well.

>
>   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.

I believe that the largest deployed directory today (NDS) supports
this. I dont know if Active Directory might, we shall have to wait and
see.

>
> >
> > 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.

They should! I dont believe you are correct here. If different
services have different passwords, and each service is in a child
entry, it would be a security flaw to allow the wrong password to gain
access to a service.

>
> >
> > 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.

this is certainly consistent, but we have a problem with Modify as
discussed below

>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.
>

This is because the user has less than half a client that cannot
browse or do full searches from any DN. Even Netscape will allow
the user to add the DN of the ancestor into the Search Root
configuration parameter, and this should then return the whole
family, should it not? RSVP on this one.

> >
> > 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?

By specifying the DN of course (or selecting the one after the
search has displayed the results, using your model).

It will be impossible to update a family as a single compound entry,
since the same attribute value might reside in two different children.
Then how do you specify which of the two values is to be updated if
you can only refer to the compound entry. Think about that one
please. If you have an answer to this, you can better convince me
that treating the family as one entry by default is feasible.

>And how will the user even be sure he/she has found
> all the entries associated with the family?
>

By doing a full subtree search of the ancestor as explained above

> >
> >
> > 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.
>

Well I would get pretty annoyed as well if I thought I had bought an
LDAP client, only to find it was quarter of a client that could not
support half of the LDAP protocol suite.

>   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.

Agreed, this should be the aim. But by existing clients, you seem to
be referring to partially implemented LDAP clients, and I dont think
that it will be feasible to cater for these.

David
>
> Robl
>
>
>
>


***************************************************

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

***************************************************