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: Jim Whitehead <ejw@ics.uci.edu>
Date: Wed, 18 Feb 1998 10:27:50 -0800
Message-ID: <01BD3C57.DE0A9A20.ejw@ics.uci.edu>
To: "'Ralph R. Swick'" <swick@w3.org>
Cc: "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
On Wednesday, February 18, 1998 4:08 AM, Ralph R. Swick [SMTP:swick@w3.org] 
> 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 13:52:05 UTC

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