Subject: rfc2518bis-14: COPY/MOVE semantics

From: Manfred Baedke <[email-masked]>
Date: Wed, 15 Mar 2006 15:45:47 +0100

Hi,

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.

Regards,
Manfred

---

From: "John Barone" <[email-masked]>
Date: Wed, 15 Mar 2006 09:56:35 -0800

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

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
specified.  

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?

Regards,

-John 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Manfred Baedke
Sent: Wednesday, March 15, 2006 6:46 AM
To: [email-masked]
Subject: rfc2518bis-14: COPY/MOVE semantics

Hi,

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.

Regards,
Manfred

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Mar 2006 19:30:10 +0100

John Barone wrote:
> ...
> ...

I'm not objecting to a change in semantics.

What I see is a discrepancy between both specs' requirements on dead 
property support (SHOULD), and support for copying dead properties (MUST).

If resource /a supports dead properties, and /b doesn't, then a COPY 
request from /a to /b "MUST" fail, which IMHO isn't a useful 
requirement. A resource should still be able to act as a destination for 
COPY, even if it doesn't support dead properties.

So the proposed change is to relax the requirement to SHOULD.

Does this make things clearer?

Best regards, Julian

---

From: Manfred Baedke <[email-masked]>
Date: Wed, 15 Mar 2006 19:43:19 +0100

John,

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.

Regards,

Manfred

John Barone wrote:

Regards,

-John

-----Original Message-----

Hi,

Regards,
Manfred

---

From: "John Barone" <[email-masked]>
Date: Wed, 15 Mar 2006 11:43:22 -0800

I can see that... although, this gets into the whole messy discussion about
what a "DAV-compliant resource" means, which Manfred brought up.  I would
think that if the source resource /a supports dead properties and
destination /b also supports dead properties, then a MOVE or COPY from /a to
/b MUST copy all the dead properties.  But then that language would become
very messy and confusing, trying to enumerate all the permutations of what
the proper behavior should be when the source and destination do/don't
support dead properties.  Changing the language to SHOULD retains the
intended behavior, while allowing your use-case to succeed.  I don't have a
problem with that change.

-John

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2006 10:30 AM
To: John Barone
Cc: 'Manfred Baedke'; [email-masked]
Subject: Re: rfc2518bis-14: COPY/MOVE semantics

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

If resource /a supports dead properties, and /b doesn't, then a COPY request
from /a to /b "MUST" fail, which IMHO isn't a useful requirement. A resource
should still be able to act as a destination for COPY, even if it doesn't
support dead properties.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Mar 2006 15:09:02 +0100

> am proposing to relax the requirement to SHOULD level.

OK, I opened an issue for this one on BugZilla 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=235>).

Best regards, Julian