LOCK and RFC 2518

I decided to read RFC 2518 just focusing on locks..  Here are my observations...

> section 6.3
> "Having a lock token provides no special access rights..."
I suggest that the phrase "owned by another party" be added in this first
sentence to distinguish between owning and having.  It speaks of "having" in
this sentence but not subsequently.   In fact "submitting" might be an even
better word than having.

> section 6.3
> ... However resource are free to return any URI scheme so long
>  as it meets the uniqueness requirements.
This is technically correct, but it might also be useful to say that the scheme
should make the URI  be readily recognizable as a *LOCK* state token in the
event that other types of state tokens exist.  I mention this because we seem to
have created the possibility of other types of state tokens.   -- Your call. :-)

> 7.1 Write lock
I believe this definition of a write lock is not right... or not complete...
judging from what I read elsewhere.  I believe one can do these operations
without a write lock... as long as someone else doesn't have a write lock on the
resources effected.

I also believe it doesn't prevent LOCK requests in the case of shared locks.


> section 7.5 Write Locks and Collections
It says that if members are locked in a conflicting manner, then their
collection can't be locked.  That seems ambiguously safe to say, but I suspect
that text should mention depth since if the parent lock request is depth 0, I
don't think we let the members lock state effect the success of the LOCK
request.  The possible exception is what we said about protecting a URI that was
used to perform a lock (of a member of the collection).  I'm not sure what we'd
like to say for that.  In the advanced collection meetings we refered to these
being "protected" and avoided speaking about "lock"ing the URI.  This creates an
odd situation though.

> 7.7 Write Locks and COPY/MOVE
It says that a lock doesn't move with a moved resource.  Of course if the lock
is on the resource, not the URI, it should move with the resource.   But then we
have the caveat that we are also protecting the LOCK'd URI.   I think the rule
should be that if we submit the locktoken with the MOVE request, we are allowed
to have the LOCK move with the resource and the lock will now protect a
different URI.  Also, ALL locks in the subtree must be submitted or the MOVE
must fail because otherwise it would break our URI protection rule.


Upon cursory reading of the rfc 2518 sec 8.10.4 through 8.11   I was confused by
the plethoria of error codes.  Nothing seems to unify them.

8.10.4 speaks of a return code of 409 Conflict   if a lock can't be granted.
  - Firstly, I can't tell if it is saying that the 409 is within the multistatus
body... or in the response header.
  - Secondly, later text seems to use a different status codes and never
mentions this one again.

8.10.7 lists status codes
  - 200 OK, 412 Precondition Failed, and 423 Locked are listed, but 409 Conflict
(mentioned above) is not.
  - In the case of 412 Precondition Failed, the description the follows doesn't
seem to describe a "precondition failed".  And it sounds like it's talking about
an access request that includes a "locktoken", not a LOCK request that generates
one.
  - The 423 Locked condition also sort of sounds like it's talking about an
access request rather than a LOCK request.

8.10.10 lists LOCK status codes
   - 207 Multistatus which was not mentioned above
  -  403 Forbidden which was not mentioned above.
  -  424 Failed dependency which was not mentioned above.

8.11 UNLOCK
  - we don't mention what the failure response should look like.
  - comment: 200 OK seems like a better response than 204 No Content.    The
brief explanation isn't persuasive and seems to say that the response code
should serve the purpose of the Content-Length. header.
  - we should probably explicitly say if an UNLOCK can only be done on the
original resource... and will fail even if the resource specified is locked by
virtue of being a child of the original resource.  Or is this too obvious?  I
know it's something easy to goof up in an implementation.


9.4 If header
  - BNF suggests that IF's content must be all tagged or all untagged.
  - doesn't say if there can be two If headers in a request.  Might we want a
tagged one and an untagged one?
  - I must be misunderstanding this, but it sounds to me like that state of a
resource(s) must match one of the locktokens listed in the request.  But what if
some of the resources are locked and others are not.  The unlocked resources
definitely won't contain state that's listed.    Are we precluding operations on
regions that might not be entirely locked?  -- Is this a valid observation or a
red herring?

9.4.1.1 If header - untagged example
  - See my comment about regions that are not entirely locked.

9.4.2 If header -tagged state
  - So if we've applied a lock with depth.... and now we're doing a DELETE on a
subtree of that tree and we've tagged the locktoken we've submitted, will this
prevent that locktoken from apply'ing to ALL the resources of the subtree... and
thus prevent the COPY from succeeding?  Or are we supposed to tag the lock token
with the root of the LOCK even if that is not part of what we are deleting?   Or
should the request use untagged locktokens?

9.4.3 If header - NOT operator
  - Why do we want this?   of course... why not?  :-)

Overall, the If header seems backwards for locktokens.  It's client driven
rather than server semantics driven.  The only feature it seems to provide is
perhaps the ability for the client to request that the request be aborted if the
resource no longer is locked.  Other than that it seems to complicate the simple
process of letting the server know what tokens you hold.   I'd think we'd just
want a different header to declare what lock tokens we hold and let the server
(not the client) decide how they affect the success of the request.


Shared locks... read locks...

Our justifcation for shared locks  ("Shared locks are included because....")
seems faulty.  It's not a mechansim for dealing with programs that forget to
release their locks.   That remains a problem with shared locks.  In this case
they'd forget to release a shared lock and block exclusive lock users.  Timeouts
and administrative action are the solutions to this problem... not shared locks.

BTW, I'd think that the use of exclusive locks is just fine.  I do have a
problem with shared locks though... or at least shared write locks.  Although
they were relatively easy to define, I see them as solving a red herring problem
of multiple entites cooperatively writing using distinct locks.  I say it's a
red herring because they don't know each other well enough to use the same lock
but they do know each other well enough to not step on each other.  This seems
unlikely.   As does the managing a compatibility matrix and getting all the
entities to abide by it.

OTOH I see another more common problem that is being overlooked.  I see a class
of folks whose purpose is to not actually write to a (set of) resource(s), but
to simply prevent others from writing to it while they are looking at it.
Shared write locks do not necessarily do that because with a shared write lock.
someone else could grab a shared lock and go ahead and write.   The only way to
block that is to get an exclusive write lock.  But doing that prevents anyone
else from doing what you're doing despite it being pretty benign.

An expedient solution is to say that a shared write lock should not necessarily
give one the right to modify a resource.  All it should do is prevent others
from writing.  And then the purpose of an exclusive write lock is just to insure
that others can't get a lock and block you from writing.    Now is this the
right solution?  Probably not.   There probably should be something called a
read lock that actually prevents writes as a side effect.... and would tend to
get used in shared mode.

Anyway, as it is, I think the shared write locks are a red herring and we're
missing something we are more likely to need... shared read locks.

J.

Received on Monday, 7 June 1999 17:18:01 UTC