Re: Comments from Christian H. on LDAP

Christian Huitema <Christian.Huitema@sophia.inria.fr> Tue, 05 January 1993 17:01 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04442; 5 Jan 93 12:01 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04438; 5 Jan 93 12:01 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa08051; 5 Jan 93 12:02 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.02639-0@haig.cs.ucl.ac.uk>; Tue, 5 Jan 1993 16:39:25 +0000
Received: from mitsou.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP id <g.22859-0@bells.cs.ucl.ac.uk>; Tue, 5 Jan 1993 16:39:12 +0000
Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA11416; Tue, 5 Jan 1993 17:41:14 +0100
Message-Id: <199301051641.AA11416@mitsou.inria.fr>
To: " (Russ Wright)" <wright@lbl.gov>
Cc: RARE & IETF OSI-DS wg <osi-ds@cs.ucl.ac.uk>
Subject: Re: Comments from Christian H. on LDAP
In-Reply-To: Your message of "05 Jan 93 08:18:18." <9301051619.AA16261(a)lbl.gov>
Date: Tue, 05 Jan 1993 17:41:11 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Christian Huitema <Christian.Huitema@sophia.inria.fr>

Regarding the modify operations: the problem I have is with their
presence in the DAP in general, not merely in LDAP, for the following
reasons:

1- Allowing real time modification of the data does make the DSA
software much more complex. You need authentication, but you also need
journalling of updates, ability to recover, maintenance of index
files, etc.

2- Allowing real time modification of the data base obliges you to
keep a correspondance between what you send over the net and what you
store in the data base. Suppose for example that you want to be able
to display "Common Name", "Surname" and "Given Name", and that someone
updates the "Surname" attribute. Should the new surname also appear in
the Given name? On any traditional (e.g. SQL) data base, it would...

3- Allowing real time modification *by the end user*, as opposed to
modification by an administrator, gives the user the impression that
the X.500 data base contains the "primary" version of the data. What
happens if user Joe modifies its phone number Thursday but the X.500
base is restored from an "up to date" version of the payroll data base
Friday?

I know that the pure X.500 answer is that the payroll application
should just use the X.500 data base. But are *YOU* willing to bet your
payroll on that? For these reasons, I believe that having the "modify"
operations in the X.500 protocol brings more trouble than services.
And that these operations should not be part of a light weight white
page service.

Christian Huitema