- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 10 Aug 2001 10:26:14 +0200
- To: "Jason Crawford" <ccjason@us.ibm.com>, "Lisa Dusseault" <lisa@xythos.com>
- Cc: "Clemm, Geoff" <gclemm@Rational.Com>, <w3c-dist-auth@w3.org>
For me, an addition to the Status Codes (currently Sec. 8.10.7) would suffice. A la 201 (Created) - The lock request succeeded by creating a new resource and the value of the lockdiscovery property is included in the body. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Thursday, August 09, 2001 9:12 PM > To: Lisa Dusseault > Cc: Clemm, Geoff; w3c-dist-auth@w3.org > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > > > It sounds like we all agree with Geoff's wording. > > Lisa did make an interesting observation below though. > > << > 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). > >> > > Do we want to enhance Geoff's explanation or add a comment along the lines > of Lisa's observation? Or just make sure we mention 201 where we list > potential error codes for LOCK requests? > > J. > > > >
Received on Friday, 10 August 2001 04:26:43 UTC