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 13:52:05 UTC