[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP ACLs
-----BEGIN PGP SIGNED MESSAGE-----
- -----Original Message-----
From: Williams,Ronald B <Ronald.B.Williams@kp.ORG>
To: 'Paul Leach' <paulle@MICROSOFT.com>; ietf-ldapext@netscape.com
<ietf-ldapext@netscape.com>
Date: Friday, May 01, 1998 5:49 PM
Subject: RE: LDAP ACLs
>In light of the resounding defeat of the multiple-ACL-model-support
>resolution at the Los Angeles meeting, I find it difficult to
understand
>why one person's individual misunderstanding obviates the clear
>consensus developed on that day.
Perhaps because the person who misunderstood is the chief architect
for one of the major implementations of an LDAP compliant DS on the
marker today.
I believe the minutes will show that
>the question was put clearly to the room, aside from any particular
>arguments that may have been offered.
I do not doubt that, all other things being equal, everyone would
prefer a single ACL model. So would I. So did the people who created
the "single ACL models" for IMAP and ACAP. So, there isn't going to be
a "single ACL model", no matter how the WG votes. My proposal merely
tries to recognize that fact.
>
>IMHO, Multiple ACL models will make LDAP irrelevant to real business.
Did multiple file formats for word processing documents make PC based
word processing irrelevant to real business? Did the creation of HTML
render prior file formats irrelevant? How about ASCII and Unicode?
IMO, the recognition of the reality of multiple ACL formats will make
deployment of LDAP based DS easier, not harder.
>I'm inclined to wonder (albeit cynically) if that is not precisely
the
>point.
So, don't attack my arguments, attack my motivation. What does that
say about the quality of your arguments?
Not to mention the obvious fact that if LDAP were to become irrelevant
to real business, then the next major release of my company's OS would
be a failure, since its major feature is an LDAP based DS.
>
>One may (as you have) provide eloquent and substantial arguments in
>favor of multiple ACL models for a given system. If support for
native
>authorization mechanisms is required, more often than not the use of
>native access methods will be used, not a union of all possible
>protocols. Unless someone wants to write a draft for LDAA
(Lightweight
>Directory Access Architecture) which contains pluggable
authorization,
>selectable transport, dynamic schema management, etc. etc.,
The demand for selectable transport and dynamic schema management is a
red herring. They aren't required to allow ACLs to be read, written,
and modified via LDAP (e.g.) as a well defined attribute of directory
entries, where the format of the ACL is identified by an OID.
And we are more than willing to write such a draft, as long as it has
not been defined "a priori" as out of scope.
- ----------------------------------
Paul J. Leach <paulle@microsoft.com>
PGP Key ID: 0x978829DD
Fingerprint: 9EFA A405 39B4 F91F DE6F 8939 6FE9 F5D8
Key Servers: http://pgpkeys.mit.edu:11371 ldap://certserver.pgp.com
-----BEGIN PGP SIGNATURE-----
Version: PGP 5.5.5
iQCVAwUBNUu24MqlCdSXiCndAQEzfQQAppZeQn7DJXjZLrYmzV+V963K1gd+grvc
/SUI0ThjhNl0UilivA9DWvIPezVWny5C7cmhCpPMuwWIV0OohilU6hsNNicYUtS2
RUmJ4zJHjk3EfFQmB4yoSYNJGXoIYCqrlwZ1U6JvL2AVEJQDjDnxukFfEf5ZTFnT
5eNP16iUVGE=
=79oF
-----END PGP SIGNATURE-----