after reading these sections again, I have to admit that RFC2518 apparently intended to say that dead properties MUST be preserved by COPY/MOVE unless specified otherwise by the propertybehavior element. Therefore, I will have to change my mind from objecting against a semantical change to proposing a semantical change :)
My point is that the MUST requirement simply does not match the SHOULD requirement of PROPPATCH. It would be plainly impossible to COPY a resource with dead properties to a server that does not support dead properties (for example, a simple file system based implementation). I am proposing to relax the requirement to SHOULD level.


John Barone wrote:
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: [] On
Behalf Of Manfred Baedke
Sent: Wednesday, March 15, 2006 6:46 AM
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.