- From: John Stracke <francis@netscape.com>
- Date: Fri, 31 Jul 1998 14:35:42 -0700
- 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 UTC