W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

[Bug 194] New: LOCK_ISSUES_WRITE_LOCKS_AND_COLLECTIONS

From: <bugzilla@soe.ucsc.edu>
Date: Mon, 21 Nov 2005 09:29:11 -0800
Message-Id: <200511211729.jALHTBt4004660@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=194

           Summary: LOCK_ISSUES_WRITE_LOCKS_AND_COLLECTIONS
           Product: WebDAV-RFC2518-bis
           Version: -08
          Platform: Other
               URL: http://lists.w3.org/Archives/Public/w3c-dist-
                    auth/1999AprJun/0246.html
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: 07.  Write Lock
        AssignedTo: joe-bugzilla@cursive.net
        ReportedBy: julian.reschke@greenbytes.de
         QAContact: w3c-dist-auth@w3.org


Reported by Jason Crawford in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>:

Section 7.5 Write Locks and Collections. 
It says that if members are locked in a conflicting manner, then their
collection can't be locked. That seems ambiguously safe to say, but I suspect
that text should mention depth since if the parent lock request is depth 0, I
don't think we let the members lock state effect the success of the LOCK
request. The possible exception is what we said about protecting a URI that was
used to perform a lock (of a member of the collection). I'm not sure what we'd
like to say for that. In the advanced collection meetings we refered to these
being "protected" and avoided speaking about "lock"ing the URI. This creates an
odd situation though.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Monday, 21 November 2005 17:29:21 GMT

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