RE: ACLs

<es>
  Jim, I think you misunderstood this statement.  The question we are
answering is, how many ACEs are allowed in a particular ACL.  We didn't
address the lower bound (which is clearly 0), but rather the upper bound.
Clearly each server will have some maximum number of ACEs that it can
handle.  For interoperability, we need to have a mimimum value for this
maximum that all servers must implement.  The current proposal is that we
have two limits (one for users & one for groups) and that the minimum
number
of supportable ACEs is 1.  For example, if you tried to store an ACL with 3
ACEs, you could not count on a particular server supporting that, and could
get a "Too many ACEs" error.
</es>
<jra
You're right, I did misunderstand the statement. I'm OK with this now.
</jra>

<es>
The benefit to treating the ACL as a property of the resource, is that it
allows a WebDAV client to implement things like "ls -l", where you could
see
all of the resources in a collection: names, access rights, owner, etc.  A
single PROPFIND call could do all of that.  Issuing a separate ACL request
for each item in the collection would be a lot slower.
</es>
<jra>
I see you're point. I could be convinced ACLs as live properties is OK.
Don't like using PROPPATCH to update them though. It would be nice if the
protocol provided an ACL method that supported the semantics instead of
PROPPATCH with a lot of possible errors returned.
</jra>

<es>
Don't you mean
<!ELEMENT ace (principal, allow|deny, right*)>
</es>
<jra>
No, I meant:
<!ELEMENT ace (principal, allow?, deny?)>
<!ELEMENT allow (right*)>
<!ELEMENT deny (right*)>
</jra>

?checkPermissions? method:  ?do I have rights to do the following operation
if I tried it?

HTTP is a "try it and see what happens" or challenge response paradigm.
This has worked well so far for access control. If the operation works, a
client wouldn't want to waste the time checking ahead of time. If it fails
due to access control, the client will know from the returned status code
and can do whatever it would have done after a "checkPermissions" method. I
don't see the need.
<es>
The method that you try might be destructive (eg. a DELETE method).  You
might want to find out if you can delete it without doing so, and without
implementing the ACL resolution mechanism in the client.  That's the
request
we're considering.
</es>
<jra>
What difference does it make if the method is destructive or not? Say you
want to do a DELETE. If you have permission, asking first will return true
and you'll do the delete. Not asking first will just do the delete - same
result in both cases. If you don't have permission, asking first will
return false and the client won't do the delete. Not asking first the
delete will fail - same result in both cases. So it seems to me the
checkPermissions() method wouldn't add anything. Am I missing something?
</jra>

Received on Monday, 3 April 2000 13:43:09 UTC