Re: Comments from Christian H. on LDAP

Steve Hardcastle-Kille <S.Kille@isode.com> Sat, 09 January 1993 18:45 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03669; 9 Jan 93 13:45 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03665; 9 Jan 93 13:45 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10326; 9 Jan 93 13:46 EST
Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP id <g.02181-2@haig.cs.ucl.ac.uk>; Sat, 9 Jan 1993 17:58:23 +0000
Received: from localhost.isode.com by glengoyne.isode.com with SMTP (PP) id <02844-0@glengoyne.isode.com>; Sat, 9 Jan 1993 16:22:47 +0000
To: Erik Huizer <Erik.Huizer@surfnet.nl>
cc: RARE & IETF OSI-DS wg <osi-ds@cs.ucl.ac.uk>, Christian Huitema <Christian.Huitema@sophia.inria.fr>
Subject: Re: Comments from Christian H. on LDAP
Phone: +44-71-223-4062
In-reply-to: Your message of Tue, 05 Jan 93 08:45:40 +0000. <9301050844.AA05227@survival.surfnet.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 09 Jan 1993 16:22:45 +0000
Message-ID: <2842.726596565@isode.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Hardcastle-Kille <S.Kille@isode.com>

Let me go through some of these points.    I believe that they are all
either trivial or can be ignored.   We should fix up the one detail, and
then get the spec out there.  Now is not the time for navel
contemplation about the philosophical direction of directory.   We
should get the lightweight spec out there and use it!

 >
 >Date:    Mon, 04 Jan 93 14:41:25 -0500
 >From:    Christian Huitema <Christian.Huitema@sophia.inria.fr>
 >To:      Erik Huizer <Erik.Huizer@surfnet.nl>
 >Subject: Re: Request
 >

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

This is a hangover from using some of the SNMP simplifications to BER.
We wanted to use ASN.1 as a specification tool, as it is an excellent
choice, and also clearly indicates the relation to X.500.   On the
other hand, we wanted simple PDUas.   I agree that this difference is
not worth it, and we should use the standard ASN.1 definition.


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

This should be progressed, but independently.  If we try to sort this
out, it will hold the whole thing up.   Many uses of LDAP do not need
any authentication.   We should set up a group to deal with the next
stage of authenticaion.   There are a lot of issues here: (how to
interact with X.500 authentication, whether to use CAT, etc....).
Will get this on the OSI-DS charter.   

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

I argued this initially, as it would simplify the protocol, and allow
the authentication to be omitted.  It is clear that remote updates are
very very useful (e.g., users changing information in their own
entries).  I think that this is definitely needed, and does not add
much complexity/

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

Already there.

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

It is only unique over the connection.  Set it to 1 for the first
operation, and then increment.   Not a big problem to code.

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

This line of thinking is flawed.   Removal of referrals is a major
simplification, and a big win for most DUAs.   It is particularly
important in a multi-protocol world - you really do not want DUAs to
have to deal with all of this mess.   

Then you try to talk about replacing the whole thing.   Big mistake.
You will increase the complexity of everything back to the level of
X.500, AND introduce a second system to compete with X.500.    The
LDAP model is that you retain your X.500 infrastructure without
change.   LDAP provides a lightweight mechanism to access this
infrastructure.    If you try to introduce alternate or replacement
DSPs, things get much more complicated.   (I do think that DSP over
Simple OSI Stack has some benefits, as it gives performance win and
can easily coexist with standard DSP.).    In summary LDAP is
targetted to enhance and aid the deployment of X.500, not to replace it.

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

Now you are going totally wild.   Lets redesign the whole world!
This may be a good thing, but it is totally irelevant to LDAP.


 >
 >Christian Huitema
 >


Steve