- From: <bugzilla@soe.ucsc.edu>
- Date: Fri, 6 Jan 2006 10:41:52 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=197
julian.reschke@greenbytes.de changed:
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |163
AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu
Status|ASSIGNED |NEW
Version|-08 |-10
------- Additional Comments From julian.reschke@greenbytes.de 2006-01-06 10:41 -------
Discussed during 2006-01-06 conference call. Recommendation to close as fixed;
re-assigning to Elias.
In particular:
"9.4 If header
- BNF suggests that IF's content must be all tagged or all untagged. "
Yes.
"- doesn't say if there can be two If headers in a request. Might we want a
tagged one and an untagged one? "
No. There can only be one If header.
"- 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?"
Spec now says untagged If header applies to Request-URI.
"9.4.1.1 If header - untagged example
- See my comment about regions that are not entirely locked."
Resolved by above change, the explanation of the example was updated accordingly.
"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?"
We're going to use the term "submitting" a lock token, which means that the lock
token appears somewhere in the If header (that is, for the action of submitting
it it's irrelevant where it appears).
"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."
Consensus to keep "Not" (see issue 163).
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Friday, 6 January 2006 18:41:57 UTC