-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> In the end I felt like I sat in a BOF trying to sell SMTP to an X.400
> crowd (and yes, I'm old enough to have been there).

Ahem, well, more like beeing in the room trying to sell LDAP to X.500.

Why I hear you say?

I wasn't around when LDAP split off from X.500 but I was around a
couple of years later (and ever since) in the IETF. The BOF felt
like deja-vue all over again for me.

In the dawn of time (smoke, also sprach zarathustra) the LDAP founding
fathers sat down and said "this X.500 directory stuff is far to complex.
Let us build a more simple directory".

They went about building LDAP. LDAP became a big hit and attracted
actual users and with them work in the IETF on all kinds of extensions,
profiling etc etc.

During the course of that work, and work on bringing LDAP to draft
standard, it has become increasingly clear to those of us who came
after the mythical progenitors of LDAP that some of the very choices
that were made when adding the 'L' to 'DAP' (X.500 includes DAP which
is the protocol for accessing an X.500 directory) were very very bad
choices.

Einstein once said - make things as simple as possible but no more
simple than that.

History has shown that it was possible to simplify X.400. Hence 821,
822,2821,2822 etc etc.

History has also shown that LDAP was probably too simple. That is not
to say that X.500 is the most simple directory model. I am saying
that the obvious choices 'simplifying' a design aren't necessarily
the right ones.

A couple of lessons from the LDAP/X.500 (imvho as always):

- - Simple doesn't necessary mean less code, text-based rather
  than 'binary' protocols, etc. The fact that you can debug your
  protocol by looking at tcpdump traces should not influence
  your design too much.
- - Non-structured as opposed to structured (ASN.1, XML, etc) data
  is a non-issue. One of the major simplifications of LDAP was
  the choice to only support text-based attribute values. That
  is one of the major problem with LDAP today.
- - Don't make design choices before fully understanding other
  solutions even remotely in the same space.

My 2 cents.

        Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEIbAD8Jx8FtbMZncRAvq1AKCX/XYX2b6UDXQrpU+n93v4xvZWrgCfUvMq
tYfaUPXUXpjzpzyhE8laSnc=
=3r5T
-----END PGP SIGNATURE-----

_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix

Reply via email to