[Bug 136] New: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY from bugzilla@soe.ucsc.edu on 2005-10-13 (w3c-dist-auth@w3.org from October to December 2005)

From: <bugzilla@soe.ucsc.edu>
Date: Thu, 13 Oct 2005 08:58:18 -0700
To: w3c-dist-auth@w3.org
Message-Id: <200510131558.j9DFwIeU008427@ietf.cse.ucsc.edu>

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

           Summary: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
           Product: WebDAV-RFC2518-bis
           Version: -07
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: 09.  HTTP Headers for Distributed Authoring
        AssignedTo: joe-bugzilla@cursive.net
        ReportedBy: elias@cse.ucsc.edu
         QAContact: w3c-dist-auth@w3.org


Is the complexity of the IF header appropriate for the simple task of verifying
that a client knowingly owns a lock&#65533; The IF header seems to serve a different
purpose. One of those purposes is for the server to verify that you have the
lock token (and that you know the root of it?). Another is for the client to
check some preconditions before doing an action. Another seems to be to specify
what lock to refresh in a lock refresh request. This seems to create ambiguity
in our definition of the semantics of the IF: header.

Raised by Jason Crawford: Feb 2001

Post: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0055.html :
It is felt by the group that it's important that the client not just own and
hold the lock token, but that it also know where the lock is rooted before it
does tasks related to that lock. This still leaves the lock referesh issue
unresolved.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Thursday, 13 October 2005 15:58:33 UTC