Subject: RFC3744 question: COPY privileges

From: Evert | Rooftop <[email-masked]>
Date: Sun, 4 Oct 2009 02:15:15 +0200

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.

Evert

---

From: Werner Donné <[email-masked]>
Date: Sun, 4 Oct 2009 14:19:31 +0200

Hi Evert,

If you are deleting an existing target collection prior to the actual  
COPY, the latter will create a new collection resource with a new  
binding in the collection the existing target collection was in. This  
would require the "bind" privilege for that parent collection, just as  
when you move the source collection into it. So you don't need a  
special interpretation of any privileges. There are anyway no "copy  
privileges".

Best regards,

Werner.

--
http://www.pincette.biz/
Handling your documents with care, wherever you are.

On 04 Oct 2009, at 02:15, Evert | Rooftop <[email-masked]>  
wrote:

> 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).
>
> 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).
>

---

From: Evert | Rooftop <[email-masked]>
Date: Sun, 4 Oct 2009 14:41:57 +0200

On 2009-10-04, at 2:19 PM, Werner Donné wrote:

> Hi Evert,
>
> If you are deleting an existing target collection prior to the  
> actual COPY, the latter will create a new collection resource with a  
> new binding in the collection the existing target collection was in.  
> This would require the "bind" privilege for that parent collection,  
> just as when you move the source collection into it. So you don't  
> need a special interpretation of any privileges. There are anyway no  
> "copy privileges".

Thanks Werner, this is what I'll be doing.

I was also not referring to any copy privileges, just that the  
specification says write-properties and write-content is required for  
copying over existing resources.
But this makes more sense regardless.

Thanks again,
Evert