W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

[Bug 28] New: MOVE vs live properties

From: <bugzilla@soe.ucsc.edu>
Date: Sat, 27 Nov 2004 03:40:18 -0800
Message-Id: <200411271140.iARBeIUh015262@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org

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

           Summary: MOVE vs live properties
           Product: WebDAV-RFC 2518-bis
           Version: -06
          Platform: Other
               URL: http://lists.w3.org/Archives/Public/w3c-dist-
                    auth/2004JulSep/0153.html
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: 08.  HTTP Methods for Distributed Authoring
        AssignedTo: joe-bugzilla@cursive.net
        ReportedBy: julian.reschke@greenbytes.de
                CC: w3c-dist-auth@w3.org


8.10.1

"Live properties described in this document MUST be moved along with the
resource, such that the resource has identically behaving live properties at the
destination resource, but not necessarily with the same values.  If the live
properties will not work the same way at the destination, the server MUST fail
the request (the client can perform COPY then DELETE if it wants a MOVE to work
that badly). This can mean that the server removes a live property if that's the
most appropriate behavior for that live property at the destination."

The second sentence implies that the MOVE must fail if the live properties can't
be moved as well, while the last sentence says that the server may remove the
live properties.

Update -05: this now reads:

"This can mean that the server reports the live property as "Not Found" if
that's the most appropriate behavior for that live property at the destination,
as long as the live property is still supported with the same semantics."

I'm not sure I understand what that means. The contradiction is still there.

"A MOVE can be a rename operation, so it's not appropriate to reset live
properties which are set at resource creation. For example, the creationdate
property value SHOULD remain the same."

So can a MOVE be something else then a rename operation? If yes, how
does the second sentence then applies? If it doesn't apply always, and
the client won't know, why are we mentioning it?

Update -06: this has been reworded again, but I still think it's 
misleading. MOVE may or may not create a new resource (as RFC2518 
explicitly allows COPY/DELETE semantics). When it does, the creationdate 
will change. When it doesn't, it won't.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Received on Saturday, 27 November 2004 11:40:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:51 UTC