W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

[Bug 161] If header section rewrite (was: EVALUATE_ALL_OF_IF_HEADER)

From: <bugzilla@soe.ucsc.edu>
Date: Fri, 17 Feb 2006 06:29:16 -0800
Message-Id: <200602171429.k1HETGv5006367@ietf.cse.ucsc.edu>
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 GMT

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