Re: Fielding on MOVE & COPY

One reason for having a separate MOVE operation is that if the document has
attributes, you want a COPY operation to result in new values for certain
attributes (like create date, creator) whereas a MOVE operation should leave
the values alone.

--Judy

 At 07:09 AM 9/4/96 PDT, Jim Whitehead wrote:
>Yaron Goland asked Roy Fielding last week what the history was on the MOVE
>and COPY methods which were in the initial HTTP 1.1 draft, and which were
>subsequently removed.  Roy cc'ed his response to me, and I feel it is of
>interest to the group.
>
>- Jim
>
>Roy Fielding:
>
>That part of the early HTTP/1.1 spec (draft 00) was never completed,
>so it probably isn't worth looking at.  The only thing I did was
>define the methods COPY and MOVE as being methods, but did not supply
>the other information that would be needed to make them work.
>In fact, I think we are better-off without any MOVE and instead just
>have a COPY and DELETE combination (the reason being that the copy
>destination needs to "run" the copy method, but only the copy source is
>capable of running the delete method -- since the source and destination
>can be different servers).
>
>Basically, what I started to do was to use those method names and have
>the source of the action be the request-URI.  However, I now believe that
>the request-URI needs to be the destination-URI, since it is the destination
>server which will be performing the COPY operation.  The question is: how do
>you specify the source-URI(s) for the copy?
>I originally thought that using a Location or Content-Location header
>field on the request would do it, but that makes those fields more
>difficult to specify.  Instead, what I suggest is that you use the
>body of the request as a list of source URIs for the copy, e.g.,
>
>    COPY /new/resource HTTP/1.1
>    Host: www.ics.uci.edu
>    Content-Type: text/uri-list
>    Content-Length: 38
>
>    http://www.microsoft.com/old/resource
>
>which would have the added benefit of allowing multiple copies
>
>    COPY /new/dir/ HTTP/1.1
>    Host: www.ics.uci.edu
>    Content-Type: text/uri-list
>    Content-Length: 640
>
>    http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0001.html
>    http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0002.html
>    http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0003.html
>    http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0004.html
>    http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0005.html
>    http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0006.html
>    http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0007.html
>    http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0008.html
>    http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0009.html
>    http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0010.html
>
>in a single request.  That one could also be done using relative URIs.
>
>
>
>
>
Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	8*222-5169
Fax:		(716) 265-7133
MailStop:	128-29E

Received on Friday, 6 September 1996 09:36:31 UTC