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 Saturday, 12 September 1998 15:06:15 UTC