[Bug 197] New: LOCK_ISSUES_IF_HEADER

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

           Summary: LOCK_ISSUES_IF_HEADER
           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: 09.  HTTP Headers for Distributed Authoring
        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>:

9.4 If header 
- BNF suggests that IF's content must be all tagged or all untagged. 
- doesn't say if there can be two If headers in a request. Might we want a
tagged one and an untagged one? 
- I must be misunderstanding this, but it sounds to me like that state of a
resource(s) must match one of the locktokens listed in the request. But what if
some of the resources are locked and others are not. The unlocked resources
definitely won't contain state that's listed. Are we precluding operations on
regions that might not be entirely locked? -- Is this a valid observation or a
red herring? 
9.4.1.1 If header - untagged example 
- See my comment about regions that are not entirely locked. 
9.4.2 If header -tagged state 
- So if we've applied a lock with depth.... and now we're doing a DELETE on a
subtree of that tree and we've tagged the locktoken we've submitted, will this
prevent that locktoken from apply'ing to ALL the resources of the subtree... and
thus prevent the COPY from succeeding? Or are we supposed to tag the lock token
with the root of the LOCK even if that is not part of what we are deleting? Or
should the request use untagged locktokens? 
9.4.3 If header - NOT operator 
- Why do we want this? of course... why not? :-) 
Overall, the If header seems backwards for locktokens. It's client driven rather
than server semantics driven. The only feature it seems to provide is perhaps
the ability for the client to request that the request be aborted if the
resource no longer is locked. Other than that it seems to complicate the simple
process of letting the server know what tokens you hold. I'd think we'd just
want a different header to declare what lock tokens we hold and let the server
(not the client) decide how they affect the success of the request.



------- 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:32:44 UTC