[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP ACLs



-----BEGIN PGP SIGNED MESSAGE-----

This is a great summary.

One interesting aspect of (B) is that either (A) or (C) can be one of
the choices of ACL system, thus permitting us to both initially get
the needed experience and support a migration to the ultimate scheme
over time. Neither of the other schemes is so tolerant of diversity.

Details:
I see the problem of interoperation for "total replication" between
servers that don't support a common ACL format, but not for less
perfect forms of replication, and not for referrals. Could you
elaborate?

I also see the potential for cross-protocol compatibility problems
with (B), but I was hoping that one outcome of this discussion is that
we could get agreement among the "LDAP, WebDAV, and IMAP/ACAP crowds"
to all follow the (B) if LDAP followed (B) -- that was the path WebDAV
was on.

I agree that (C) will get to market faster the (A), but I think (B)
would get to market at about the same speed, with (C) as one of the
choices.

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

- -----Original Message-----
From: Chris Newman <Chris.Newman@innosoft.com>
To: Paul Leach <paulle@MICROSOFT.com>
Cc: ietf-ldapext@netscape.com <ietf-ldapext@netscape.com>
Date: Wednesday, April 29, 1998 4:34 PM
Subject: Re: LDAP ACLs


>I agree with most of what you said, Paul.
>
>We're faced with a choice among evils:
>
>(A) Get the LDAP, WebDAV, and IMAP/ACAP crowds together to come up
with
>    joint requirements and design an IETF ACL system.
>Pros: Will probably have best final outcome
>Cons: Will take a long time (possibly 2 or 3 years)
>      We probably don't have enough field experience to do this right
>      OS vendors with different models will have to add support for
the
>        IETF model
>
>(B) Several mandatory-to-implement-on-client ACL systems.  Possibly
add
>    (A) later.
>Pros: flexible
>      server implementations more secure
>Cons: lots of client complexity
>      interoperability problems with less frequently used models
>      LDAP servers with different ACL models can't interoperate for
>        replication, referrals, etc.
>      Introduces cross-protocol compatibility problems
>
>(C) Design a single experimental LDAP model with the intention that
it be
>    replaced with (A) down the road.
>Pros: Gets something to market faster
>Cons: OS vendors with different models will have to add support for
the
>        this model and the future model
>      This model will probably have to be supported for a long time
after
>        (A) is deployed.
>      Introduces cross-protocol compatibility problems
>
>I'm afraid (C) is the lessor of evils here.  But none of these are
>appealing.
>
> - Chris
>
>
-----BEGIN PGP SIGNATURE-----
Version: PGP 5.5.5

iQCVAwUBNUfAKcqlCdSXiCndAQFBAQP/S63E7cxDfcfbekQ6yN2gimybkqyZOD3F
NziQwBMwr/9YKrUuLv7Ei1SDsI5Pr5RnP5ETRFMN4z7050Z91cd4xoPNMDGR9Hxg
ICS7Nyv6zMwve52Ly5drorr+Xdzk6xD+CR00bTljAy3jf6k9PpU628h6cDydwqRb
HKRFHZ+n9AY=
=Oe8Z
-----END PGP SIGNATURE-----