[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP ACLs
-----BEGIN PGP SIGNED MESSAGE-----
I am flattered that given the "questionable" quality of my arguments,
you've
chosen to maintain the high road of debate.
Nonetheless my understanding of protocols (having created a few) centers
on
the isolation of particular functionality at the protocol layer in use.
The
notion of providing intelligence of lower layer protocols throughout the
protocol stack is usually considered poor programming practice. This is
precisely the case for an individual ACL model with which to secure LDAP
communications, without respect to any underlying backing store.
I would question the failure of NT 5.0 based on possible ldap
irrelevance.
The majority of the desktop development community will continue to write
to
MS API's with little or no regard to IETF or any other standards. It is
left
to large enterprises continuing to operate heterogeneous platforms to
wrestle
the issues of interoperablilty in order to support our businesses.
Indeed, LDAA was a red herring - my apologies.
Ronald Becker Williams e-mail:ronald.b.williams@kp.org
Technology Planning vox:(626) 564-7680
Kaiser Foundation Health Plan, Inc. fax:(626) 564-7219
PGP Fingerprint: 5357 5718 A8D3 E1AA A465 962A A883 E25C
PGP Public Key: Email reply with "SEND PGP KEY" in the subject line
- -----Original Message-----
From: Paul Leach [SMTP:paulle@microsoft.com]
Sent: Saturday, May 02, 1998 5:14 PM
To: Williams,Ronald B; ietf-ldapext@netscape.com
Subject: 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 PG
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBNU36X6hbf2bwGt1HAQEl7gf+P6MWcYY4DGIA37tpTNqfxQ0mqnIO1wec
yIBEuqMN7sajfJnWV96JUvFwDpnafUS/VqzDY3EyvieSwDsqATRohJ74FqtItR8k
eSMdq0KnQ5IWR/ydlCJANmkCjMiJrSgJgfxQfJiKRnqf7DIGqGyaq5qoRP6Y3wM4
ehMlFBRsau/s7JzqHuvXrODCjzoqvowD5QmNgUoMCgbXMn7kIAkF56svHk72xP/+
jx1bHnJAMgbSy4hCGFf1inwRdtp06T1jhR5CYZQEn5EEY4Zv/9EV2Wjh3XZB3LIN
B2EXWNV1GITB0XTmGffLA7Wd7ab4rR7t4FF6E0aELYvDCeEXKW8Eug==
=VB0U
-----END PGP SIGNATURE-----