RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

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