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 11:43:22 -0800
To: "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "'Manfred Baedke'" <manfred.baedke@greenbytes.de>, <w3c-dist-auth@w3.org>
Message-ID: <NSNOVPS00411AtTpXNr00000df9@NSNOVPS00411.nacio.xythos.com>

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.



-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Wednesday, March 15, 2006 10:30 AM
To: John Barone
Cc: 'Manfred Baedke'; w3c-dist-auth@w3.org
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?
> ...

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
Received on Wednesday, 15 March 2006 19:43:23 UTC

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