Subject: [Bug 86] DAV header definitions should use RFC3864 templates

From: [email-masked]
Date: Sat, 7 Jan 2006 12:44:29 -0800

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

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         [email-masked][email-masked]

------- Additional Comments From [email-masked]  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.