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