Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 13 Jul 2001 14:45:12 -0400

From: Lisa Dusseault [mailto:[email-masked]]

   Since somebody was asking if lock-null resources have been implemented:
    - Xythos WebFile Server implements lock-null resources
    - I believe the Microsoft DAV servers allow LOCK of a non-mapped URL
then
   PUT.  Their version of a lock null resource may not support MKCOL, and it
   may not disappear when the lock expires, but it still solves the
lost-update
   problem for a new resource (not a problem for MKCOL).
    - Our tests of Office XP show it seems to use lock null resources.

Note that the main issue is not whether anyone has implemented lock
null resources, but rather that different repositories have
implemented them differently because the current lock null semantics
are incompatible with the semantics of those repositories.
To me, this is a clear signal that lock null resources are not
a basis for interoperability.

   My next concern is that the functionality was intended to solve an
   important problem - the lost-update problem for a new resource is
   the problem that two users can both try to create a resource with
   the same name using PUT.  One overwrites the other unwittingly.

It has been demonstrated in the recent thread on lock null resources
that the lost-update problem for a new resource can be solved without
the use of lock-null resources.  In particular, you do a
PUT/If-None-Match with a zero length body, followed by a LOCK (or if you
wanted to create a collection, a MKCOL followed by a LOCK, or
if you wanted to create an activity, a MKACTIVITY followed by a LOCK,
etc.).

   LOCK already solves the lost-update
   problem for existing resources, so it seemed reasonable at the time to
use
   the same mechanism for new resources.

Yes, but there is no need for a lock-null resource.  You create an
"empty" resource at the location, which gives you a real resource to
lock, and then lock it (before you do any updates to that resource
that you care about).  The fact that another client can LOCK the new
empty resource is of no significance, since it does not have any of
the content that you care about yet (i.e. it is no different from them
getting their "lock" request in before yours).  If the server gives
the owner special permissions on the new resource, that is fine (and
only the creating client's LOCK will succeed), but it is not
necessary for solving the lost update to a new resource problem.

   Since lock null resources solve an important problem, and since
   they have been implemented, I'd object to removing them from
   RFC2518.  Although it may be possible to try to simplify, I'd
   hesitate.  We'd want to make sure there was a good reason to do
   that.  Is there any serious problem with the existing definition?

The current implementations have demonstrated that lock null resources
are not a basis for interoperability.  That is the serious problem
that is being addressed by removing them from the protocol.

Cheers,
Geoff

---

From: "Keith Wannamaker" <[email-masked]>
Date: Mon, 23 Jul 2001 12:54:52 -0400

| The current implementations have demonstrated that lock null resources
| are not a basis for interoperability.

This statement has been mentioned several times, in one form or
another, in this thread.  Do you have documentation or test cases
for these interoperability problems?

When I did the initial locknull implementation for mod_dav, it seemed
to me that the notion of a lock-null resource as presented in 2518
was very clear and logical.  On what have implementors disagreed?

It seems to me that we gain more from the work already done and
implemented to clarify, if needed, rather than abandon.

Keith

---

From: "Stefan Eissing" <[email-masked]>
Date: Tue, 24 Jul 2001 10:24:04 +0200

> [mailto:[email-masked]]On Behalf Of Keith Wannamaker
> 

One example is Microsoft IIS which does not implement lock-null resources
as specified in 2518. E.g. MKCOL will not work and lock-null resources
will not disappear after lock timeout.

> was very clear and logical.  On what have implementors disagreed?

mod_dav is an excellent implementation.
 
> implemented to clarify, if needed, rather than abandon.

The point made is that the specified behaviour might not be worth
the effort. Limiting the lock-null requirements could result in
making (server) implementations easier without giving up any
functionality. The benefit for clients would be that more servers
will comply to the spec.

//Stefan