Re: If: header and "parent" resource checking

See <jra> tags below.


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.
<jra>
The lock-null resource appears as a member of its parent collection, so it
must modify its state. Otherwise, how would one see the results of the LOCK
request?
</jra>

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.
<jra>
The versioned collection only needs to have a working revision. The
lock-null resource may be deleted (with unlock) or converted to a real
resource (with put) before the working revision of the versioned collection
is checked back in.
</jra>

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.
<jra>
Just so you can see the results of the LOCK operation and have a URL to
unlock or put.
</jra>

Received on Monday, 29 May 2000 09:11:42 UTC