RE: COPY def'n (was: Comments on draft-ietf-webdav-protocol-06.txt)

I agree with Jim whitehead on his rationale for keeping "octet-for-octet"
language. I am not comfortable with server altering resource(s). Let
us keep this as it is and keep the spec as simple as we can. 

-- Surendra 

On 18 Feb 1998, Dylan Barrell wrote:

> Maybe you should define copy such that if you copy A to B and then back to A it is octet-for-octet the same as the original A.
> 
> Cheers
> Dylan
> 
> 
> -----Original Message-----
> From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
> Sent:	Wednesday, February 18, 1998 7:28 PM
> To:	'Ralph R. Swick'
> Cc:	w3c-dist-auth@w3.org
> Subject:	Re: COPY def'n (was: Comments on draft-ietf-webdav-protocol-06.txt)
> 
> On Wednesday, February 18, 1998 4:08 AM, Ralph R. Swick [SMTP:swick@w3.org] 
> wrote:
> > At 09:15 PM 2/17/98 -0800, Yaron Goland wrote:
> > > ... attempts to just define
> > >what "octet for octet" even means have utterly failed.
> >
> > I understand.  My suggestion was to remove those words to avoid the
> > implication that a server that did an "intelligent copy" (whatever
> > that may mean to it) is not DAV-compliant.  Move does have the
> > same problem as you point out.  I didn't notice any words in the
> > description of Move that would restrict an implementation's options
> > with respect to modifying the resource in arbitrary ways as a
> > side-effect of the Move.
> 
> Well, as the main proponent of the "octet-for-octet" language, I seem to be 
> taking it on the chin here.  Let me explain my rationale, and why I thought 
> (and still think) the octet-for-octet language is OK.
> 
> Once the octet for octet language has been removed, there is no way to 
> verify that a copy operation has performed correctly.  If you allow the 
> server to modify the state of a resource during a copy, then you run into 
> the following case:
> 
> 1. copy A to B
> 2. copy B to A
> A in (1) does not equal A in (2)
> 
> If I write a compliance test suite, and I'm trying to verify that a server 
> has implemented copy correctly, there are very few assertions which can be 
> made about the body of the destination after the copy.  For example, a 
> compliance test suite could check for a non-null body on the destination, 
> but it couldn't check for matching lengths, or matching contents.
> 
> I know (and truly do sympathize) with those who want to perform an 
> intelligent move or copy to perform link maintenance.  This isn't a case of 
> me not "getting it."  My concern is developing a spec. where the definition 
> of copy is more precise than people's intuition of copy.
> 
> That said, I do note that the growing consensus of the working group is in 
> favor of removing the "octet-for-octet" language from COPY.
> 
> - Jim
> 
>

Received on Wednesday, 18 February 1998 18:44:34 UTC