W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2009

RFC3744 question: COPY privileges

From: Evert | Rooftop <evert@rooftopsolutions.nl>
Date: Sun, 4 Oct 2009 02:15:15 +0200
Message-Id: <DE4F1AE2-0458-4C2E-82F1-B813EB14BF5E@rooftopsolutions.nl>
To: WebDAV <w3c-dist-auth@w3.org>
Dear list,

I'm implementing RFC3744. However, the required privileges for COPY  
don't make a lot of sense to me. (Referencing Appendix B).
If I'm doing a COPY and the target already exists, the write-content  
and write-properties privileges are required for the target resource.

This is contrasting with MOVE, where the requirements for the target  
collection is unbind/bind.

RFC4918 (section 9.8.4) states the following:

When a collection is overwritten, the membership of the destination  
collection after the successful COPY request MUST be the same  
membership as the source collection immediately before the COPY.  
Thus,   merging the membership of the source and destination  
collections together in the destination is not a compliant behavior.

In general, if clients require the state of the destination URL to be  
wiped out prior to a COPY (e.g., to force live properties to be  
reset), then the client could send a DELETE to the destination before  
the COPY request to ensure this reset.

(end copy-paste).

If I'm copying a non-collection resource to overwrite another non- 
collection resource, this behaviour makes total sense to me. However,  
when I'm dealing with collections on either the source or the target,  
I'm deleting the target resource before doing the copy (which I feel  
is quite sensible).

So from the perspective of RFC3744, I feel the spec makes the  
assumption COPY is just dealing with non-collections. Do I have the  
liberty to treat COPY privileges similar to MOVE?
Either way this will probably be the route I will be taking, but  
clarification is appreciated.

Received on Sunday, 4 October 2009 00:15:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:44 UTC