Re: comments from Christian H. on LDAP

[Wengyik Yeong <[e-mail]>]

------- Forwarded Message

Date:    Fri, 08 Jan 93 13:05:14 -0500
From:    MAILER-DAEMON (Mail Delivery Subsystem)
To:      <[e-mail]>
Subject: Returned mail: Cannot send message for 3 days

   ----- Transcript of session follows -----
421 cs.ucl.ac.uk.tcp... Deferred: Connection timed out during user open with su
n2.nsfnet-relay.ac.uk

   ----- Unsent message follows -----
Received: by spartacus.psi.com (5.65/2.1-PSI/PSINet Research and Development)
	id AA01315; Tue, 5 Jan 93 12:24:42 -0500
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Comments from Christian H. on LDAP 
Cc: [e-mail]
Reply-To: [e-mail]
In-Reply-To: Your message of Tue, 05 Jan 93 08:45:40 +0000.
             <[e-mail]> 
Date: Tue, 05 Jan 93 12:24:40 EST
From: Wengyik Yeong <[e-mail]>

[Apologies if this is a repeat: the message I sent last night doesn't seem
 to have made it to the list.]

> As LDAP is up for the last call on it's way to proposed standard, I have
> asked a couple of people to give this a thorough review. Earlier I forwarded
> Marshalls comments to the authors. 

Steve, Tim and I are talking about Marshall's comments.

> Here are some more extensive comments by
> Christian to whom I'm very gratefull that he has spend some time reading
> through this.

Yes, thanks for the comments Christian. You will forgive me if I disagree
with your substantive point :-) :-)

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

One of the overriding concerns with LDAP was to make implementations as
small as possible. Amongst other things, this translated to the minimum
of ASN.1 tagging and typing possible.

> 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 did consider CAT, but decided that we weren't sufficiently confident
that the necessary infrastructure would be in place for us to depend
on it.

I have the same concerns about the PEM certification hierarchy.

In any case, the authentication field in the BIND is a choice, so we
could add other authentication types later as necessary.

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

I'm sorry, I don't understand this comment.

> 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 what the provision for batching several messages would buy.
We made a deliberate decision not to introduce complexities like
messages in messages (or multiple commands in one message if you prefer)
to keep LDAP reasonably lightweight.

Since LDAP runs over a connection-oriented transport, I'm not sure what
batching messages would get us. Besides, it somewhat defeats the objective
of providing interactive access if LDAP were to batch things.

With regard to the question about whether LDAP allows the sending of a
query without first sending a BIND, the answer is "no". From the text
of the LDAP specification:

	"The Bind Operation must be the first operation request
	 received by a server from a client in a protocol session."

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

This is a good point, and I will talk to the other authors about fixing
it. Thanks for pointing it out.

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

LDAP is in fact restricted: it is specifically targeted at simple management
and 'browser' applications.

There is a philosophical point here which may not be evident from the LDAP
specification itself. In doing LDAP, we took a different approach to
providing access to the Directory than did the standards. Whereas the
standards provides one single access mechanism, the DAP, which is
supposed to be *the* access mechanism for all applications/uses of the
Directory, we decided instead to provide multiple, special-purpose
mechanisms for Directory access. In this way, we could provide applications
with a means of access to the Directory that had all the functionality
they needed, yet not require them to drag along the deadweight of functionality
they didn't need.

LDAP is supposed to be the first of these special-purpose mechanisms.

So, Christian, you are right in pointing out that LDAP is restricted. I
think of it as a feature, not a bug :-). LDAP has a very specific class
of applications in mind: the 'fred' and 'maX.500' type programs that
many are currently using for Directory access. It will hopefully provide
implementors with the ability to build small, simple management and
browser applications. That's all. Nothing more or less.

Obviously, the fact that LDAP is but the first of an envisioned series
means that it isn't supposed to be exclusionary. Certainly there should
be other directory access protocols in the series as other classes
of applications come to use the Directory, and there can certainly
be other approaches to Directory access (Christian's LDSP being one).


Wengyik

------- End of Forwarded Message