RE: Comments on draft-ietf-webdav-protocol-06.txt

I think Ralph made a good point. The spec should be more precise about what is within the scope of a copy. Allowing the spec to be read "creatively" should be discouraged. As the spec stands, it is an octet for octet copy of the resource in question (if that means HTML broken links, then that is what it means). It could be argued that this should be restricted to "source" resources - but this is probably too restrictive.

If you analyse the HTML Link issue a little more closely, then it is not only COPY, but also MOVE which has to be taken into account and in the case of MOVE, it is not only the moved resource which has to be modified, but all the resources which link to it.

If it was just COPY, then I would be happy to allow for the definition to state that the COPY should be an octet-for-octet binary copy of the source resource which MAY differ in content where it is necessary to maintain the integrity of embedded links.

When you take MOVE into account, then there are lots of options from having the above statement apply to MOVE and COPY, saying nothing about the result or the side-effects of either MOVE or COPY or having a blanket statement about acceptable side-effects for WebDAV methods.

Has anyone dealt with similar issues in other standards WGs?

Cheers
Dylan

-----Original Message-----
From:	Yaron Goland [SMTP:yarong@microsoft.com]
Sent:	Friday, February 13, 1998 9:23 AM
To:	'Ralph R. Swick'; w3c-dist-auth@w3.org
Subject:	RE: Comments on draft-ietf-webdav-protocol-06.txt
7.10

The requirement says that the copy must be octet-for-octet identical,
however it never says octet-for-octet identical to what. For example, if I
execute a COPY on the URL used to retrieve the output of a calculated
resource (a fancy way of saying I'm copying the URL of a CGI file not the
URL of the CGI file's source) what exactly is copied? The source? Possibly.
Perhaps the system can actually "move" the live resource and make it work at
the destination. More likely the result will be a "snap shot" of the output
or maybe not. The point is that the power of HTTP is its flexibility, a
"resource" can be anything. This is both a gift and a curse. A gift because
it allow HTTP to morph to do anything. A curse because it makes it
impossible to nail down some definitions. I suppose magic has its price. In
this case the price is that one needs to be a bit, creative, in reading the
standard. So, when you copy that file, who says you aren't just copying a
snap shot, a snap shot which was smart enough to update the links. TNSTFL

Received on Tuesday, 17 February 1998 13:16:35 UTC