W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

RE: rfc2518bis-14: COPY/MOVE semantics

From: John Barone <jbarone@xythos.com>
Date: Wed, 15 Mar 2006 09:56:35 -0800
To: "'Manfred Baedke'" <manfred.baedke@greenbytes.de>, <w3c-dist-auth@w3.org>
Message-ID: <NSNOVPS00411QIrGC5V00000de6@NSNOVPS00411.nacio.xythos.com>

I don't know that this changes the semantics of COPY/MOVE.  From the 2518

8.8.1 COPY for HTTP/1.1 resources

... After a successful COPY invocation, all properties on the
   source resource MUST be duplicated on the destination resource,
   subject to modifying headers and XML elements, following the
   definition for copying properties...

8.8.2. COPY for Properties

   ... Live properties SHOULD be duplicated as identically behaving live
   properties at the destination resource.  If a property cannot be
   copied live, then its value MUST be duplicated, octet-for-octet, in
   an identically named, dead property on the destination resource
   subject to the effects of the propertybehavior XML element.

   The propertybehavior XML element can specify that properties are
   copied on best effort, that all live properties must be successfully
   copied or the method must fail, or that a specified list of live
   properties must be successfully copied or the method must fail. The
   propertybehavior XML element is defined in section 12.12.

While the language is imprecise and a bit confusing, I read this as saying
that properties MUST be copied over, with an exception for live properties,
which SHOULD be copied if possible.  There's some further discussion of
transforming live props that can't be copied in to dead properties, and well
as some caveats depending on how the propertybehavior XML element is

In the 2518 spec. the properties language in 8.8.1 probably should have been
in 8.8.2, and instead of "all properties" it probably should have refered to
"dead properties", but I don't think the new language fundamentally changes
the semantics of COPY/MOVE.   

To my reading, the change is actually that the language about the
propertybehavior XML element has been removed, and the MUST language for
turning a LIVE property that can't be copied into a dead property has been
changed to a SHOULD NOT ("Servers SHOULD NOT convert live properties into
dead properties on the destination resource..."), which seems like a prudent
change to me.

8.9.1 MOVE for Properties

   The behavior of properties on a MOVE, including the effects of the
   propertybehavior XML element, MUST be the same as specified in
   section 8.8.2.

This is also a bit unclear, and probably should have pointed to 8.8.1 as
well, but basically I see this as saying that a MOVE should behave in much
the same way as COPY; dead properties MUST be moved, LIVE properties SHOULD
be moved (which, I'd actually argue, that for a MOVE it should be a MUST).

So, what is the change in semantics that you don't agree with, and what
changes in language are you proposing to correct it?




-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
Behalf Of Manfred Baedke
Sent: Wednesday, March 15, 2006 6:46 AM
To: w3c-dist-auth@w3.org
Subject: rfc2518bis-14: COPY/MOVE semantics


from Section 9.8.2 of rfc2518-bis-14:
> After a successful COPY invocation, all dead properties on the source 
> resource MUST be duplicated on the destination resource, along with 
> all properties as appropriate
and from Section 9.9.1 of rfc2518-bis-14:
> Dead properties MUST be moved along with the resource
Apart from my opinion that 'along with all properties as appropriate' 
has neither normative nor explanatory character and should be omitted, this
changes the COPY/MOVE semantics of RFC2518 in a way that is rather
inconsistent with the fact that not even a resource which supports PROPPATCH
is required to set dead properties. Furthermore, such a change would force
existing implementations that support DAV namespace operations but not DAV
property operations to break the specification.

Received on Wednesday, 15 March 2006 17:56:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:35 UTC