Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: "Clemm, Geoff" <[email-masked]>
Date: Sun, 5 Aug 2001 19:13:00 -0400

The full proposal I advocate is as follows:

Delete all references to the term "lock null resource".

Instead, in the LOCK semantics, add the following:

"If a LOCK request is applied to an unmapped URL, the server
MUST automatically precede the LOCK request with the creation
of a resource at the request URL.
This automatically created resource has the same behavior as
a resource created by a PUT with a zero length body.
In particular, it is never automatically deleted when it is
UNLOCK'ed.  Note that this changes the behavior defined in
RFC-2518, which stated that the resource MUST be automatically
deleted if it is unlocked before it has been explicitly updated
(e.g. by a PUT)."

I believe that this reference to the old 2518 semantics is sufficient.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]

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

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

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

> - LOCK on existing resource stays as is
> - 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: "Stefan Eissing" <[email-masked]>
Date: Mon, 6 Aug 2001 09:32:18 +0200

> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Monday, August 06, 2001 1:13 AM
> To: [email-masked]
> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
> 
> 

I fully agree and support the proposal.

//Stefan

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 6 Aug 2001 11:51:08 -0700

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

lisa

> From: [email-masked]
> Sent: Sunday, August 05, 2001 4:13 PM
> To: [email-masked]

---

From: Ilya Kirnos <[email-masked]>
Date: Thu, 09 Aug 2001 00:15:09 -0700

(apologies if this is a duplicate)

> I fully agree and support the proposal.

This sounds good to me as well.

-ilya

---

From: Ilya Kirnos <[email-masked]>
Date: Mon, 06 Aug 2001 18:52:49 -0700

-ilya