-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Simple in the LDAP sense most certainly does mean less code, where it
> counts, in the client.
Measured how exactly?
>
>> - - 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
>>
> ;binary? In any case, I think the text based attribute values helped
> fuel adoption and to a certain extent narrowed focus and expectations.
Not ;binary - thats details. It did lower expectations but clearly
didn't narrow focus. LDAP is beeing used for much more than X.500 was
ever intended to be used for and I claim that many of these applications
are today feeling the lack of structured data in attribute values
(to pick one simplification of LDAP).
>
>> .
>> - - Don't make design choices before fully understanding other
>> solutions even remotely in the same space.
>>
>>
>>
> Agreed.
>
> Whether you believe LDAP was too simple or not, I think it can be agreed
> that whatever it did, for good or bad, it got deployed widely. In the
> absence of LDAP I don't think x.500 would ever have achieved the same
> ubiquity. DIX has similar goals, simplify where it counts, make it
> deployable in a larger scope than current offerings.
And I am trying to put it across to the dix community that there is
value in simplification but not in over-simplification. LDAP did not
represent the optimal simplification. Learning from LDAP (and similar
cases) might help dix achieve wide deployment *and* long life.
MVH leifj
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEIbw98Jx8FtbMZncRAhepAKC6C0VUHeVGjJsHAIsRqACXFgbEsACcC/gj
8/3dA3+LT8LHe22aHIfZngI=
=/49J
-----END PGP SIGNATURE-----
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
