Re: [cmis] Re: Note on CMIS utilizing COPY and MOVE verbs

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

Al Brown wrote:
>  >Is the assumption that the server will assign the collection-local name?
> That is the APP behavior - After POST, Content-Location header is 
> returned with the location of the [new] resource [in that collection]. 
>  The server may specify the new location as a collection-local name.  Or 
> it may not.  The FileNet prototype does not use collection-local names, 
> but rather bases the URI off of the underlying object id.

Sure, that's the APP behavior, but APP is designed for posting items to 
news feeds, not for document management. So what I wanted to know what 
*CMIS* assumes.

>  >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.
> I would prefer Destination-Collection.  However, how do we advertise to 
> clients that COPY/MOVE does not support Destination but 
> Destination-Collection header?  Also, how do we map 

By defining a precondition code that can be sent back if 
Destination-Collection is absent, and by defining a new WebDAV feature 
to be returned in the "DAV" response header.

> removeObjectFromFolder?  

How is that a problem?

> We could either add a new header (e.g., removeFrom) or a new verb. 
>  However, I do not get a warm feeling from this approach so far.  I 
> think it would be cleaner to have new verbs or have those verbs 
> clarified in an rfc for this use case first.

Of course, whatever is needed here should be done in the IETF Apps Area.

BR, Julian