- 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>
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: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