RE: Status code for creating lock-null resource

<<
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.

Received on Monday, 2 July 2001 01:23:33 UTC