RE: three clarification questions on the If header.

I believe the spec is clear on the effects of the Depth 0 lock but I do
admit that the term "Depth 0" gives the connotation that somehow the
children aren't covered under the lock token. However Depth 0 in this
context is only meant to reference the scope of the original LOCK method.
That is, the original LOCK was only on the collection and thus was Depth 0.
However the effect of a depth 0 write lock extends to the children in that
PUT and DELETE is restricted on them as an effect of the lock. Thus
submitted the write lock token for C in an untagged production on C/R is
completely correct because the locktoken DOES describe C/R's state (or
potential to have state, depending on how you actually define what it means
to have an undefined resource, after all, if the resource isn't defined how
could it return an error? But that is a philosophical discussion I will
leave for Roy Fielding and his ilk).

I will definitely record this issue in my list of things that could be
clearer in WebDAV.

			Yaron

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Saturday, September 12, 1998 11:54 AM
> To: Yaron Goland; w3c-dist-auth@w3.org
> Subject: RE: three clarification questions on the If header.
> 
> 
> At 07:26 PM 9/11/98 PDT, Yaron Goland wrote:
> 
> >This example is too vague to properly respond to. You need 
> to specify what
> >method you are executing, what sort of lock you have on C, 
> what its depth
> >is, etc. and why you need to refer to C's lock in order to 
> execute your
> >method on R.
> 
> You're right, the question was too vague.  Here is another try.
> 
> A client has an exclusive write lock on collection C at depth 0.  The
> client wishes to create a new resource C/R by doing a PUT.  
> The state token
> for C is needed because C/R did not exist previously (7.10.2)
> 
> Suppose the client uses the non-tagged production in the If 
> header.  It
> includes the state token for the lock on C. 
> 
> 8.4 says "If the state of the resource to which the header is 
> applied does
> not match any of the specified state lists than the request 
> MUST fail".
> 
> Clearly the PUT method is applied to C/R, yet there is no 
> possible state
> token that the client can include that will match C/R.  It 
> does not even
> exist yet, it has no state at all.
> 
> Perhaps the protocol should be amended with the material 
> below in brackets.
> 
> "If the state of the resource to which the header is applied 
> does not match
> any of the specified state lists [and the resource is not 
> null] than the
> request MUST fail".
> 
> and with something to the effect of
> 
> A client SHOULD use tagged productions rather than the no-tag-list
> production when the set of affected resources is known in 
> advance and is
> small.
> 
> As for my second question, I am sure the language of 8.4.1 is 
> crystal clear
> to you.  But you wrote it.  My claim is that it is not 
> crystal clear to me,
> and hence not likely to be crystal clear to others.
> 
> To summarize, the two points of unclarity are:
> 
> 1. the restrictive qualifier "due to the presence of a Depth 
> or Destination
> header".
> 
> 2. what it means to "apply".  adding a cite to RFC 2068 would 
> be sufficient
> if there's a clear statement there.  or we could use the 
> definition from
> your reply, which (editted) reads:
> 
> >To apply a method [to a resource] ... means that the method
> >directly affects the state of [the]  resource.
> 
> But the protocol language as is is sufficiently unclear that even
> reasonably competent readers can have doubts about its meaning.  
> 
> 
>

Received on Tuesday, 15 September 1998 03:23:42 UTC