RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Held for Document Update (1)

RFC 4229, "HTTP Header Field Registrations", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 161

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Alexey Melnikov
Report Text:


Reference tags for RFC 2109 [5] should be replaced by reference tags for RFC 2965 [15].

Rationale:
RFC 2109 [5] has been obsoleted by RFC 2965 [15], and the latter
apparently contains the current specification for the Set-Cookie
(and the Set-Cookie2) Header Field.

Nevertheless, the registration for 'Set-Cookie' in Subsection
2.1.96 of RFC 4229 (on page 36) refers to RFC 2109 [5] as the
normative Specification document.

I suspect that this particular Registration should be updated
immediately to point to RFC 2965 [15] .


Status: Rejected (1)

RFC 4229, "HTTP Header Field Registrations", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 837

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Rejected by: Peter Saint-Andre
Date Rejected: 2011-05-16

 

(2)

RFC 2068 [4] has been obsoleted by RFC 2616 [11], and the latter
purposely has omitted a few elements of HTTP from the former
specification because of "detected problems" and/or "lack of
implementation" -- cf. Section 19.6 of RFC 2616.
Thus, there is no more current specification for these elements.
According to my understanding that means that these elements
effectively have been deprecated by RFC 2616.

Among those (deprecated) elements of HTTP 1.1 are the HTTP Header
Fields:
         -  Content-Base
         -  Content-Version
         -  Derived-From
         -  Keep-Alive
         -  Link
         -  Public
         -  URI

As expected, the Registrations for these HTTP Header Fields, as
presented in RFC 4229, consistently all refer to RFC 2068 [4] as
the (obsolete) 'Specification document' -- but, very surprisingly,
the registered 'Status' entries for these Header Fields all contain:
"standard" instead of "deprecated".

According to my understanding of IETF procedures, a feature or
protocol element must not be named "standard" if its specification
has been officially obsoleted / deprecated by a Standards Track RFC.

Hence, IMHO the IANA Registrations for the above mentioned HTTP
Header Fields (Subsections 2.1.{21,33,41,59,62,89,108} of RFC 4229
should be immediately corrected to contain 'Status: deprecated".

It should say:

[see above]

Notes:

(Note: A status of "deprecated" still allows standards conformant
implementations to implement any such feature or protocol element
for the sake of backwards compatibility!)
--VERIFIER NOTES--
This is not an appropriate subject for an erratum.
Please take this up with the IANA or, better yet,
write an Internet-Draft. --Peter Saint-Andre

Report New Errata



Search RFCs
Advanced Search
×