Subject: RE: Status code for creating lock-null resource

From: "Jason Crawford" <[email-masked]>
Date: Mon, 2 Jul 2001 01:22:13 -0400

<<
So I think we should just say "A server SHOULD fail
an attempt to lock an unmapped URL", and then remain
silent on what a server might end up doing if it lets
the lock of an unmapped URL succeed.  In general,
a MAY here is of little more use to the client than having
the protocol remain discretely silent, and the
benefit of using one of the several different
flavors of lock-null behavior is unlikely to warrant
writing special purpose code for each of those flavors.

Geoff,
    After looking over the binding spec and how it relates to locking, I've
changed my position to support what you've just said.  I think it's
important that we move forward and we are spending a lot of time on LNR
despite the fact that many of us over the last few years have expressed a
desire to remove them and as far as I know no one has taken a strong stand
for them or their functionality.  I suggest, as you have above, that we
simply drop LNR's in a way that doesn't prevent us from adding them or
something equivalent to the spec later if we decide there really is a need
for them.   Your suggestion above is the best one down this path that I've
seen recently.  I hope we all can quickly agree on it.

J.