Re: Comments from Christian H. on LDAP

[Tim Howes <[e-mail]>]

> From:    Christian Huitema <[e-mail]>
> To:      Erik Huizer <[e-mail]>

> 1- Why define IA5String ::= OCTET STRING
> when it is already defined in ASN.1 as [UNIVERSAL 19] OCTET 
> STRING?

Don't know.  Weng or Steve, can you think of a reason?

> 2- There should be a provision to use the common authentication 
> technology. In particular, one should be able to include a 
> challenge/response mechanism and the use of PEM certificates.

We talked about this.  Originally, there was only simple auth.  Then
when we (U of M) went ahead and implemented the kerberos stuff, we
(the ldap authors) decided to at least document it in the protocol.
Basically, we felt that the cat stuff would open a whole other can
of worms, and that we coule do without the extra complexity.  So,
it was deferred for "version 2" of the protocol.

> 3- Do we really need to carry the X.500 update operations over 
> the network? We could probably do without!

This was one of our hardest fought battles.  I argued strongly that
without modify the protocol would be essentially useless to me.  The
issue you raise about X.500 not being the primary data source is
certainly one people should consider before letting their users modify
the data in X.500.  However, I don't feel that it's any reason to
remove modify from the protocol.  There are places (U of M, for example)
that are dealing with this problem and have a need to allow people to
modify their own entries.  Also, keep in mind that, here at least, X.500
stores more than what is held in our administrative databases.  So even
if we prevent users from modify the admin fields, we want them to be
able to modify the other ones (email address, fax phone number,
description, etc).

> 4- There should be a provision for "batching" several messages. I dont
> understand whether LDAP allows to send a query without sending a
> "BIND" first; stateless operation should be allowed!

I'm not sure I know what you mean by "batching".  Certainly it's
possible for a client to prepare a bunch of requests, then send them
"all at once" (i.e., one right after another without pause).  The same
is true for a server on a response.  There is no interaction that needs
to happen between requests that prevents this.  How would the protocol
be changed to support "batching", and what advantage would it give over
the scenario I just described?

Yes, an LDAP client must BIND first.  Are you suggesting that making the
TCP connection should be an implicit unauthenticated BIND?  I believe
that was an idea that was kicking around early in the development, but
got dropped.  It sounds like a sensible thing to me, though (being the
one who was kicking this idea around :-)).

> 5- The request that all ids be strictly superior to all previous IDs 
> is impractical. One should either use a modulo, or a restriction of 
> the form "not reused...".

We can change the wording here to be better.

> And now, the MAJOR problem. I dont understand the real purpose of this
> proposal -- more precisely, I believe its purpose is far too limited.
> It seems uniquely designed as a way to use TCP instead of T/S/P/ROS
> between the DUA and the "home DSA". What of distributed operation? If
> you really want to run a white page service on the Internet, nobody,
> not even the servers, should be bothered with running the OSI upper
> layers. You should define the representation of knowledge, and in
> particular the "Continuation References" retourned in REFERALs and
> Result Lists, in terms of domain names and IP addresses; this protocol
> should replace DSP as well as DAP!
> 
> Think more. The hierarchical distribution of searches in X.500 is
> bogus. Suppose we would want to provide a "yellow page" service. Why
> not start from LDAP and try to integrate the "forward reference"
> concepts of WHOIS++? LDAP could then be the first step towards a white
> + yellow pages service in the Internet.

Our original idea was for three protocols.  The first was to be a
read-only nameservice protocol.  Next was what turned into LDAP.  The
third was to be full DAP (or even DAP+) directly over TCP.

I like the idea of a DSP++, especially one that supports the WHOIS++
concepts, because I think there are some really interesting ideas there.
But I think that most if not all of this development is orthogonal to
what we've done with LDAP.  The addition of referrals to LDAP is the
possible exception, but even that's not necessary.  We could do a DSP++
transparent to LDAP, by having the LDAP server chase referrals just as
it does now.

I have no doubt that the use of a full OSI stack for X.500 servers and
clients is nothing but a big stinking log in the road of X.500 deployment
on the Internet.  The question is, what exactly to do about it.  I see
LDAP as solving half the problem.  DSP++ would solve the other half, but
would it lose us anything?

No doubt Steve and Weng have some comments to make also...     -- Tim