Re: Defaults for Compound Entries

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

David Chadwick wrote:
> 
> Mark Smith wrote
> 
> > 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)
> 
> Sorry, Mark, you are most definately wrong here. There is No
> change to the LDAP information model at all from the perspective of
> the client. Just that one attribute is returned that happens to have a
> large value i.e. a long string running over several lines (a bit like a
> huge  postal address really). This long string is a concatenation of
> several LDAP attributes and RDNs, which each already have a
> string based format.

I believe that what you describe is in fact a change to the information
model, although by looking at the situation in a generic way I can see
how you believe it is not.  Regardless, there are some compatibility
concerns.  An example might help.  Suppose I have the following entry:

  dn: uid=bjensen,ou=People,dc=airius,dc=com
  cn: Barbara Jensen
  cn: Babs Jensen
  sn: Jensen
  objectclass: top
  objectclass: person
  objectclass: organizationalPerson
  objectclass: inetOrgPerson
  ou: Product Development
  l: Cupertino
  uid: bjensen
  mail: bjensen@airius.com
  telephonenumber: +1 408 555 1862
       
Now suppose I download a new release of my favorite directory server
software and split the telephone number attribute off into a child entry
like this:

  dn: uid=bjensen,ou=People,dc=airius,dc=com
  cn: Barbara Jensen
  cn: Babs Jensen
  sn: Jensen
  objectclass: top
  objectclass: person
  objectclass: organizationalPerson
  objectclass: inetOrgPerson
  ou: Product Development
  l: Cupertino
  uid: bjensen
  mail: bjensen@airius.com

  dn: cn=Barbara Jensen's phone number,
uid=bjensen,ou=People,dc=airius,dc=com
  cn: Barbara Jensen's phone number
  objectclass: top
  objectclass: person
  objectclass: organizationalPerson
  objectclass: inetOrgPerson
  telephonenumber: +1 408 555 1862

If we go with the "return the family-information derived attribute"
approach, then a phone dialer LDAP client application that previously
could find the telephonenumber attribute won't see one at all as the
phone number itself will be buried inside a complex attribute with a
new, unknown FamilyEntries syntax.  If we go with the "return more than
one entry approach", the phone dialer client probably won't find the
entry containing the phone number because it will assume that a base
object search (which it will likely use to retrieve the needed
attribute) always returns only one entry when in fact it will return
two.


> ... The client does not need to know that it is
> several embedded attributes, all it has to do is display the large
> single attribute value that it is presented with. There is nothing to
> stop anybody today from defining a big attribute whose contents
> (value) could be a newspaper or even the bible. (I doubt if a family
> of entries will be that large.) We already have photo attributes
> anyway and these are big. We also have certificates and these are
> pretty complex structures and difficult for many clients to display. So
> there is no change to the LDAP information model. Just a new
> attribute has been defined.

What you say is true for a generic client that displays information to
end-users.  It is not true for any client that needs to act on the data
returned such as an administrative client or an MTA.  Such clients will
need to be revised to know about compound entries; otherwise, the wrong
action may be taken (e.g., e-mail may be bounced rather than delivered,
my phone may not be able to dial numbers it previously could, and so
on).


> ...
> >
> > 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).
> 
> Which is precisely what happens today when I search four11 for
> "smith." I get lots of them.

Sure, but suppose the person(s) who run a directory service have
implemented a policy that says "across this entire subtree, uid
attribute values are unique."  Then clients can reasonably expect to get
back at most one entry if they submit a subtree search with a filter
like "(uid=bjensen)."  Once compound entries are introduced, they may
get back several entries.  And not know what to do with them.  Again, I
am much less concerned about clients that present information to
end-users than I am about clients that process the data returned.


> ...
> >
> > 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.
> 
> I believe they are. They are broken because they do not allow the
> user to differentiate between different entries with different DNs that
> have the same final RDN. Eg. Mark Smith in Surveying and Mark
> Smith in Chemistry are both displayed as the same person by some
> clients, including Netscapes. This is a bug if you ask me.

Arguable.  I don't work on Netscape Communicator (sorry!), but it is
configurable to a great extent.  And even out of the box, you can
distinguish among multiple Mark Smiths by examining other attributes in
the entry.  Would you rather it presented DNs in the raw?


> ...
> >The burden is on us who
> > are extending the standard to be as compatible as possible with existing
> > clients.
> ...
> The burden is also on those who are implementing the existing
> standard to do it wisely (and correctly). For example, the scrolled
> results feature in Netscape 4.5 does not work with our local X.500
> server that supports LDAP but not the scrolling control, but it does
> work with an LDAP server that supports scrolling of results. This
> does not sound like a backwards compatible client implementation to
> me. There is an old saying that "People who live in glass houses
> should not throw stones."

I agree.  And I am not trying to throw stones as that is not a
productive activity.  I am just trying to raise awareness of some
compatibility issue with the compound entries proposal.  I wish we could
come up with a way to be nicer to clients that are not compound entry
aware, but I think you have already outlined the major alternatives. 
For what its worth, my understanding is that Communicator is supposed to
present a slightly different interface if the VLV control is not
supported by the server.  Are you saying you can't search your server at
all using the Netscape Communicator 4.5 address book feature (which is
definitely a bug)?  Or just that you do not get a scrollable list of
entries?


> ...
> Now I clearly dont want to break existing implementations, that would
> be unwise, this is why there are two ways proposed above for
> migrating forward. But please dont use the excuse that an existing
> partial client implementation that cannot even cope with existing DIT
> structures properly (viz the Mark Smith example above), let alone
> with some future proposed ones, should be a reason to stop new
> seriously required features from being standardised in a way that
> properly implemented clients are already able to cope with.

Please widen the scope of your thinking beyond just the Netscape
Communicator client.  Try this experiment -- implement the families of
entries feature in a server, convert some entries be of the compound
variety, and try pointing a variety of existing LDAP clients at it.  I
could be wrong, but I believe many clients that present results to
end-users will work, but in a confusing way, and that many clients that
process data returned over LDAP will take a wrong turn when processing
the compound entries.

A final note:  I am not arguing against standardization of the compound
entries proposal.  I am just trying to reinforce the fact that backwards
compatibility with existing LDAP clients is a thorny issue for this
extension and that we should think some more about the alternatives.  At
present, I do agree with you that the existing draft's proposed default
(i.e, to treat the compound entry as a set of individual entries) is
probably the least problematic choice.  My rationale is that the
family-information attribute will clearly not be useful to any client
that is not compound entry aware.

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