Re: Comments from Christian H. on LDAP

[Tim Howes <[e-mail]>]

> From:    Christian Huitema <[e-mail]>
> To:      " (Russ Wright)" <[e-mail]>

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

This is very true.  Authentication is needed anyway, though.  Lots of
people want to restrict read access based on who you are, not just modify
access.  The other stuff is a pain, but indexes have to be maintained by
something (even if things are updated only in batch).  Recovery and
journalling remain.  I look at what we run here at U of M, and don't
think we can do without updates very easily!

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

I'd say that would be ok (modifying surname also changes common name).
If your X.500 db is mapped onto an sql database, presumably it would
do just that.  Does doing this violate X.500 somehow?

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

I said more about this in my previous message, but here's another thought.
Perhaps the payroll database should not use X.500, but X.500 should use
the payroll database as its back end....                       -- Tim