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

[Jari Urpalainen]

Julian, sorry for being stubborn ;-) 

On Fri, 2006-09-22 at 13:09 +0200, ext Julian Reschke wrote:
> 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).
> 
no wonder ;)

> In general, DELETE will
> 
> 1) unmap the URL and
> 2) optionall garbage collect the object if it doesn't have any 
> references anymore.
> 
agreed, this is the "rather well-known" rfc2616 model 

> 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.
> 
ok, I did some homework about the background:
<http://mailman.webdav.org/pipermail/acl/2003-September/001654.html>

I think the ambiguity you are referring to is about: when does acls
disappear (when there are e.g. several references to single object) ? If
they will be unlinked (or really destroyed) during phase 1) I'll agree
that there's probably a chance of some weird implications but it depends
on the implementation. However, if you do this unlinking on stage 2) I
still cannot see what exactly goes wrong. Or you are actually saying
that while you implement acls you don't know or don't have control to
basic DELETE behavior. Whatever, the issue may have pragmatic
implications but it certainly prohibits a useful use-case, imo. 

anyway, thanks for your enlightenment.
br,
Jari