Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 23 Jul 2002 17:59:29 -0400

If a MOVE operation MAY fail when live properties can't be continued as
live properties at the destination, what should we say about when the
server can allow the MOVE and when it can't? Is it entirely up to the
server or should we make a recommendation?

Then, if the server does fail, what error code should be returned?

Lisa

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 24 Jul 2002 08:35:20 -0400

I don't quite understand the first part of the question.
If we say that the live properties must continue live at
the destination, what more do we need to say?  (I.e. what
situation is left ambiguous?).

For the second part, a 403 (Forbidden) seems right to me.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 5:59 PM
To: [email-masked]
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities

Lisa

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 24 Jul 2002 13:14:33 -0400

It depends on the precise wording of the language. One alternative is to
be loose, allowing servers compliant with 2518 to still be compliant
with 2518bis (with either MAY or SHOULD, I'm not sure yet):

"A MOVE operation MAY fail (403 Forbidden) if the live properties of the
source cannot be live properties of the destination.  The server MAY
remove live properties that are no longer appropriate at the
destination."

A stricter alternative:

"All live properties on the source resource MUST become live properties
on the destination resource with appropriate values and the same
semantics. If the server cannot guarantee this, it MUST fail the request
with 403 Forbidden."

The problem with the stricter alternative is that it forbids a server
from removing a live property.  E.g. in collection "drafts", the
property "draftstatus" (in some custom namespace) can be set by clients
and the server allows certain actions on the resource based on the value
of this property.  Therefore "draftstatus" is a live property. When the
resource is moved to the "publish" collection, "draftstatus" is no
longer appropriate as a live property at all.  May the server remove it?

Lisa

> From: Clemm, Geoff [mailto:[email-masked]]
> Sent: Wednesday, July 24, 2002 5:35 AM

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 25 Jul 2002 08:58:26 -0400

I'd prefer the stricter alternative, but I could live with
the former if it said "SHOULD" instead of "MAY".

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Wednesday, July 24, 2002 1:15 PM
To: Clemm, Geoff; [email-masked]
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities

A stricter alternative:

Lisa

---

From: "Jason Crawford" <[email-masked]>
Date: Thu, 25 Jul 2002 13:30:26 -0400

I also prefer the stricter version... although only for MOVE.  (The second
wording doesn't mention "MOVE" explicitly.)

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

                      "Clemm, Geoff"                                                                                       
                      <gclemm@rational.        To:       [email-masked]                                             
                      com>                     cc:                                                                         
                      Sent by: w3c-            Subject:  RE: New RFC2518bis draft, COPY / MOVE of live properities         
                      dist-auth-                                                                                           
                      [email-masked]                                                                                       

                      07/25/2002 08:58                                                                                     
                      AM                                                                                                   

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Wednesday, July 24, 2002 1:15 PM
To: Clemm, Geoff; [email-masked]
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities

A stricter alternative:

Lisa

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 25 Jul 2002 14:14:28 -0400

I believe this definition will work in enough cases for the
implementor to be able to extrapolate what to do in those
multiple-representation cases (and I'll bet is very close to how
Xythos actually does implement its cross-repository MOVE).

In particular, I believe we have to say something to clarify the
distinction between MOVE and COPY, and that this would be a reasonable
compromise between "fully defines every case" (not achievable) and
"undefined" (pretty much what we have in 2518).  But I'm always open
to replacing it with something better!

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 2:02 PM
To: Clemm, Geoff; [email-masked]
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Thursday, July 25, 2002 7:53 PM
> Yes, good point Jason, these constraints should only
> apply to MOVE, and definitely not to COPY.
>
> For COPY, I would like us to use the rfc-3253 semantics,
> i.e. that a COPY is semantically equivalent to a GET/PROPFIND
> followed by a PUT/PROPPATCH, where the PROPFIND/PROPPATCH
> is for all properties that can be PROPPATCH'ed at the destination.

This won't work (in all cases).

The resource may have multiple representations (depending on request
headers), but a simple sequence of GET/PROPFIND-PUT/PROPPATCH will only copy
one of the representations.

---

From: "Jason Crawford" <[email-masked]>
Date: Wed, 31 Jul 2002 18:11:45 -0400

I support Geoff's proposal.   COPY seems like a difficult species to
define, and what Geoff proposes below seem like the best definition that we
are likely to come up with.

                                                                                                                           
                      "Clemm, Geoff"                                                                                       

                      07/25/2002 02:14                                                                                     
                      PM                                                                                                   

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 2:02 PM
To: Clemm, Geoff; [email-masked]
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities

The resource may have multiple representations (depending on request
headers), but a simple sequence of GET/PROPFIND-PUT/PROPPATCH will only
copy
one of the representations.