[Bug 86] DAV header definitions should use RFC3864 templates

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

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu



------- Additional Comments From julian.reschke@greenbytes.de  2006-01-07 12:44 -------
As "DAV" now also is a request header, and we certainly changed semantics for
"If", I think we should re-register at least those. For consistency, I think
it's even better to register all. See changes below and in
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz086>:

Section 20., para. 1:
OLD:

    This specification defines two URI schemes:

NEW:

 20.1  URI Schemes
 
    This specification defines two URI schemes:


Section 20., para. 4:
OLD:

    XML namespaces disambiguate WebDAV property names and XML elements.
    Any WebDAV user or application can define a new namespace in order to
    create custom properties or extend WebDAV XML syntax.  IANA does not
    need to manage such namespaces, property names or element names.

NEW:

 20.2  XML Namespaces
 
    XML namespaces disambiguate WebDAV property names and XML elements.
    Any WebDAV user or application can define a new namespace in order to
    create custom properties or extend WebDAV XML syntax.  IANA does not
    need to manage such namespaces, property names or element names.


Section 21., para. 0:
NEW:

 20.3  Message Header Fields
 
    The message header fields below should be added to the permanent
    registry (see [RFC3864].
 
 20.3.1  DAV
 
    Header field name: DAV
 
    Applicable protocol: http
 
    Status: standard
 
    Author/Change controller: IETF
 
    Specification document: this specification (Section 9.1)
 
 20.3.2  DAV
 
    Header field name: DAV
 
    Applicable protocol: http

    Status: standard
 
    Author/Change controller: IETF
 
    Specification document: this specification (Section 9.2)
 
 20.3.3  Destination
 
    Header field name: Destination
 
    Applicable protocol: http
 
    Status: standard
 
    Author/Change controller: IETF
 
    Specification document: this specification (Section 9.3)
 
 20.3.4  If
 
    Header field name: If
 
    Applicable protocol: http
 
    Status: standard
 
    Author/Change controller: IETF
 
    Specification document: this specification (Section 9.4)
 
 20.3.5  Lock-Token
 
    Header field name: Lock-Token
 
    Applicable protocol: http
 
    Status: standard
 
    Author/Change controller: IETF
 
    Specification document: this specification (Section 9.5)
 
 20.3.6  Overwrite
 
    Header field name: Overwrite
 
    Applicable protocol: http
 
    Status: standard
 
    Author/Change controller: IETF
 
    Specification document: this specification (Section 9.6)
 
 20.3.7  Timeout
 
    Header field name: Timeout
 
    Applicable protocol: http
 
    Status: standard
 
    Author/Change controller: IETF
 
    Specification document: this specification (Section 9.7)
 

Section 22., para. 21:
NEW:

    [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
               Procedures for Message Header Fields", BCP 90, RFC 3864,
               September 2004.


(Re-assigning to Elias for follow-up)



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Saturday, 7 January 2006 20:44:34 UTC