RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

   From: Keith Wannamaker [mailto:Keith@Wannamaker.org]

   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

Received on Wednesday, 25 July 2001 02:26:17 UTC