Re: Fielding on MOVE & COPY

> There is a substantial disadvantage in not supplying MOVE
> in addition to COPY and DELETE. It forces servers to perform
> a copy operation when a much cheaper directory operation may 
> be possible.

That is possible, but only when the resource can be moved as a
filesystem object in a single disk within a single server.  If we were
to limit MOVE to be only within a single server, that would be reasonable.

> I see no reason why sending a MOVE operation to the source
> location of a URI should not cause that server to do a POST
> of the information to the new location and delete it locally.

The reason why it can't do that is because we currently have no way for
the client to "lend" its authentication credentials to the server such
that the server could perform that action on behalf of the client.
Again, this is only an issue in cross-server MOVE methods.
[And it would be a PUT, not a POST.]

> MOVE http://etna/foo http/1.2
> Destination-URI: http://krakatoa/bar
> 
> This has the substantial advantage that the machine that holds
> the data can wait until receiving the 2xx OK response before
> performing the local delete, also the command would not be
> permitted unless the user had delete as well as copy permission.

Yes, it does have an advantage in terms of atomicity.  However, it might
be better to just introduce a form of transaction support, since we
already need that anyway.

> I don't think that the entity compartment should be utilized for 
> specifying the source or destination. It seems to me that this
> would be better used to put a comment on the reason for the
> operation.

That too would be a reasonable solution, assuming that it is desirable
to have the comments be typed via the content-type/encoding mechanism
(I think so).  Naturally, you could also include comments in the form of a
Comments field.

If people do choose to use a new header field for the list of source
or destination URIs, then it is important to use a robust syntax.
In other words, the URIs should be <bracketed> or "quoted" so that
they are easily distinguished from adjoining commas or folding.

......Roy

Received on Friday, 6 September 1996 21:20:40 UTC