Subject: RE: three clarification questions on the If header.

From: Yaron Goland <[email-masked]>
Date: Fri, 11 Sep 1998 19:26:55 -0700

> -----Original Message-----
> From: Jim Davis [mailto:[email-masked]]
> Sent: Friday, September 11, 1998 3:00 PM
> To: [email-masked]
> Subject: three clarification questions on the If header.
> 
> 
> For the following questions, assume a collection C contains 
> resource R, and
> suppose C is locked at Depth 0.  Assume that resource S does 
> not exist.
> 
> 1. Is it true that the lock on C has no effect on doing a PUT 
> to R?  (The
> protocol in 7.10.2 is clear that it affects ability to add or remove
> members, but says nothing about changing existing ones.)
> 

Yes, it is true.

> 2. In 8.4.1, which says "If a method, due to the presence of 
> a Depth or
> Destination header, is applied to multiple resources then the 
> No-tag-list
> production MUST be applied to each resource the method is 
> applied to", what
> is the significance of "due to the presence of a Depth or 
> Destination header"?
> 
> Can a method be applied to multiple resources in any other 
> way?  It seems
> to me that it can.  Consider a PUT to S (which does not yet exist).
> Certainly the PUT applies to S.  Does it also "apply" to C?  
> It seems to me
> that it does, or else why would the client have to pass the 
> state token for
> the lock on C?
> 
> Will someone please clarify 8.4.1?
> 

To apply a method is a very specific term in HTTP and means that the method
directly effects the state of one or more resources. The lock token
submitted on a request for S does NOT effect the state of C. Rather it
allows S's state to be effected as a consequence of confirming knowledge of
C's state. On the other hand, issuing a DELETE on C most certainly effect's
S's state since the method can not succeed unless S gets nuked. Thus I
believe the section is absolutely crystalline clear.

> 3.  In the case where the client has a lock on C, but no lock 
> on R, and
> does not have the etag for R, is it possible for a client to use an
> _untagged_ production in the If header to pass the lock token 
> on the C?
> 
> If so, I don't see how to implement it.  The production 
> matches the state
> of C, but it will not match the state of R, so it will fail, 
> and hence the
> PUT will fail.
> 
> If this is right, it seems to me that the protocol document 
> should say that
> a client SHOULD use tagged productions when the set of 
> affected resources
> is known in advance and is small (as in this case) and it 
> should explain
> the potential problem with using the no tagged production.  Otherwise,
> clients will fail and programmers will be puzzled.
> 
> If this is wrong, then a clarification in 8.4 is in order.
> 

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.

---

From: Jim Davis <[email-masked]>
Date: Sat, 12 Sep 1998 11:53:30 PDT

>is, etc. and why you need to refer to C's lock in order to execute your

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.