Re: Defaults for Compound Entries

[David Chadwick <D.W.Chadwick@ITI.salford.ac.uk>]

Date forwarded: 	Wed, 28 Jul 1999 09:03:11 -0700 (PDT)
Date sent:      	Wed, 28 Jul 1999 12:02:21 -0400
From:           	mcs@netscape.com (Mark C Smith)
Organization:   	Netscape Communications
To:             	d.w.chadwick@iti.salford.ac.uk
Copies to:      	Rob Weltman <rweltman@netscape.com>, ietf-ldapext@netscape.com
Subject:        	Re: Defaults for Compound Entries
Forwarded by:   	ietf-ldapext@netscape.com

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

This is a clear example that shows up the problem with existing 
clients.

>   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

Quick point of clarification. If this is the ancestor of a family then it 
would also have objectclass: parent

>   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

Quick point of clarification. The object class would not usually be as 
above, but would most probably be something like
objectclass: top
objectclass: child
objectclass: telephone

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

Yep, it would need to parse for the telephone number string (LDAP 
attibute type) within the compound attribute. But it already does this 
now at the higher level in order to extract it from the entry. So it 
would not be too painful to add, I dont think. But I agree, extra work 
is needed for an application client. This approach is best for 
HUMAN READABLE clients, because the human can do the parsing 
and extract the information without the client needing to be altered. 
Do you agree?

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

Now this will be very easy to implement and will not require any code 
changes to the client. It simply needs to alter its Search command 
as follows. Change base object search to full subtree search. Keep 
the target object name the same (ie the person's entry). Change the 
filter to objectclass=telephone. Then read the telephone number 
attribute from the single returned entry.

And if we put a new operational attribute in the rootDSE (lets call it 
families supported) then the client can tell which type of search 
command to use for each LDAP server it contacts. N.B. This is why 
the default approach in the existing ID is to return single entries.

> 
> 
> > ... 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).
> 
> 
I think I have shown a very easy way to do this in the example 
above, haven't I?

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

Not so. If you carefully read your own example above, you will see 
that only ONE entry has the uid=bjensen attribute, and that is Babs 
personal entry. The telephone entry will have its own different uid (if 
this is necessary)

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

I hope I have shown you a very simple method for automated 
application clients to work with families and still get the single entry 
with the attribute they want.

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

I think this should definately be an option for the user to click on a 
"show DN" or similar button, in order to get the full DN. I would love 
to have this feature now in the Security part of Netscape when I view 
certificates for example.

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

I hope I have outlined some more above. All new features require 
some changes in order to be used to best advantage. I agree that it 
would be nice if existing clients could continue completely 
unchanged when a new feature is introduced, and still get the same 
sort of service that they were previously used to. I think Rob had the 
idea to merge all the attributes from a family and return them as if 
they were all still in the one entry, and I dismissed this initially as it 
negates the benefit of families (you loose the relationship between 
attibutes.) But I concede that it might be useful to exhibit this default 
behaviour for old clients. In other words a family aware server, when 
talking to a family unaware client, collects all the attributes from all 
the children and sends them back as if it held them. But this will of 
course confuse the client if it tries to update the attributes. It will also 
cause a problem for single valued attributes as there might be many 
of them. It will also cause a problem for duplicate attributes (I guess 
the server should dispose of these in the result). I think this solution 
needs to be thought about it bit more before I complete buy into it. 
What do you think?



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

What I actually get when I contact our X,.500 server, as I slowly 
type in my name, for example, is

i) all the entries starting with C
ii) then all the entries starting with CH concatenated to the end of the 
original list
iii) then all the entries starting with CHA concatenated to the end of 
the previous list etc etc.

Now when I contact an LDAP server that supports scrolling, the list 
is cleared out everytime and a new list is displayed.

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

I dont dispute that you are correct if I use some (but not all) of 
todays clients.

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

I agree.

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

except for clients that are meant to be human viewable (as the 
human is intelligent enough to do the parsing).

We seem to be getting closer I think

David


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


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

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

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