RFC Errata
Found 6 records.
Status: Verified (4)
RFC 2231, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", November 1997
Source of RFC: Legacy
Errata ID: 476
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2003-02-09
Section 4 says:
A single quote is used to separate the character set, language, and actual value information in the parameter value string, and an percent sign is used to flag octets encoded in hexadecimal.
It should say:
A single quote is used to separate the character set, language, and actual value information in the parameter value string, and a percent sign is used to flag octets encoded in hexadecimal.
Errata ID: 477
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Shuhei KOBAYASHI
Date Reported: 2001-04-17
Section 7 says:
extended-parameter := (extended-initial-name "="
extended-value) /
(extended-other-names "="
extended-other-values)
It should say:
extended-parameter := (extended-initial-name "="
extended-initial-value) /
(extended-other-names "="
extended-other-values)
Errata ID: 478
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Stedfast
Date Reported: 2001-11-24
Section 7 says:
encoded-word := "=?" charset ["*" language] "?" encoded-text "?="
It should say:
encoded-word := "=?" charset ["*" language] "?" encoding "?"
encoded-text "?="
Errata ID: 590
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Shuhei KOBAYASHI
Date Reported: 2001-04-17
Section 4.1 says:
Content-Type: application/x-stuff
title*0*=us-ascii'en'This%20is%20even%20more%20
title*1*=%2A%2A%2Afun%2A%2A%2A%20
title*2="isn't it!"
It should say:
Content-Type: application/x-stuff;
title*0*=us-ascii'en'This%20is%20even%20more%20;
title*1*=%2A%2A%2Afun%2A%2A%2A%20;
title*2="isn't it!"
Status: Reported (1)
RFC 2231, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", November 1997
Source of RFC: Legacy
Errata ID: 5701
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Freeman
Date Reported: 2019-04-19
Section 7 says:
regular-parameter-name := attribute [section]
It should say:
regular-parameter-name := attribute
Notes:
It seems to me that there is no need for a [section] value to be appended to a regular-parameter-name, and that the existing rule that allows for this violates the intent of the text in Section 3 that states "The asterisk character ("*") followed by a decimal count is employed to indicate that multiple parameters are being used to encapsulate a single parameter value". With the existing rule, it is unclear how to treat the [section] value in this case. (e.g., Is it to be considered as part of the attribute name, or is it to be ignored?)
Status: Held for Document Update (1)
RFC 2231, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", November 1997
Source of RFC: Legacy
Errata ID: 3269
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2012-06-28
Held for Document Update by: Barry Leiba
Section 3 says:
(2) the mechanism MUST NOT depend on parameter ordering
since MIME states that parameters are not order
sensitive. Note that while MIME does prohibit
modification of MIME headers during transport, it is
still possible that parameters will be reordered when
user agent level processing is done.
It should say:
(2) the mechanism MUST NOT depend on parameter ordering
since MIME states that parameters are not order
sensitive. Note that while MIME does prohibit
modification of MIME headers during transport, it is
still possible that parameters will be reordered when
user agent level processing is done.
(3) the mechanism MUST NOT alter parameter values that are
critical to existing MIME processors. This specifically includes
the "boundary" parameter for multipart types and the "charset"
parameter for text types.
Notes:
Earlier text in the section states "Any such mechanism MUST be compatible with existing MIME processors." The addition of a 3rd item clarifies an additional behavior that is necessary to achieve that requirement. It is a flaw in the RFC 2231 standard if it creates a message format that can not be processed by an RFC 2045 processor but can be processed by an RFC-2045-as-extended-by-2231 processor. I have seen a 2231 split boundary marker in the wild so this elaboration on the existing MUST appears to be necessary.
Note that I do not object if this errata is marked "hold for document update".