Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 2 May 2002 17:38:58 -0400

Fine by me.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 4:41 PM
To: Clemm, Geoff
Cc: WebDAV
Subject: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION

The recent thread entitled
RE: need clarification about COPY to locked resource response cod       e
  and
RE: need clarification about COPY to locked resource response cod e
recently died down with the following posting.
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0043.html

I just want to bring it to conclusion and get it on the ISSUES list.

So we have a proposal on the table regarding error reporting for lock
conflicts
during COPY/MOVE.  I'll try to describe it below.

If a portion of the destination is locked and preventing a portion of the
COPY/MOVE,
then a 207 Multistatus MUST be returned by the server.   That MultiStatus
response should
indicate (with 409 Conflict status) what source resource could not be
copied/moved and
optionally say something about the locked destination resource the locked
that prevented
the copy.

<D:response>
    <D:href>/bla/source</D:href>
    <D:status>HTTP/1.1 409 CONFLICT</D:status>
    <D:responsedescription>
      <D:error>
         <D:locked-destination>
           <D:href>/other/destref...</D:href>
         </D:locked-source>
      </D:error>
    </D:responsedescription>
 </D:response>

That D:error tag is optional.  And clearly we'd need the add definitions
for the
D:error tag and the descendent tags listed in the example above.
We should work out if the dest URL listed is the root of the lock or the
locked resource
that was directly affecting the operation.  We should possibly clarify
"protected URL"
status codes and what URL is depicted.

If none of the COPY/MOVE could be done due to a locked destination, then it
is acceptable,
although obviously not optimal, to simply return a 409 CONFLICT rather than
a
207 MULTISTATUS.

As for *source* locks...

Source lock error don't occur for COPY, just MOVE.  And the 423 LOCKED
status
code will be used instead of 409 CONFLICT.  More specifically...

In the case of a MOVE operations where a portion of the source is locked,
the server
is to respond with 207 MULTISTATUS and the body of that will simply
indicate the
locked source resources with a 423 LOCKED status.

<D:response>
   <D:href>/bla/...</D:href>
   <D:status>HTTP/1.1 423 LOCKED</D:status>
</D:response>

In the case that the request (source) URL is locked in a way that prevents
any other
MOVEs to occur, the server is free to simply reply with a 423 LOCKED rather
than
a 407 MULTISTATUS.

In all cases, minimization rules apply.  I will start a seperate thread for
Minimization
issues if necessary.

So does this sound acceptable to everyone?

J.

---

From: "Jason Crawford" <[email-masked]>
Date: Sat, 4 May 2002 16:49:31 -0400

We could use a few more people speaking up...  :-)

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0080.html

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 6 May 2002 15:52:13 -0400

The reason not to reuse it is that this is not a "response"
element, but rather an "explanation" element (i.e. the same
reason you would not re-use a "point" element to represent
a "vector" element, even though they both contained 2 integers).
In particular, it is likely that you will want to extent a
"response" in ways that are inappropriate for an "explanation",
and vica versa.

Of course, as with most questions of re-use, it is a value
judgement as to "how close" two concepts are to each other,
and how likely it is for them to evolve in divergent ways.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Monday, May 06, 2002 3:30 PM
To: Clemm, Geoff; WebDAV
Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Monday, May 06, 2002 9:11 PM
> To: WebDAV
> Subject: RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION
> 
> 
> I don't think that it makes sense to try to re-use
> DAV:response in the "explanation" part of the error message,
> because you don't need another responsedescription,
> and it is not clear that the HTTP status codes are a
> useful way of characterizing what about the state of
> the other resource contributed to the error being described.

Well, we need 

- the URI and
- error information (be it an HTTP status or a DAV:error element).

DAV:response is a container that can hold both, so why not re-use it?

---

From: "Jason Crawford" <[email-masked]>
Date: Tue, 7 May 2002 09:23:23 -0400

<<
Well let's go in to a few examples and see if that sways any
opinions.

To review...

The basic concept of the proposal is that the body of the
COPY/MOVE multistatus response will list source resources
rather than destination resource.  But additionally, it
can list resouces that contributed to the status as an
explanation of the source resource(s) error status.  Often
that will be a destination resource.

Now for some examples...

A depth lock above the destination that prevents a COPY/MOVE
to the destination.  How would you list this?  (I'll let Geoff
and Julian make the proposals.)

A lock on the parent collection of the destination resource.

A lock on the destination resource.

A lock below the destination resource whose protected-lock-uri
guarantees prevents the destination DELETE phase of the MOVE/COPY
from occuring.

A COPY/MOVE to a destination that doesn't have an immediate parent.

A depth lock above the source URI that prevents a MOVE.

A lock of the parent of the source URI prevents a MOVE.

A lock on the source prevents a MOVE.

A lock below the source prevents a MOVE due to protected-lock-uri
guarantees.

Same as the above LOCK situations but ACL's instead.

Can the two approaches handle all of these well?

Reminder, the issue is just for MOVE/COPY lock issues, but
a check of these will let us know if the mechanism is flexible.

J.

---

From: "Jason Crawford" <[email-masked]>
Date: Thu, 9 May 2002 17:54:05 -0400

I'll record it as resolved that the multistatus results will list the
source URL not the destination.   That will move to "Edit" status.

I'll create an issue item for the proposals for how to document the nature
of the errors beyond the status code.  I'll mark that item as defered to
next version of WebDAV unless someone picks up the torch on this one.

J.