RFC Errata
Found 3 records.
Status: Verified (1)
RFC 2817, "Upgrading to TLS Within HTTP/1.1", May 2000
Note: This RFC has been updated by RFC 7230, RFC 7231
Source of RFC: tls (sec)
Errata ID: 1801
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Nottingham
Date Reported: 2009-07-05
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18
Section 7.1 says:
Values to be added to this name space SHOULD be subject to review in the form of a standards track document within the IETF Applications Area. Any such document SHOULD be traceable through statuses of either 'Obsoletes' or 'Updates' to the Draft Standard for HTTP/1.1 [1].
It should say:
Values to be added to this name space are subject to IETF review
([12], Section 4.1).
(where [12] would refer to RFC 5226 in the References Section)
Notes:
Since RFC 2817 was published, it has become harder to publish non-WG
documents on the Standards Track. The "IETF review" policy is defined in
RFC 5226 as:
IETF Review - (Formerly called "IETF Consensus" in
[IANA-CONSIDERATIONS]) New values are assigned only through
RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The
intention is that the document and proposed assignment will
be reviewed by the IESG and appropriate IETF WGs (or
experts, if suitable working groups no longer exist) to
ensure that the proposed assignment will not negatively
impact interoperability or otherwise extend IETF protocols
in an inappropriate or damaging manner.
To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored (or WG)
documents with an IETF Last Call.
which should address this nicely.
Furthermore, overloading the "Updates" relation for specifications that
use a well-defined extension point plus an IANA registry is misleading.
Reviewed by the HTTPbis WG; see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/170>
Status: Held for Document Update (1)
RFC 2817, "Upgrading to TLS Within HTTP/1.1", May 2000
Note: This RFC has been updated by RFC 7230, RFC 7231
Source of RFC: tls (sec)
Errata ID: 4187
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Roy T. Fielding
Date Reported: 2014-11-20
Held for Document Update by: Stephen Farrell
Date Held: 2015-03-24
Section 7.2 says:
The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey
the production for 'product':
product = token ["/" product-version]
product-version = token
[...]
This specification defines the protocol token "TLS/1.0" as the
identifier for the protocol specified by The TLS Protocol [6].
It should say:
The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey
the production for 'product':
product = token ["/" product-version]
product-version = token
[...]
This specification defines the product token "TLS" as the
identifier for the protocol specified by The TLS Protocol [6].
When a specific version of TLS is desired, it is indicated by
appending a slash ("/") and the TLS version number as the
product-version (e.g., "TLS/1.0").
Notes:
This erratum clarifies that "TLS" is the product token and any TLS version number (currently DIGIT "." DIGIT) is the product-version token. This has already been corrected in the Upgrade Token Registry.
Status: Rejected (1)
RFC 2817, "Upgrading to TLS Within HTTP/1.1", May 2000
Note: This RFC has been updated by RFC 7230, RFC 7231
Source of RFC: tls (sec)
Errata ID: 3941
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florian Borchert
Date Reported: 2014-03-31
Rejected by: Stephen Farrell
Date Rejected: 2014-05-08
Section 3.1 says:
Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be supplied within a Connection header field (section 14.10)
It should say:
The hyperlink (http://tools.ietf.org/html/rfc2817#section-14.10) to section 14.10 does not work, it should refer to RFC2616: http://tools.ietf.org/html/rfc2616#section-14.42
Notes:
The hyperlink is an IETF tooling artefact and not part of the RFC, which is clear.
--VERIFIER NOTES--
The hyperlink is an IETF tooling artefact and not part of the RFC, which is clear.