[ACL] Re: [Ietf-caldav] DAV acls

[Julian Reschke]

Jari Urpalainen schrieb:
 >...
> The problem is that there is no strong definition for DELETE in the 
>> first place. Some servers just remove the binding (thus affect the state 
>> of the parent collection) and then garbage collect resources with no 
>> URIs left, other move them into a trashcan, other destroy them immediately.
>>
>> That's why the definition of the DAV:delete privilege was ambiguous and 
>> was removed.
>>
> hmm. Are we speaking about the spec or actual, maybe somewhat weird
> implementations ? Sorry, I'm still confused why e.g. the actual type of
> implemented removal will influence delete privilege ? So if you allow
> (ambiguous ?) delete you would allow only binding removal, move to
> trashcan or complete removal (the latter of which is my preference,
> btw.).

The WebDAV ACL spec tries to define privileges based on the nature of a 
method invocation (it's semantics), not the syntax alone. For instance, 
you don't have a privilege for REPORT, as what a REPORT actually does 
depends on the request body.

This way, new methods can be introduced without the need to define new 
privileges (in general). For instance, MKCOL is similar to PUT, in that 
it adds a new member to it's parent collection.

The trouble with DELETE was that when we discussed it, there was 
absolutely no agreement about it's semantics are (funny enough, a 
similar issue ist just being discussed over at the atom-protocol mailing 
list).

In general, DELETE will

1) unmap the URL and
2) optionall garbage collect the object if it doesn't have any 
references anymore.

For simple servers that have a single URL per object, this may be a 
single well-defined operation. In general it isn't.

The only semantics we all agreed on is that removing a member from a 
WebDAV collection affects the state of that collection, thus the 
DAV:unbind privilege has been defined to cover exactly that.

>>>> Secondly, while distributed acl rules (on different servers) or
>>>> referencing distributed group principals may be cool they are quite
>>>> challenging to implement, that's why I was hoping to see a postcondition
>>>> like "DAV:no-distributed-acls" (and something similar to distributed
>>>> groups). Also this should be listed on <acl-restrictions>.  What I mean,
>>>> there are other things that are optional to implement which are imo much
>>>> easier to implement than these. So probably the "generic"
>>>> "no-ace-conflict" could be used here, but it isn't that descriptive for
>>>> the client (the implementation of which in general, must be quite
>>>> flexible imo btw.).
>> When you say "distributed", what exactly are you referring to? The 
>> inheritance mechanism defined in 
>> <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.5.5.4>?
>>
>>> ...
> 
> Most likely I've understood (and even implemented) inheritance in this
> context (which is imo an "advanced" feature of the spec). What I'm
> trying to refer to: if you list e.g. a "remote" principal group uri
> (remote.com) within a "local" principal group uri (example.com), i.e.
> the acl evaluator should retrieve this remote group content and also
> keep sync with this uri content in order to do proper evaluations (and
> similarly, when inherited acls exist on another server). So this is imo
> hard to implement (DoS, trust=credentials, retrieve, sync, loops etc.),
> so I was thinking about simple server implementations which only support
> locally accessed rules or groups (and sure you can have multiple virtual
> hosts). So having uri references makes things really flexible but also
> easily broken. So maybe <recognized-principal> etc. will do the trick,
> but I'd prefer to see a clearer alternative (i may have misunderstood
> this totally, however...)

Hm. The ACL spec gives the responsibility where to place principals 
(principal URIs) to the server. I personally haven't seen an 
implementation that puts principals "somewhere else" yet. Why do you do 
that in the first place, if it hurts...?

Best regards, Julian