- From: <bugzilla@soe.ucsc.edu>
- Date: Sat, 28 Jan 2006 09:09:42 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=211
julian.reschke@greenbytes.de changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|lisa@osafoundation.org |elias@cse.ucsc.edu
Status|REOPENED |NEW
------- Additional Comments From julian.reschke@greenbytes.de 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.
Received on Saturday, 28 January 2006 17:09:47 UTC