RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

   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