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

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Sunday, August 05, 2001 4:13 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
>
>
> 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?
>
> J.

Received on Monday, 6 August 2001 14:51:51 UTC