RFC Errata
Found 4 records.
Status: Verified (3)
RFC 2183, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", August 1997
Note: This RFC has been updated by RFC 2184, RFC 2231
Source of RFC: Legacy
Errata ID: 485
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-05
Section 2 says:
NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
It should say:
NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)
Errata ID: 1457
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2008-06-20
Verifier Name: Lisa Dusseault
Date Verified: 2008-10-06
Section Boilerplate says:
Network Working Group R. Troost
Request for Comments: 2183 New Century Systems
Updates: 1806 S. Dorner
Category: Standards Track QUALCOMM Incorporated
K. Moore, Editor
University of Tennessee
August 1997
It should say:
Network Working Group R. Troost
Request for Comments: 2183 New Century Systems
Obsoletes: 1806 S. Dorner
Category: Standards Track QUALCOMM Incorporated
K. Moore, Editor
University of Tennessee
August 1997
Notes:
RFC 2183 completely replaces RFC 1806, so it should say "obsoletes" instead of "updates".
Errata ID: 3847
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Reitmaier
Date Reported: 2013-12-23
Verifier Name: Barry Leiba
Date Verified: 2013-12-23
Section 3 says:
Content-Type: image/jpeg
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
Content-Description: a complete map of the human genome
It should say:
Content-Type: image/jpeg
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 Feb 1997 16:29:51 -0500"
Content-Description: a complete map of the human genome
Notes:
In section 2 it states:
disposition := "Content-Disposition" ":"
disposition-type
*(";" disposition-parm)
The semicolon should not be at the end of a header field.
And in the example there is a semicolon behind the disposition-parm "modification-date".
Status: Reported (1)
RFC 2183, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", August 1997
Note: This RFC has been updated by RFC 2184, RFC 2231
Source of RFC: Legacy
Errata ID: 5330
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Beardsmore
Date Reported: 2018-04-20
Section 2 says:
NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters) parameter value containing only non-`tspecials' characters SHOULD be represented as a single `token'. A short parameter value containing only ASCII characters, but including `tspecials' characters, SHOULD be represented as `quoted-string'. Parameter values longer than 78 characters, or which contain non-ASCII characters, MUST be encoded as specified in [RFC 2184].
It should say:
NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters) parameter value formed solely from characters valid for a `token' SHOULD be represented as a single `token', and not as a `quoted-string'. Parameter values longer than 78 characters, or which contain non-ASCII characters, MUST be encoded as specified in [RFC 2184].
Notes:
The RFC seems to assume that token = ASCII - tspecials. Token in fact is defined more strictly: token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials>.
Consequently, a value with spaces (such as "Some file.txt"), which is a value without any tspecials, is expected to be recorded as a token, when in fact this is impossible. The same applies to CTLs.
I've written the corrected text according to the apparent intent, to avoid quotes around the value when they are unnecessary. You may wish to revise the correction for clarity or to better suit the intent of this restriction.