Delete, Move, and Copy for References (Yaron's Issue #9)

I think that Yaron, Geoff, and I are all in agreement about everything
except the default behavior of COPY.  Let me summarize what the advanced
collections design team has done:

For all methods, we try to choose the default behavior to be what is
intuitively right for down-level clients, since they have access *only* to
the default behavior.  Other considerations can override this one, but we
always give heavy weight to the rule of least surprise for down-level
clients.

Reference-aware clients can always override the default behavior.  If the
default behavior is to pass the method through to the target (automatically
for direct references, via a 302 for redirect references), a reference-aware
client can use the No-Passthrough header to apply it to the reference
instead.  If the default behavior is to apply the method to the reference,
the reference-aware client can look up the value of the DAV:reftarget
property on the reference, and send the request to that target instead.

For DELETE and MOVE, the default behavior is to apply the method to the
reference rather than to its target.  This is true both for direct
references and for redirect references.  Reference-aware clients can force
these methods to apply to the target by looking up the value of
DAV:reftarget and sending the request to the target.  I think we all agree
that this is right, though maybe not all for the same reasons.

Now, what about COPY?  The spec says that the default behavior for direct
references is to apply the method to the target.  I think we all agree that
this is right.  What a down-level client expects is to end up with an
independent resource that can be modified without affecting the original --
COPY would have to be applied to the target to get this result.

For COPY on redirect references, I think Yaron likes what the spec currently
says: that the COPY request applies by default to the redirect reference, so
that there will be no 302.  This is a point where I think the spec is wrong
(and I think Geoff agrees with me).

What behavior is surprising for any method is the same for direct and
redirect references.  In the case of COPY, it is surprising if you think you
have created an independent resource, and it turns out that when you modify
that resource you have also modified the original that it was copied from.
This is true whether you used a direct reference or a redirect reference to
access it.  Getting a 302 response to a COPY request is not in itself
surprising -- it just looks to the down-level client as if the resource it
is trying to copy has been temporarily moved, and it still makes sense to
ask the user whether he wants to copy that resource.  The answer will almost
certainly be "Yes".

I don't quite get Geoff's comment that "The client needs to be warned that
there really will *not* be a copy made," since I thought the position we
were both supporting is that there *will* really be a copy made, both for
direct references and for redirect references.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Friday, 26 February 1999 10:26:23 UTC