- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 2 Aug 2001 09:15:46 -0400
- To: w3c-dist-auth@w3.org
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Alan Kent > - LOCK on existing resource stays as is > - LOCK on unmapped URI should (must? can?) create a > non-collection resource MUST if the namespace is kept consistent. A MUST is always better than a SHOULD or MAY, so we should try for a MUST. One alternative is "MUST fail with 404", but to minimize impact on existing implementations, I'd support "MUST create a non-collection resource". I'd phrase it as "MUST produce the same result as if the LOCK were preceded with a PUT with a zero-length body. > - UNLOCK on the same URI without a PUT should (can?) delete the resource Same holds true for LOCK timeout. should or can is the question. Here as well we should try for a MUST. Automatic resource deletion is one of the main incompatibilities of lock-null resources with other protocols. One problem is that when an "unlock" operation is seen, an implementation would have to ask "if this unlock is from WebDAV, then do an auto-delete, otherwise just unlock it". But implementation layering often will not allow you to do a deletion as a side effect of the unlock operation. It is very unlikely that an existing repository will be re-layered to support an unnecessary construct like lock-null resources, which means that (as was done by Microsoft), the auto-delete behavior will not be implemented. There is a reason why no other protocol has introduced a concept like lock-null resources ... they are unnecessary. So I advocate that a resource created by a LOCK on an unbound resource should behave just like a resource created by PUT, with no special auto-delete on UNLOCK characteristics. > - MKCOL on a LOCKed unmapped URI will fail ... I agree, but would phrase this differently. There would be no such thing as an locked unmapped URI, since the LOCK will automatically create a resource, which is then locked. Then it is expected that a MKCOL will fail, because MKCOL only succeeds on an unmapped URI. > In order to completely remove the concept of LNR, PROPFIND must be > cleaned up too. I don't think PROPFIND behavior is affected, but PUT is. > Here are some alternatives: > (1) I would say a LOCK on a unmapped URI MUST create a resource > and lock it. > That way it will appear in PROPFIND's. A PUT on the resource > would then > say 200, not 201. That's what I would expect. I agree. > (2) If a LOCK creates a temporary file, PROPFIND returns it. If a > LOCK does > not create a temporary file, PROPFIND does not return it. > > (3) Keep more of the current semantics. PROPFIND returns info about LNR > resources. If your implementation creates a temporary file, then your > implementation does not have to worry about LNR (but it stays in > the standard as a concept). That makes life of clients unnecessary difficult. I agree. Just say LOCK of an unmapped URI does an "auto-PUT", and then nothing more needs to be said. > I was actually going to propose a new optional flag to say for locks > that the intent is to create a non-collection resource or a collection > resource (where non-collection is the default for backwards > compatibility). I would vigorously argue against this added complexity, without a very compelling argument that this is required for a use case that cannot be otherwise achieved. The question is what to do with such resources when they are unlocked or the lock times out. Possibilities: 1. If the resource disappears, WebDAV still has the concepts of LNRs and servers have to track resources created by a LOCK. 2. If the resource stays as an empty file, the concept of LNRs can be removed completely from the spec. Additionally, servers would have no need to track resources created by LOCK. I favour the second approach. It gives most bang for less bugs. I totally agree. Cheers, Geoff
Received on Thursday, 2 August 2001 09:16:21 UTC