DEFER_LOCK_NULL_RESOURCES_IN_SPEC from Clemm, Geoff on 2001-08-05 (w3c-dist-auth@w3.org from July to September 2001) (original) (raw)

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:ccjason@us.ibm.com]

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

Received on Sunday, 5 August 2001 19:15:13 UTC