W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1998

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

From: Surendra Reddy <skreddy@us.oracle.com>
Date: Wed, 18 Feb 1998 15:40:13 -0800 (PST)
To: Dylan Barrell <dbarrell@opentext.ch>
cc: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, "'Ralph R. Swick'" <swick@w3.org>, "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
Message-ID: <Pine.SOL.3.96.980218153536.3484B-100000@volcano.us.oracle.com>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:13 UTC