- From: <bugzilla@soe.ucsc.edu>
- Date: Fri, 17 Feb 2006 06:29:16 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=161
julian.reschke@greenbytes.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
Version|-13 |-14
------- Additional Comments From julian.reschke@greenbytes.de 2006-02-17 06:29 -------
I have reviewed the changes made by Lisa to the text proposed in
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=161#c19>, some of which
were good.
I'm not happy with re-arranging the examples, they now appear in somehow random
locations, not close to the normative text they illustrate. Subsubsection Angst?
Below are the other changes I think should be done, see also
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz161>:
Section 10.4.1., para. 2:
OLD:
o The first purpose is to make a request conditional by supplying a
series of state lists. If the state lists are tested and all
fail, then the request MUST fail with a 412 (Precondition Failed)
status. On the other hand, the request can succeed only if one of
the described state lists succeeds. The success criteria for
state lists are defined in Section 10.4.4 below.
NEW:
o The first purpose is to make a request conditional by supplying a
series of state lists. If none of the state lists match the state
of the resource it applies to, the request MUST fail with a 412
(Precondition Failed) status. Otherwise, the request may succeed.
The matching functions for ETags and state tokens are defined in
Section 10.4.4 below.
(Lisa's rewrite lost the reference to the matching terminology that I think is
essential)
Section 10.4.2., para. 11:
OLD:
10.4.3. List Evaluation
NEW:
10.4.3. Evaluation
(It's about the whole If header, not only individual lists)
Section 10.4.2., para. 16:
OLD:
10.4.4. Matching Tokens and ETags
NEW:
10.4.4. Matching State Tokens and ETags
Section 10.4.2., para. 21:
OLD:
Matching unmapped URLs: for both ETags and state tokens, treat as if
the URL identified a resource that exists but does not have the
specified state.
NEW:
Note that for the purpose of matching entity tags and state tokens,
the URL being unmapped should be treated the same way as if the
resource existed, but did not have the specified state.
(the new language confuses the term matching; the rest of the paragraph just
uses it to Etags and State Tokens)
Section 10.4.5., para. 4:
OLD:
(
is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND
matches-etag("I am an ETag")
)
OR
(
matches-etag("I am another ETag")
)
NEW:
(
is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND
matches-etag("I am an ETag")
)
OR
(
matches-etag("I am another ETag")
)
(whitespace lost)
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Friday, 17 February 2006 14:29:20 UTC