RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

Good thing you're making sure :)

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.

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

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?

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Wednesday, July 11, 2001 10:55 PM
> To: WebDAV
> Subject: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
>
>
>
>
> I've just entered this one in the issues list.  I think we basically
> settled on this but I just want to make sure.
>
> ------------------------------------------------------------------
> -----------
>
> DEFER_LOCK_NULL_RESOURCES_IN_SPEC
>
> Proposal to remove lock null resources from the spec until we are
> motivated
> to have them or something equivalent.  In the meantime, keep the spec
> silent on the topic in order to avoid precluding LNR or the
> equivalent in a
> future version of WebDAV.
> ------------------------------------------------------------------
>
> The issue references the following posting
>
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0354.html
>
> and more particularly the following paragraph:
>
> 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.
>
> If we can get this resolved it might actually resolve a lot of other
> unresolved issues on the issues list.    Let's try to settle on this by
> Monday.
>
> J.
>
> ------------------------------------------
> Phone: 914-784-7569,   ccjason@us.ibm.com

Received on Thursday, 12 July 2001 14:46:22 UTC