Re: If: header and "parent" resource checking

I believe a "lock-null" resource is best treated as a convenient
fiction maintained in order to make it easy to query for the existence
of locks.

In particular, according to section 7.4 of 2518, a lock null resource
acts the same as a null resource for all methods except for PROPFIND
and UNLOCK.  A DELETE on a lock null resource MUST fail, a MOVE on a
lock null resource MUST fail, a COPY on a lock null resource MUST
fail, etc.

The reason I am particularly concerned that the creation of a lock NOT
be treated as a modification of the state of the parent collection is
to ensure that effect of creating a lock-null resource is treated
consistently in the versioning and the locking protocols.

In the versioning protocol, the creation of a lock-null resource cannot
be a modification to the state of the collection containing it, because
if the collection were versioned, this would then require a new revision
of that collection in order to hold the "new resource".  But then this
lock-null resource could never be removed from this collection revision,
because revisions are immutable.

On the other hand, if the addition of a lock is not considered a modification
to the state of a collection, but rather the modification occurs at the
first PUT, then all is well ... no "immutable" locks end up being captured.
In this model, a lock is not a modification to the state of a resource
(either the resource itself, or the collection containing the lock), but
rather "metadata" that controls interactions with the state of the resource.

In versioning, this is also how "labels" are handled, i.e. as metadata on
a resource that does not modify the state of the resource.

I'd *very* much like the versioning protocol and the locking protocol to
be consistent as to whether the creation of a lock-null resource modifies the
state of the collection containing them.  Since I don't see that the
versioning protocol has a choice in this regard, I'd like to see the locking
protocol handle it the same way, unless there is some serious problem that
arises from doing so.

So I guess what I'd like to hear is why it is important for the addition
of a lock-null resource to be treated as a modification to the state of
the collection containing it.

Cheers,
Geoff

   Date: Sun, 28 May 2000 03:41:01 -0700 (PDT)
   From: Greg Stein <gstein@lyra.org>

   On Sat, 27 May 2000, Geoffrey M. Clemm wrote:
   > What Greg proposes is consistent with what is stated in 2518.
   > 
   > But I believe it is also consistent to say that a lock null resource
   > is not treated as a real member of a collection (just as there are
   > various other ways where it doesn't act like a real resource).

   I see no rationale to create more differences :-)

   > This is compatible with section 7.5 of 2518, which states that:
   > 
   >    when a principal issues a PUT or POST request to create a new
   >    resource under a URI which needs to be an internal member of a write
   >    locked collection to maintain HTTP namespace consistency, or issues a
   >    DELETE to remove a resource which has a URI which is an existing
   >    internal member URI of a write locked collection, this request MUST
   >    fail if the principal does not have a write lock on the collection.
   > 
   > i.e. it says nothing about the creation of "lock-null" resources via
   > the LOCK request.

   I think that you are being too literal in your reading [in order to
   support your position]. Note that the text in question does not mention
   MKCOL or BIND, yet we expect the client to provide a locktoken for the
   parent on those methods.

   In other words, I am reading S7.5 as a "general description of behavior"
   rather than a literal/explicit description. As a result, the creation of
   ANY internal member, by ANY means, should (IMO) require the client to
   provide locktokens for the [write-locked] parent collection.

   > Having a LOCK request not interact with locks on a parent collection
   > ensures that a LOCK request has consistent behavior wrt a write-locked
   > parent collection, whether or not a resource currently exists at the
   > LOCK request-URL.  It also ensures you do not get the bizarre behavior
   > where the first shared lock on a null resource requires the lock token
   > for a locked parent collection, while all subsequent shared locks do not.

   You can't issue two MKCOL methods for the same resource, so I believe
   there is precedent for the different behavior.

   Using lock to create a locknull resource is a state-changing operation of
   the target resource. It seems quite reasonable to have methods operate
   differently, based on the different states of that resource.

   Another counter-example for you:

       Collection <locktoken A, depth=0>
	 (no internal members)

   The client issues a PUT to create "Resource" within Collection. Since this
   is the first PUT (thusly creating the internal member), locktoken A must
   be provided. Now the client issues a second PUT. But wait! The locktoken
   DOES NOT need to be provided.


   Therefore: I submit that your argument does not hold, and that the
   behavior that I detailed w.r.t. locknull resources is "correct."

   I'm still quite open to discussion, of course. I don't want to create
   incompatibilities in behavior.

   Cheers,
   -g

   p.s. of course, IIS5 doesn't even allow collection locks, so clients can
   simply be screwed anyhow :-)

   -- 
   Greg Stein, http://www.lyra.org/

Received on Sunday, 28 May 2000 14:13:14 UTC