W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

Re: Additional WebDAV Requirements?

From: John Stracke <francis@netscape.com>
Date: Fri, 31 Jul 1998 14:35:42 -0700
Message-ID: <35C238AD.DD12EFD2@netscape.com>
To: "Jeffrey E. Sussna" <jes@kuantech.com>
CC: w3c-dist-auth@w3.org
Jeffrey E. Sussna wrote:

> All I really meant was
> that ACL's could be represented to external clients as properties (perhaps
> "pseudo-property" is a better term).

No, no, "property" is fine.  But, if ACLs are visible as properties, and if
there is some way to manipulate the ACL of a property, then we fall into a
potentially infinite regression--unless we arbitrarily declare that you can't
put an ACL on the the ACL of an ACL, or some such.  I believe it would be
cleaner to expose ACLs via a separate protocol than to introduce this type of
ad hockery.

Oh, and there's a practical reason not to expose ACLs as
properties: interoperability.  Suppose I have a server that doesn't support
ACLs, and a client that's too lazy to check for ACL support before setting the
ACL properties? The server won't know that the client is expecting the
properties it's setting to mean something; the server will just store the
properties and forget about it.  This sort of behavior is fine for some things
(e.g., ordered collections); but ACLs are security issue.  If I have a buggy
client that doesn't check for ACL support, I want it to fail safe; I want the
server to report an error saying, hey, dummy, I don't do ACLs.  To do that, we
need ACLs to be implemented via their own HTTP methods.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      |The good are innocent and create justice.|
|francis@netscape.com      |The bad are guilty, and invent mercy.    |
\====================================================================/
New area code for work number: 650
Received on Friday, 31 July 1998 17:35:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:47 GMT