Subject: RE: More on ordered collections

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 7 Apr 2003 18:19:06 -0400

One thing that I would suggest is to never try to define semantics for
both COPY and MOVE at the same time (they have radically different
semantics, in spite of what 2518 incorrectly implies, as acknowledged
by the authors of 2518 :-).  In particular, in the following
discussion, what Lisa says is true for COPY while what Julian says is
true for MOVE.  In particular:

   > > From: Julian Reschke [mailto:[email-masked]]
   > >
   > > If I MOVE or COPY a resource into a collection, overwriting
   > > a resource that has an ordering position, is that ordering
   > > position (of the destination) preserved?  Usually not, as
   > > RFC2518 defines an Overwrite to be implicitly DELETE the
   > > target.

I believe that we have consensus that 2518 is wrong here 
(this is explicitly pointed out in 3253) and that Overwrite is
only a DELETE for MOVE, not for COPY.

   > From: Lisa Dusseault
   >
   > No, I disagree with this.  Overwriting a regular resource does
   > not reset all the live properties.  For example, it would be
   > pretty disastrous for the ACL property to be reset every time a
   > resource is overwritten.

Here Lisa is talking about COPY behavior.

   From: Julian Reschke [mailto:[email-masked]]

   If you do that using a MOVE? I *really strongly* disagree. ACLs are
   properties of a resource, not of it's binding/URL. MOVEing a
   resource MUST move it's ACL with it, overwriting the target
   resource's ACLs.

And here Julian is responding with MOVE behavior.

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 8 Apr 2003 00:52:36 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Tuesday, April 08, 2003 12:19 AM
> To: 'Webdav WG'
> Subject: RE: More on ordered collections
>
>
>

That's why I wrote *usually* here.

> only a DELETE for MOVE, not for COPY.

That would be good. Do we? Anyway, this should be clarified in RFC2518bis.

> And here Julian is responding with MOVE behavior.

That *may* be the source for the confusion.

However I've got the impression that Lisa would like servers to better
support the following request chain ("safe delete"):

GET A
PUT A.bak
MOVE A.bak -> A

or similarily

GET A
MOVE A -> A.bak
PUT A
DELETE A.bak

Under this scenario, a resource would usually lose it's ordering position.
However, it would also lose it's version history and it's ACL, so I fail to
see why this would be a specific problem with the ordering spec.

However, if the client would issue these requests:

GET A
PUT A.bak
COPY A.bak A
DELETE A.bak

and the server conforms to the RFC3253 COPY semantics, there wouldn't be any
problem with ordering, ACLs or version history (the ordering spec just
"inherits" from the server's view of what COPY/Overwrite means).

So if at the end of the day we agree that COPY should always have RFC3253
sematics, I'm all for it :-) I just didn't want the ordering spec to require
a specific model.

Julian

P.S.: these "safe delete" scenarios obviously can become problematic if the
client doesn't properly handle dead properties.

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 7 Apr 2003 17:29:17 -0700

I agree there's little we can do about the safe-save algorithms that use
MOVE, sadly.  In fact, the correctest behavior for MOVE is probably, as
with version histories, to retain the source resource's ordering
position if a destination is overwritten.

However, if a destination is not being overwritten, then shouldn't the
MOVE (the rename) preserve ordering?

lisa

> -----Original Message-----
> [mailto:[email-masked]] On Behalf Of Julian Reschke
> Sent: Monday, April 07, 2003 3:53 PM
> To: Clemm, Geoff; 'Webdav WG'

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 8 Apr 2003 09:05:45 +0200

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Tuesday, April 08, 2003 2:29 AM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'

From a client's point of view: almost certainly.

The spec currently lets this depend on whether the server implements this as
a single rename or a bind/unbind (in which a new binding is created and the
previous is removed). Before I add some language about this, I'd like to get
some more additional opinions.

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 16 Apr 2003 22:26:41 +0200

Trying to summarize the issues raised by Lisa:

1) Concerns that ordering information will be lost when clients not aware of
ordering do "safe updates" (such as writing to a temp file, then moving it
to the original file): I agree that this is less than optimal, but the very
same issues exist with versioning (version history lost) or ACLs. Therefore
I'd say that the ordering spec should not try to fix something that is
inherently broken. The right way to fix this is to have clients that take
advantage of WebDAV properly (for instance doing in-place editing using
LOCKs).

2) More specific language about when ordering information is supposed to be
preserved. Right now, the ordering spec is mainly silent on this issue -- it
only defines specific behaviour for the case when new collection members are
added. In particular, Lisa mentioned DELETE which should not affect the
ordering of other members in the collection. I think this is obvious and
doesn't need to specified separately, but I'm willing to add a few sentences
if others feel this should be addressed (my point being: removing one member
from an ordered set doesn't affect the ordering of the remaining members).

3) The spec currently avoids to completely specify about *when* a new
collection member is added. Obviously this is the case for MKCOL and
PUT/COPY [when not updating an existing resource] (as stated in section
6.1), but what about MOVE? I can imagine servers that implement MOVE as a
sequence of LINK and UNLINK, in which case clearly a new binding is being
created and an old one is destroyed. On the other hand, it would be useful
for clients if they could rely on MOVE inside a collection (-> rename) not
to change the ordering. So do we want to mandate a specific server behaviour
(making it harder for server implementors), or leave it as it is (making it
harder for clients)?

Feedback appreciated.

Julian

[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html>