Subject: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: "Jason Crawford" <[email-masked]>
Date: Thu, 12 Jul 2001 01:54:43 -0400

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,   [email-masked]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 12 Jul 2001 11:45:59 -0700

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Wednesday, July 11, 2001 10:55 PM
> To: WebDAV
> Subject: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
>
>
>
>
> -----------