comments on ACLs

A first pass of comments on the ACL spec:

* are ACLs resources?  Can they be resources in some implementations?  I can see where versioning them separately might be useful, especially in the case where I'm dynamically inheriting an ACL--I might want to select an ACL version separately from the resource that is the source of the ACL inheritance.  I think they probably should be.

* should we define some notion of a rights bundle?  It would be nice to see a nice directory listing where I could see a simple summary of what stuff I have rights to, and I think users will want summarize rights frequently.  E.g. I define a rights bundle that gives writeowner & writeacl rights as a group.  This could help simplify things.
 
* is this a typo in the definition of the "writeowner" right (section 6.7) -- 
  <aclspec>The writeowner right controls the ability to change the value of the owner right</aclspec>

  There is no "owner" right, just an "owner" property

* why isn't PROPFIND used to list the ACL property (and subproperties) for a resource?  This seems totally inconsistent, since you call ACLs a property.  In general, I think I will want to get ACL information as well as other properties about a resource, and I will want to get them in a single request.

I have no problem with the ACL method being used to update ACL properties rather than PROPPATCH, however, although I can see a case for using PROPPATCH in this instance.

* the following text makes no sense to me (Introduction--section 1):

"Properties on a resource, by default, dynamically inherit from the
   ACL on the resource. In other words, the resource is the ACL source
   for the properties"

What you mean to say is that by default, the ACL controls (the big C in ACL) access to all of the properties of a resource, but that an ACL can be used to control access to individual properties in the resource as well.

While on this topic, I think per-property ACLs are:

* incredibly expensive to maintain
* create an overwhelming amount of data for users to process

What is generally desired when restricting access below the object (or resource level) is the ability to subdivide the properties of a resource into separate sets, with an ACL for each set.  If the XML used for sub-resource ACLs looked something like:

<acl>
  <d:displayname>Classified</d:displayname>
  <ace>...</ace>
  <ace>...</ace>
  <applies-to prop="foo"/>
  <applies-to prop="bar"/>
  ...
</acl>
 <acl>
  <d:displayname>Top Secret</displayname>
  <ace>...</ace>
  <ace>...</ace>
  <applies-to prop="default"/>
  ...
</acl>
 
I think users & implementers would understand what is going on better, and be steered toward simpler implementations.

* Why do we need rights like "writeowner" when you can define a separate ACL for the owner property if you want, and use the regular "write" permission

--Eric