Subject: [Bug 211] Inconsistencies about Destination header

From: [email-masked]
Date: Sat, 28 Jan 2006 09:09:42 -0800

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

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         [email-masked]      [email-masked]
             Status|REOPENED                    |NEW

------- Additional Comments From [email-masked]  2006-01-28 09:09 -------
and:

4) This change needs to appear in the Changes Section.

Proposed changes below and at
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz211>:

Section 10.1., para. 0:
OLD:

 10.1.  DAV Header

NEW:

    The ABNF productions below are used in the following header
    definitions:
 
       Coded-URI        = "<" absolute-URI ">"
                          ; no LWS allowed in Coded-URI
 
       Reference        = absolute-URI | ( path-absolute [ "?" query ] )
 
       Coded-Reference  = "<" Reference ">"
                          ; no LWS allowed in Coded-Reference
 
       ; absolute-URI:  see Section 4.3 of [RFC3986]
       ; path-absolute: see Section 3.3 of [RFC3986]
       ; query:         see Section 3.4 of [RFC3986]
 
 10.1.  DAV Header

(define grammar elements upfront)

Section 10.1., para. 1:
OLD:

       DAV              = "DAV" ":" #( compliance-class )
       compliance-class = ( "1" | "2" | "3" | extend )
       extend           = Coded-URL | token
       Coded-URL        = "<" absolute-URI ">"
                           ; No LWS allowed in Coded-URL
                           ; absolute-URI is defined in RFC3986

NEW:

       DAV              = "DAV" ":" #1compliance-class
       compliance-class = "1" | "2" | "3" | extend
       extend           = Coded-URI | token
       ; token: see Section 2.2 of [RFC2616]

(simplify grammar)

Section 10.1., para. 3:
OLD:

    The value is a comma-separated list of all compliance class
    identifiers that the resource supports.  Class identifiers may be
    Coded-URLs or tokens (as defined by [RFC2616]).  Identifiers can
    appear in any order.  Identifiers that are standardized through the
    IETF RFC process are tokens, but other identifiers SHOULD be Coded-
    URLs to encourage uniqueness.

NEW:

    The value is a comma-separated list of all compliance class
    identifiers that the resource supports.  Class identifiers may be
    Coded-URIs or tokens (as defined by [RFC2616]).  Identifiers can
    appear in any order.  Identifiers that are standardized through the
    IETF RFC process are tokens, but other identifiers SHOULD be Coded-
    URIs to encourage uniqueness.

(Coded-URL -> Coded-URI)

Section 10.3., para. 2:
OLD:

            Destination = "Destination" ":" ( URI-reference )
 
    The URI-reference production is defined in section 4.1 of [RFC3986],
    with further rules for URI handling in Section 8.2.

NEW:

            Destination = "Destination" ":" Reference

(simplify grammar, remove ref to 8.2)

Section 10.3., para. 3:
OLD:

    If the Destination value is an absolute URI, it may name a different
    server (or different port or scheme).  If the source server cannot
    attempt a copy to the remote server, it MUST fail the request with a
    502 (Bad Gateway) response.

NEW:

    If the Destination value is an absolute-URI (Section 4.3 of
    [RFC3986]), it may name a different server (or different port or
    scheme).  If the source server cannot attempt a copy to the remote
    server, it MUST fail the request.

(relax language on 502, use RFC3986 productions)

Section 10.4., para. 1:
OLD:

       If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
       No-tag-list = List
       Tagged-list = Resource 1*List
       Resource = Coded-Reference
       List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
            ; No LWS allowed between "[", entity-tag and "]"
       State-token = Coded-URL
       Coded-Reference        = "<" URI-reference ">"
            ; No LWS allowed in Coded-Reference

NEW:

       If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
       No-tag-list = List
       Tagged-list = Coded-Reference 1*List
       List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
       State-token = Coded-URI

(simplify grammar)

Section 10.4., para. 3:
OLD:

    The URI-reference production is defined in section 4.1 of [RFC3986],
    with further rules for URI handling in Section 8.2.
 
    The If header's purpose is to describe a series of state lists.  If
    the state of the resource to which the header is applied does not
    match any of the specified state lists then the request MUST fail
    with a 412 (Precondition Failed).  If one of the described state
    lists matches the state of the resource then the request may succeed.

NEW:

    The If header's purpose is to describe a series of state lists.  If
    the state of the resource to which the header is applied does not
    match any of the specified state lists then the request MUST fail
    with a 412 (Precondition Failed).  If one of the described state
    lists matches the state of the resource then the request may succeed.

(remove ref to 8.2)

Section 10.4.3., para. 2:
OLD:

      COPY /resource1 HTTP/1.1
      Host: www.example.com
      Destination: http://www.example.com/resource2
      If: <http://www.example.com/resource1>
            (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
            [W/"A weak ETag"]) (["strong ETag"])
          <http://www.example.com/random>
            (["another strong ETag"])

NEW:

      COPY /resource1 HTTP/1.1
      Host: www.example.com
      Destination: http://www.example.com/resource2
      If: </resource1>
            (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
            [W/"A weak ETag"]) (["strong ETag"])
          </random>
            (["another strong ETag"])

(use new notation in one example)

Section 10.5., para. 1:
OLD:

       Lock-Token = "Lock-Token" ":" Coded-URL

NEW:

       Lock-Token = "Lock-Token" ":" Coded-URI

(Coded-URL -> Coded-URI)

Appendix E., para. 25:
OLD:

 E.2.  Changes Notable to Client Implementors

NEW:

    Destination headers and Tagged Lists in If headers can now contain
    absolute paths in addition to URIs. [[anchor118: Also affects
    clients.]]
 
 E.2.  Changes Notable to Client Implementors

(mention change)

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
You are on the CC list for the bug, or are watching someone who is.