Re: LDAP Comments

[Tim Howes <[e-mail]>]

> From:    Eric Rosenquist <Eric.Rosenquist>
> To:      [e-mail] (Tim Howes)

> > It was intentional to leave out both list and read.  These are trivially
> > implemented using search and leaving them out simplifies the protocol.
> 
> It may simplify it for the LDAP server, but I don't see that it makes
> a DUA much simpler.  If a DUA doesn't need to do List/Read operations,
> then what's the difference (aside from some extra code sitting in the
> LDAP server that never gets executed)?

If a DUA wants to do any or all of read, search, and list, it only has
to implement search.  If a DUA doesn't need to do list or read operations,
then there is no difference to the DUA, assuming it's using its own
custom LDAP access routines that implement only what it needs.  In
general, though, it's two less operations a DUA or LDAP server has
to implement.

> If a DUA wants to do a List, it has to contruct a "null filter" for a
> single level search (a test for the presence of the objectClass
> attribute is the only 100% safe filter I can think of) plus ask for
> one attribute to be returned (again, you'd have to ask for the
> objectClass even if you didn't want it).  While this is not rocket
> science in terms of complexity for a DUA, it is wasteful and would
> almost certainly be more expensive to execute on the target DSA.  The
> DSA would have to apply the filter expression to every subordinate,
> and while (to use Dish syntax) "objectClass=*" is a simple test that
> could even be optimized to avoid reading the entry, it's got to be
> more expensive than simply creating a list of subordinate RDNs.
> Similarly, you're forced to ask for at least one attribute even if you
> don't want any.  You could use some bogus object identifier I suppose
> to ensure that you don't get anything back, but that's going to force
> the DSA to read the attributes or check the objectClass schema of
> every subordinate.

Why is it wasteful?  The reason we left out read and list in the
first place was because we felt they were wasteful, since you could
do the same thing with search.

Arguing about what type of operation is going to be more efficient for
a DSA doesn't mean that much without mentioning specific
implementations.  If a DSA implementor wanted to make one-level
searches for objectclass=* efficient, it could certainly be done (via
the quipu method, the pizarro method + replication, etc).  Both search
and list are going to be inefficient in some circumstances, though.
It's not possible to say with a blanket statement that the one-level
search is less efficient than list.  It depends how it's implemented.
List can also cause lots of chaining, just like search (in fact, the
circumstances are very similar - list needs to fill in whether entries
are aliases and therefore needs access to the entry or some cached
information).  NSSR's and SR's affect list as well as they do search.

> > > o  pg. 9: I had to read the paragraph on search results a couple of
> > >    times before I understood what you were trying to say....
> > >    ...
> > 
> > I am reluctant to change the text, so I'm inclined to say that as
> > long as you were able to understand it eventually, it's ok as is! :-)
> 
> Why are you reluctant to change the text?  Isn't the whole purpose of
> internet drafts and RFCs to get discussions flowing and improve the
> document :-) ?

If I am reluctant, or appear somewhat short, I apologize.  But these
issues have, for the most part, been argued on this list and at OSI-DS
meetings in some detail a while ago.  At this point, I am happy to
fix errors in the documents but not to change the text without a really
really good reason, as that would kick LDAP back to ID status.

> > > o  Further on the Search Response topic... what is the reasoning behind
> > >    returning a sequence of search responses rather than a single
> > >    response containing multiple matching entries?
> > >    ...
> >
> > Several reasons.  1) It allows clients to have smaller memory requirements
> > (buffer space).  2) It allows clients to easily cancel part way through
> > retrieving a lot of search results.  3) It allows "streaming" to be done
> > (i.e. start sending search results before all of them have been collected).
> 
> 1) Not really, unless the client is willing to throw out the results
>    as they arrive and are displayed.  I would argue that it could in
>    many cases make the client more complicated, since it would have to
>    piece the results together.  This would be particularly so for a
>    client that issues multiple simultaneous operations or connects to
>    more than one server at a time.  It means that the search results
>    are not a single PDU and therefore require some extra state
>    information in the client.
> 
> 2) and 3) I can appreciate, but I wonder if either would be that much
>    different / better than an 'all or nothing' approach in practice.
>    The results from the LDAPD simply stream into the client at full
>    speed, so unless the LDAPD is delayed in the middle of sending the
>    results because it is chasing continuation references, you haven't
>    bought a heck of a lot for the client.

Your reason in 1 (deal with a result and then throw it out) is exactly
the situation in which it helps.  And that comes up quite often.  Several
things I've seen do/could/should take advantage of this.  Also, based
on experience with DIXIE and DAS, this was a feature several people
requested.

> > > o  Given that a string may be returned with each result and that
> > >    attribute types are passed around as names, it would be nice to
> > >    have a language specifier in the Bind request.
> 
> > This would add complexity to the protocol, for very little benefit.
> > The text error messages are not essential to the protocol and are
> > provided primarily as a "debugging" aid.  Adding multi-language
> > support there just doesn't seem worth it to me.
> 
> "Very little benefit"!?  Excuse me for being so bold, but you must be
> from a country with only one official language... ah yes, University
> of Michigan, USA.  I'm not suggesting that every LDAP server implement
> 15 or even 2 languages, I'm just requesting an extra parameter in the
> BindRequest and BindResponse so that a client can say "please use
> French" and the server can say "sorry, I can only use English".  Any
> existing LDAP server implementations would change only to hard-code
> their language value in the BindResponse.  That would allow those of
> us in Canada or Europe who care about such things to actually *do*
> something with the language field in our LDAP servers.

I do not mean to sound US-centric.  But the fact is that the error
messages are not part of the protocol.  Therefore, adding support to
the protocol to select what language they should be in does not make
sense to me.

Also, consider that there is no other protocol that does this.  SMTP,
for example, includes optional error messages after a numeric return
code.  But it doesn't allow you to select what language the messages
are in.  As with SMTP, the ability to add an error message is
primarily a debugging aid.

A DUA that depends on a particular message being there is depending
on a detail of a particular implementation.  Needless to say, this
is bad.  If a DUA wants to display it to a user in an attempt to be
helpful, that's fine.  But it should not be counting on the fact that
the user will be able to understand it, even if it is in their
native tongue. :-)                                     -- Tim