- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Fri, 26 Feb 1999 10:30:34 -0500
- To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>, yarong@microsoft.com
- Cc: w3c-dist-auth@w3.org
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