Re: Note on CMIS utilizing COPY and MOVE verbs

[Julian Reschke <julian.reschke@greenbytes.de>]

Al Brown wrote:
> Julian,
> 
> I saw a post on the JSR list and it prodded to me to (re)read the 
> appropriate rfcs. If you look at copy 
> (http://tools.ietf.org/html/rfc2518#section-8.8) or move 
> (http://tools.ietf.org/html/rfc2518#section-8.9), it is articulated to 
> copy (or move) a resource from location a (uri1) to location b (uri2). 

The relevant RFC nowadays is RFC 4918, but, yes, that is correct.

> These locations are fully specified to be where the object will live 
> after the verb. They include the location under the folder, rather than 
> uri2 being the uri to the folder. Am I understanding COPY and MOVE 
> correctly in WebDAV?
> 
> This is a discrepancy with the CMIS model.
> 
> In CMIS, we have:
> - moveObject (object, folder)
> - addObjectToFolder(object, folder)
> - removeObjectFromFolder(object, folder)
> 
> In WebDAV case COPY/MOVE would want uri2 to contain the location of the 
> object in the folder: e.g. http://foo/folder1/newlocation where in CMIS 
> it should be http://foo/folder1.

I keep forgetting that :-).

Is the assumption that the server will assign the collection-local name?

> In CMIS, there is not a notion of path, only folder containment. All 
> URI's in the rest binding are basically repository-specific how they are 
> generated. The most a client can do is specify the Slug ala app.
> 
> If we would like to use COPY and MOVE, wouldn't we have to redefine COPY 
> and MOVE for CMIS?

If there's no way for the client to "guess" the final URI (like "new 
folder name / old local name" -- which I doubt), then yes, MOVE and COPY 
wouldn't work as desired.

If we wanted to use COPY/MOVE, we'd need an extension (such as 
"Destination-Collection" instead of "Destination"). On the other hand, 
we could standardize the "Allow-Rename" header 
(<http://msdn.microsoft.com/en-us/library/aa142703(EXCHG.65).aspx>), 
which apparently is already supported in some Microsoft products.

BR, Julian