RFC Errata
Found 2 records.
Status: Held for Document Update (1)
RFC 4229, "HTTP Header Field Registrations", December 2005
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 161
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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 GROUPArea Assignment: app
Errata ID: 837
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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