Re: [Bug 124] REPORT_OTHER_RESOURCE_LOCKED

Proposed changes in
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz124>
(reassigning to Elias to schedule discussion in conference call)

In particular:

Section 7., para. 71:
OLD:

     If a depth-infinity write LOCK request is issued to a collection
     containing member URLs identifying resources that are currently
     locked in a manner which conflicts with the write lock, the request
     MUST fail with a 423 (Locked) status code, and the response SHOULD
     contain the 'lock-token-present' precondition.

NEW:

     If a depth-infinity write LOCK request is issued to a collection
     containing member URLs identifying resources that are currently
     locked in a manner which conflicts with the write lock, the request
     MUST fail with a 423 (Locked) status code, and the response SHOULD
     contain the 'no-conflicting-lock' (Section 15.7) precondition.


Section 8., para. 271:
OLD:

     423 (Locked) - The resource is locked already.

NEW:

     423 (Locked), potentially with 'no-conflicting-lock' (Section 15.7)
     precondition code - There is already a lock on the resource which is
     not compatible with the requested lock (see lock compatibility table
     above).



Section 10., para. 7:
OLD:

     The 423 (Locked) status code means the source or destination resource
     of a method is locked.  This response SHOULD contain the 'lock-token-
     present' precondition element and corresponding 'href' in the error
     body.

NEW:

     The 423 (Locked) status code means the source or destination resource
     of a method is locked.  This response SHOULD contain an appropriate
     precondition code, such as 'lock-token-present' (Section 15.6) or
     'no-conflicting-lock' (Section 15.7).



NEW:

  15.7  DAV:no-conflicting-lock (precondition)

     This precondition code can be used to signal that a lock request
     failed due the presence of an already existing conflicting lock.
     Note that a lock can be in conflict although the resource to which
     the request was directed is only indirectly locked.  In this case,
     the precondition code can be used to inform the client about the
     resource which is the root of the conflicting lock, avoiding a
     separate lookup of the "lockdiscovery" property. [[anchor103: Make
     sure the document actually defines "indirectly locked".]]

            <!ELEMENT no-conflicting-lock (href)* >

     Servers SHOULD insert a DAV:href element for the URL of the root of
     the conflicting lock.

Received on Saturday, 31 December 2005 15:48:35 UTC