[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Defaults for Compound Entries
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. 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.
>
> 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.
>
> 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.
>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."
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.
>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.
I think that if you can solve the problem that exists today of different
people in the same organisation, but in different OUs, with the same
final RDN, from being displayed as the same entry with different
attributes, then you will have already solved the families problem as
well I think
David
***************************************************
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
***************************************************