Subject: [Bug 211] Inconsistencies about Destination header

From: [email-masked]
Date: Wed, 8 Feb 2006 10:14:58 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=211

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         [email-masked]          [email-masked]

------- Additional Comments From [email-masked]  2006-02-08 10:14 -------
Discussed this during the Feb. 8, 2006 teleconference.

We discussed the handling of errors in situations where a client requests a
cross-server COPY/MOVE. This situation is as follows:

client --> server A --> server B

The client makes a cross-server COPY/MOVE request to server A. This request asks
server A to COPY/MOVE one or more resources to server B. There are two broad
error cases here.

1) The original origin server (server A) just plain does not implement
cross-server COPY/MOVE. It has no mechanism for executing this functionality. In
this case, we agreed that the original origin server (server A) MUST fail the
request, and SHOULD return a 501 (Not Implemented), with a <DAV:error> code that
indicates this error situation.

2) The original origin server (server A) does implement cross-server COPY/MOVE
functionality (perhaps with WebDAV, perhaps using some other protocol), and
attempts the requested COPY/MOVE. The follow-on server (server B) is unable to
fulfill this request, and hence server A now needs to tell the client that their
request was not fulfilled. Ideally, server A should report that there was a
cross-server operation error (perhaps using a new status code (5xx series most
likely), and then also indicate the problem faced by the follow-on server. That
is, server A would essentially be packaging the error reported by server B, and
sending it along to the client. If server A and server B are communicating using
WebDAV, then this is fairly easy -- we just use a variant of the PROPFIND
response XML packaging for reporting errors. If server A and server B comunicate
using some other protocol, the best we can do is create a generic envelope,
label the kind of error response, and leave it to the client to figure out
what's going on. Alternately, we could define some broad categories that server
A would use to map the errors into.

In any event, it should be clear there are a number of issues involved in
propertly reporting cross-server operation errors. These are part of a larger
collection of issues surrounding cross-server operation behavior in general. It
would be best to have a separate effort that addressed these issues
substantively, and we should leave the error reporting in this situation
undefined, so that this future effort has a blank slate for designing
appropriate error reporting.

Therefore, in this situation 2518bis should state that the error reporting for
case #2 is intentionally undefined.

Assigning to Lisa to add text into the specification.

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
You are on the CC list for the bug, or are watching someone who is.