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

To quote Larry Masinter "There be Dragons Here".

We have been down this path previously and it leads to madness because the
types of possible primary and side effects are unlimited. Any attempt to
restrict them would end up being arbitrary. Even attempts to just define
what "octet for octet" even means have utterly failed.

For example, Dylan implies that "octet for octet" means that HTML links will
be broken. However if what is being copied is a calculated resource, such as
a CGI file, then the resource is certainly within its right to generate an
output to be copied that does not have any broken links.

We can not be more precise without turning HTTP into an RPC, which it most
certainly is not. Both the power and the curse of HTTP is that it does not
have and can not have precise definitions. Unfortunately few realize this
until they have embarked upon the ultimately futile quest to define the
undefinable.

The purpose of the DAV definition of COPY and MOVE is to say that, at
minimum, one can expect that the result of a COPY or MOVE will be some
stream of bytes at the destination. Unfortunately we can not be more
specific about what those stream of bytes would actually represent without
inappropriately restricting the freedom of the server.

		Yaron

P.S. Hum.. is that a new slogan? HTTP != RPC? =)

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> Sent:	Tuesday, February 17, 1998 9:59 AM
> To:	Yaron Goland; 'Ralph R. Swick'; w3c-dist-auth@w3.org
> Subject:	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 Wednesday, 18 February 1998 00:15:21 UTC