Re: Defaults for Compound Entries

[mcs@netscape.com (Mark C Smith)]

This is an interesting discussion.  See my comments below.


David Chadwick wrote:
> 
> Rob,
> 
> I have not copied my message and your answers again as it is
> getting too long. Suffice to say you have one mis-understanding
> about the way that a whole family is represented as single
> compound entry in a result. You thought that, quote
> 
> I was assuming that a single entry would be returned with the union
> of attributes of the family members. The association information that
> was embodied in the structure of the family would be lost, but that's
> the best a clueless client can hope for.
> 
> This has never been proposed or suggested. The proposal is to have
> a complex structured attribute that contains RDNs followed by the
> attributes in that family member, so that the structure is maintained.
> (Read the ID section 5.1 again for a definition of this). If the whole
> set of attributes from each family member were to be merged
> together on retrieval then this would negate the whole purpose of
> families, which are to link together related sets of attributes. The
> merging together would remove their whole purpose for existance,
> and so there would be no point in having them!! Thus the alternative
> to the complex attribute in a single entry is simply to send each
> family member as a separate entry so that the relationships between
> attributes can still be maintained.

So for the situation where an LDAP client that is not compound entry
aware (an "old" client) is operating against a server whose DIT contains
compound entries (a "new" server) the choices presented so far are:

1) A significant change in the LDAP information model that is not
backwards compatible with LDAPv2 or LDAPv3 (i.e., one in which some
regular attributes are transformed into complex attributes)

OR

2) A significant change in the LDAP operational model that is arguably
not backwards compatible (i.e., where entries are replaced by a tree of
entries and more than one entry may be returned from a search that
previously was known to return one).

Either choice will break many clients.  Your (David's) argument seems to
be "those clients should be fixed" but I don't believe they are broken
when measured against the LDAPv3 specifications.  The burden is on us
who are extending the standard to be as compatible as possible with
existing clients.  Unlike many of the extensions previously discussed in
LDAPEXT, compound entries are something existing clients will likely
trip over.  I think that is Rob's concern and I am worried too.


> ...
> Clearly there is a problem with the existing MS and Netscape clients
> that hide the DNs and the DIT structure and that return subtrees of
> entries as a flat picking list. However this could be catered for by
> embedding an attribute value (say common name) in each family
> entry as follows. So we could have for example in my family of
> entries:
> 
>   Common Name
> David Chadwick.......followed by a set of attributes
> David Chadwick's telephone entry....followed by a set of attributes
> David Chadwick' fax entry.....followed by a set of attributes
> David Chadwick's email entry.....followed by a set of attributes
> David Chadwick's email's account entry......followed by a set of
> attributes etc
> 
> Here the common name of each family entry is used to denote its
> position within the family. And this would work with existing quarter
> clients I think

LDAP clients come in all shapes and sizes, and design tradeoffs of all
kinds must be made by client developers.  It goes without saying that
most users are not interested in being exposed to DNs, hierarchy, or any
other LDAP concepts when all they are trying to do is address an e-mail
message to the right person within their organization.  In my opinion,
hiding the DIT structure is generally a good thing to do for most
directory users.  I don't think it is fair to imply that the client
authors should have anticipated the addition of the compound entries
feature -- although your suggested "work around" should work in some
deployments.

I'd also add that we shouldn't forget about the thousands of
applications that have a little bit of LDAP in them (MTAs, calendaring
applications, switches and routers, HR synchronization scripts, and so
on) -- we can't expect them all to be upgraded quickly to support
compound entries.

I appreciate the power contained in the compound entries proposal, but
adopting it is a very significant change for LDAP.  Unless we can figure
out how to deploy this new feature without breaking existing clients, I
fear it will never be deployed widely.  One can argue that it is
acceptable for some clients to need revisions before they can be used
with a directory service in which compound entries are stored -- but
this need will greatly slow down adoption of the compound entries
feature.  I don't see any way to avoid that though.  Clever ideas are
welcome.

-- 
Mark Smith
Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.  Got LDAP?