W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

three clarification questions on the If header.

From: Jim Davis <jdavis@parc.xerox.com>
Date: Fri, 11 Sep 1998 15:00:16 PDT
Message-Id: <3.0.5.32.19980911150016.0080db30@mailback.parc.xerox.com>
To: w3c-dist-auth@w3.org
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.)

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?

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.
Received on Friday, 11 September 1998 18:00:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:47 GMT