Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: Ilya Kirnos <[email-masked]>
Date: Wed, 01 Aug 2001 19:52:59 -0700

>
> I don't think LNRs should be changed at all.
>
> You could use a file to track the lock if you wish and you won't be
> deviating from the RFC.
>
> The RFC doesn't place restrictions on implementation (in this case LNRs) -
> you can basically use whatever you want, so why are you suggesting that the
> semantics should be changed ?
>
> Its an implementation problem, not a protocol problem.
>

As I recall, there are some restrictions on the behavior of a lock-null
resource that make it difficult to track with an honest-to-goodness file.  For
example:

As I recall an LNR is supposed to show up as a member of its parent collection,
but return 404 when you try to do a GET on it.  This means you have to keep
some metadata about that file to know that it's 'special'.  You can keep it in
the DAV server, but nobody else would know or care about it, so even another
DAV server (forget other protocols) working against the same filesystem
wouldn't know about the 'specialness'.  Why would you want to limit DAV locking
in this way if you have a filesystem that supports locking natively, for
example?

I think there were other examples as well.  Generally, IMHO, LNRs have unusual
behavior, and perhaps we can solve the problems LNRs are intended to solve and
make them a little easier to implement on many existing systems.

Like I said, I'd be up for keeping LNRs if things like this were amended.  I
know these are all implementation details, but if the implementation becomes
one hack after another, as I think LNRs would have to be as currently defined,
maybe it's time to step back and revisit the spec.

-ilya

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 2 Aug 2001 09:15:46 -0400

From: Stefan Eissing [mailto:[email-masked]]

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

---

From: "Jason Crawford" <[email-masked]>
Date: Thu, 2 Aug 2001 14:11:39 -0400

> - UNLOCK on the same URI without a PUT should (can?) delete the resource

I think most people would change this to be...

- UNLOCK on the same URI without a PUT should NOT delete the resource

This will give existing implementations that try to delete it some
flexibility but push people away from that direction.  I doubt we can say
anything stronger right now.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 2 Aug 2001 16:52:08 -0400

I agree with Jason's revision, although I'd probably further revise the
wording to say:

"When a new resource is created by a LOCK request against an
unmapped URI, if an UNLOCK is applied to that resource before it
has been explicitly updated (e.g. by a PUT or a PROPPATCH), then
that resource SHOULD NOT be deleted as a side effect of the UNLOCK.
Note that this changes the behavior defined in RFC-2518, which
stated that the resource MUST be deleted in this case."

Cheers,
Geoff

---

From: "Jason Crawford" <[email-masked]>
Date: Sat, 4 Aug 2001 12:40:09 -0400

> stated that the resource MUST be deleted in this case."

I support Geoff's wording above over my little one liner.  :-)

This would be in conjuction with Alan Kent's proposals...

> - LOCK on unmapped URI [should] create a non-collection resource
> - MKCOL on a LOCKed unmapped URI will fail (pity, but too bad).

So is this the way we want to go?

Items of note so far (just to make sure we're comfortable with this):

- We don't speak about what happens if you violate Geoff's (SHOULD NOT).

- This doesn't speak about the nature of the non-collection resource
created.  Nor do we explicitly mention that this is a change of behavior
from 2518 except through Geoff's words about what happens upon UNLOCK.

- Presumably we'd only use the "MKCOL on a LOCKed..." wording if somewhere
in the 2518 it says otherwise since this is implicit if we are clear that
we generated an ordinary non-collection resource.

Comments?  Wordings?  Additions?

J.

---

From: "Hall, Shaun" <[email-masked]>
Date: Fri, 10 Aug 2001 11:15:39 +0100

Since the general consesus of the list is to do away with LNRs as we know
them, if you can't beat em, join em :-)

It makes sense for 201 to be the response for LOCKing an unmapped URL. This
was discussed a while ago.

I think Jim said he would add this to the issues list. Jim ?

Regards

Shaun Hall
Xerox Europe

> Sent: 10 August 2001 09:26
> To: Jason Crawford; Lisa Dusseault
> Cc: Clemm, Geoff; [email-masked]
> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
> 
> 
> For me, an addition to the Status Codes (currently Sec. 8.10.7)
> would suffice. A la
> 
> 201 (Created) - The lock request succeeded by creating a new resource
> and the value of the lockdiscovery property is included in the body.
> 
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Jason Crawford
> > Sent: Thursday, August 09, 2001 9:12 PM
> > To: Lisa Dusseault
> > Cc: Clemm, Geoff; [email-masked]
> > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
> >
> >
> >
> >
> >
> > It sounds like we all agree with Geoff's wording.
> >
> > Lisa did make an interesting observation below though.
> >
> > <<
> > This means that LOCK can return 201, which is important to 
> distingusih
> > between LOCK of an unmapped URL (I can go ahead and put my 
> content) and
> > LOCK
> > of URL that somebody else just created (I should NOT send my
> > content before
> > checking).
> > >>
> >
> > Do we want to enhance Geoff's explanation or add a comment 
> along the lines
> > of Lisa's observation?   Or just make sure we mention 201 
> where we list
> > potential error codes for LOCK requests?
> >
> > J.
> >
> >
> >
> >
>

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 10 Aug 2001 12:33:05 -0400

I think that adding 201 to the list of status codes returned by
LOCK is the right approach.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Thursday, August 09, 2001 3:12 PM
To: Lisa Dusseault
Cc: Clemm, Geoff; [email-masked]
Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

<<
This means that LOCK can return 201, which is important to distingusih
between LOCK of an unmapped URL (I can go ahead and put my content) and
LOCK
of URL that somebody else just created (I should NOT send my content before
checking).

Do we want to enhance Geoff's explanation or add a comment along the lines
of Lisa's observation?   Or just make sure we mention 201 where we list
potential error codes for LOCK requests?

J.

---

From: "Jason Crawford" <[email-masked]>
Date: Tue, 14 Aug 2001 14:01:31 -0400

Okay all...

I've just entered this issue as resolved.   The resolution consists largely
of what is suggested in the following posting by Geoff.

http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0107.html

The following other issues as resolved by virtue of the fact that we no
longer have LNR's...
COPY_OVER_WRITE_LOCK_NULL
LOCK_NULL_SLASH_URL
NULL_RESOURCE_CLARIFY

I'll list the 201 status response discussion and consensus as a resolution
of the LOCK_NULL_STATUS_CREATION issue shortly.

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]