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

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.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Thursday, July 25, 2002 1:30 PM
To: Clemm, Geoff
Cc: w3c-dist-auth@w3c.org
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities


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

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com

"Clemm, Geoff" <gclemm@rational.com>





"Clemm, Geoff" <gclemm@rational.com>
Sent by: w3c-dist-auth-request@w3.org 
07/25/2002 08:58 AM

To: w3c-dist-auth@w3c.org
cc: 
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities




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:ldusseault@xythos.com]
Sent: Wednesday, July 24, 2002 1:15 PM
To: Clemm, Geoff; w3c-dist-auth@w3c.org
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities


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

> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@rational.com]
> Sent: Wednesday, July 24, 2002 5:35 AM
> To: w3c-dist-auth@w3c.org
> Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities
> 
> 
> 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:ldusseault@xythos.com]
> Sent: Tuesday, July 23, 2002 5:59 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities
> 
> 
> 
> 
> 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

Received on Thursday, 25 July 2002 13:53:51 UTC