W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: Jason Crawford <ccjason@us.ibm.com>
Date: Sat, 4 Aug 2001 12:40:09 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: w3c-dist-auth@w3.org
Message-ID: <OFB9F26038.7983BA54-ON85256A9E.005964C3@pok.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 Saturday, 4 August 2001 13:00:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT