Subject: FW: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 17 Jul 2001 19:24:38 -0700

Jason had trouble sending a message to the DAV list -- let's see if this one
goes through...

- Jim

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 7:12 PM
To: [email-masked]
Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

Jim,
The following note doesn't seem to have reached the list.  You might want
to probe for errors with the list server...

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---------------------- Forwarded by Jason Crawford/Watson/IBM on 07/17/2001
10:11 PM ---------------------------

Jason Crawford
07/17/2001 04:26 PM

To:   "Clemm, Geoff" <[email-masked]>
cc:   WebDAV <[email-masked]>
From: Jason Crawford/Watson/IBM@IBMUS
Subject:  RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC  (Document
      link: Jason Crawford)

Can have a few more people speak up on the above thread.   So far we've
just heard from Geoff and Lisa.  Any comments on either of their postings?
Any additional comments?

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 18 Jul 2001 10:09:02 -0400

From: Stefan Eissing [mailto:[email-masked]]

   As an implementor of server and client software using WebDAV, I
   would have gladly skipped the mechanisms known as lock-null
   resources. As Geoff pointed out in this thread, there are
   alternatives for clients to live without them (although not quite
   as comfortable).

It's probably worth noting that a client gains little or nothing
from the use of lock-null resources.  In the common case, the user
has selected either "Open" or "New" from some user interface.
In the Open case, the user is expecting an error if the resource does
not exist, so having LOCK return 404 actually makes the client
protocol simpler.  In the New case, the user is expecting an error
if the resource already exists, so a PUT/If-None-Match
can be used to determine if the resource does not exist,
followed by a LOCK to verify the resource can be write locked.

In case the user interface does not distinguish between Open and
New, the client just follows the LOCK call with a:
 if status is 404 then
    PUT/If-None-Match # ignore status from this request
    LOCK
and otherwise uses the exact same code it would have used if
lock null resources were supported.  (Note: the "PUT" would
whatever is the right call to create a null resource of the
right type, e.g. MKCOL for collections, MKACTIVITY for activities,
or whatever).

   But the choice to include lock-null has been made in the past and I
   see more trouble with abandoning it, than keeping it. Every
   implementation I've seen (and that might be too few) implements
   lock-null correctly.

You need to look at the Microsoft IIS implementation.  When a LOCK
is applied to an unmapped URI, it just automatically preceded the
LOCK with a PUT with a 0 length body.  The result is a regular
locked resource, not a lock null resource.  In particular, MKCOL will
fail on that resource, and when you remove the lock, you still
have the 0 length resource (i.e. it doesn't disappear, as a lock
null resource is required to do).

Note: Our implementation is likely to act the same way, probably
for the same reasons as Microsoft, i.e. we support multiple protocols
accessing our repository, and none of the other protocols have
anything remotely resembling lock null resources.

   Apart from certain software from Seattle based companies: their
   server has an incomplete implementation, which works only for
   ordinary resources.  It works good enough for the Seattle client
   software which uses this feature.

   Now, if WebDAV removes lock-null, every server implementor would
   have to support it anyway, because 90% of the users use those
   Seattle clients.  I therefore see nothing to gain on the server
   side by abandoning lock-null.

Having your server support the behavior expected by IIS is easy, just
automatically create a 0-length resource.  It is real lock-null
behavior (which is not implemented by IIS) which is the problem.

In the revised protocol, we can warn clients about the various ways
that existing servers deal with a LOCK applied to an unmapped URI, but
could increase interoperability in the future by stating that a LOCK
to an unmapped URI SHOULD return a 404.

   On the client side, lock-null is a comfortable thing to use. So there is
   nothing to gain either.

If you care about interoperability, it is not comfortable to use
because it is not implemented uniformly, so you have to special
case around the alternative implementations.  The client code will
be simpler if it just doesn't use lock null resources at all.

   So, I'd say: let's embrace and extend lock-null resources.

Lock-null resources are very unlikely to be embraced by implementors
who must care about multiple protocols accessing their repositories
(and commercial vendors are almost all in that situation).  Any
attempt to embrace (much less extend) lock-null resources will result
in interoperability problems.  If they were the only good way to
provide a key client use case, I'd be willing to live with the
interoperability problems, but since the lock-null use cases are
easily supported without lock-null resources, I see no reason to
persist (much less, increase) these problems.

Cheers,
Geoff

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 25 Jul 2001 02:33:58 -0400

From: Keith Wannamaker [mailto:[email-masked]]

   The point is, of course, there are plenty of other servers that have
   implemented locknull correctly and fully.  You're throwing away a 
   tremendous amount of work away if you pull it from the spec. 

If implementing locknull correctly and fully involved a tremendous
amount of work, that is already one strike against it, unless it
is required for some important use case.  It has been demonstrated
that lock null resources are not required for the use case
that has commonly been used to motivate their existence.

We already have an interoperability problem because of the inherent
conflict between lock null resources and multi-protocol repositories,
but we have an opportunity to:
- free subsequent implementors from the burden of lock null resources
- increase interoperability by avoiding an unnecessary construct that
  has at least one major inconsistent implementation today.

   The other reason I disagree with dropping it is that there had to
   be a reason that lock-null was chosen as the solution to the
   lost update problem rather than the alternatives you suggest.
   Perhaps someone else can speak to this, as I imagine this road
   has already been traveled.

I believe that the degree to which 2518 will just be carried forward
unchanged into the next draft is a striking example of the high
quality of work resulting from the IETF process, the WebDAV working
group, and the authors of 2518.  But there will be some lessons
learned in going from proposed standard to draft standard, and I
believe that the removal of lock null resources is one of them.

Cheers,
Geoff