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

7.1

There are no guarantees for atomicity on depth 0 PROPFINDs because most
servers could not implement it. The problem is especially acute with live
properties where the very act of reading one property may cause the value of
another property to change, calling into question what "atomicity" really
means in that scenario. Atomicity in general is an issue that has been
repeatedly examined within the working group and the general determination
has been that it is simply too expensive a guarantee to require of the
overwhelming majority of servers.

Locking is a "poor man's" atomicity guarantee and as most systems have
locking built in, rather than having to simulate it at the HTTP level, it
also tends to have fairly decent performance while providing the strongest
atomicity guarantee that most systems are capable of providing. I freely
admit it isn't a perfect solution but the consensus has been that it is good
enough for now.

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

12.12.1

What you found is a bona fide bug. Turns out it happened twice in the spec.
What was missing was the href entry inside the response element. That
properly scopes the response.

2.4

An excellent point, it now reads "The value of a property is, at minimum,
well formed XML."


			Yaron

> -----Original Message-----
> From:	Ralph R. Swick [SMTP:swick@w3.org]
> Sent:	Thursday, February 12, 1998 12:05 AM
> To:	w3c-dist-auth@w3.org
> Subject:	Comments on draft-ietf-webdav-protocol-06.txt
> 
> 7.1: Are there any atomicity guarantees for PROPFIND?  Section 8.3 could
> be
> interpreted as applying only to depthwise operations.  For depth 0
> PROPFIND,
> a client should have a way to know that, for example, the values of all
> the live properties in a reply were valid taken as a whole at some
> instant.
> If such a guarantee is not provided, clients may resort to abusing the
> lock
> mechanism.
> 
> 7.10: The requirement that a COPY be octet-for-octet identical is overly
> restrictive.  This prevents, for example, an intelligent HTML copy that
> fixes relative links in the content such that they continue to work from
> the location of the copy.
> 
> 12.12.1:  Is it the intention of this protocol to not allow a server to
> support
> different lock types in different parts of its namespace?
> 
> Editorial:
> 
> In 2.4 the value of a property is described as being a well-formed XML
> *document*.
> However, it is the response to each method that is the well-formed
> document;
> the value of each returned property (e.g. in PROPFIND) is just well-formed
> XML.

Received on Friday, 13 February 1998 03:23:40 UTC