RFC Errata
Found 7 records.
Status: Verified (2)
RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996
Note: This RFC has been updated by RFC 2184, RFC 2231
Source of RFC: 822ext (app)
Errata ID: 504
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jose M. Cainzos
Date Reported: 2001-11-10
Section 5 says:
(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC
822 ABNF definition for 'comment' is amended as follows:
comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
contain the characters "(", ")" or "
'encoded-word' that appears in a 'comment' MUST be separated from
any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.
It should say:
(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC
822 ABNF definition for 'comment' is amended as follows:
comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
contain the characters "(", ")" or "\". In addition, an
'encoded-word' that appears in a 'comment' MUST be separated from
any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.
Errata ID: 506
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2003-02-13
Section 2 says:
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="
It should say:
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
<"> / "/" / "[" / "]" / "?" / "." / "="
Notes:
Also reported by Jon Steinhart 2002-01-17, but corrected by Bruce Lilly.
Status: Held for Document Update (4)
RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996
Note: This RFC has been updated by RFC 2184, RFC 2231
Source of RFC: 822ext (app)
Errata ID: 5469
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-08-17
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30
Section 5 says:
In this case the set of characters that may be used in a "Q"-encoded
'encoded-word' is restricted to: <upper and lower case ASCII
letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_"
(underscore, ASCII 95.)>
It should say:
In this case the set of characters that may be used in a "Q"-encoded 'encoded-text' is restricted to: <upper and lower case ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=" (only if followed by two hexadecimal digits), and "_" (underscore, ASCII 95.)>
Notes:
This sentence discusses the use of encoded words within a phrase. However, the original text is wrong in at least two ways:
1. The production "encoded-word" also allows "?" to appear, as well as characters allowed in MIME "token"s.
2. Even in the "encoded-text" portion the "=" sign can't appear freely in Q-encoding, but must be followed by two hexadecimal characters (as stated later in section 5).
The correction given here changes "encoded-word" to "encoded-text" and adds text restricting where "=" can appear. Another plausible correction would be to add "?" and the other characters allowed in "tokens" (and leave the text "'q'-encoded 'encoded-word'" alone), but that would interfere with later RFCs, notably RFC 2231, that restrict the syntax of the charset component of encoded-words.
Errata ID: 2823
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Spiros Bousbouras
Date Reported: 2011-06-05
Held for Document Update by: Pete Resnick
Date Held: 2011-06-05
Section 8 says:
The following examples illustrate how text containing 'encoded-word's which appear in a structured field body.
It should say:
The following examples illustrate how text containing 'encoded-word's appears in a structured field body.
Errata ID: 4913
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Drinkwater
Date Reported: 2017-01-19
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30
Section 8 says:
Any amount of linear-space-white between 'encoded-word's,
even if it includes a CRLF followed by one or more SPACEs,
is ignored for the purposes of display.
It should say:
Any amount of linear-white-space between 'encoded-word's,
even if it includes a CRLF followed by one or more SPACEs,
is ignored for the purposes of display.
Errata ID: 5692
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2019-04-14
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30
Section Appendix says:
+ explicitly state that the MIME-Version is not requried to use
'encoded-word's.
It should say:
+ explicitly state that the MIME-Version is not required to use
'encoded-word's.
Notes:
a minor spelling mistake
Status: Rejected (1)
RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996
Note: This RFC has been updated by RFC 2184, RFC 2231
Source of RFC: 822ext (app)
Errata ID: 3749
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alec H. Peterson
Date Reported: 2013-10-11
Rejected by: Barry Leiba
Date Rejected: 2013-10-26
Section 2 says:
An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used.
It should say:
An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used. Multiple encoded words MAY exist on a single line, in that event a SPACE MUST separate the encoded words, and after decoding the SPACE is not rendered.
Notes:
Section 2 makes no mention of multiple encoded words per line, or how to handle it. However, the example at the end specifically illustrates what should happen (section 8)
(=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b)
In order to cause a SPACE to be displayed between two strings
of encoded text, the SPACE MAY be encoded as part of one of
the 'encoded-word's.
--VERIFIER NOTES--
<<
I think I just hadn't fully digested the whole RFC. I was just re-reading the RFC in working to come up with the proposed change, and then I saw this in section 6.2:
When displaying a particular header field that contains multiple
'encoded-word's, any 'linear-white-space' that separates a pair of
adjacent 'encoded-word's is ignored. (This is to allow the use of
multiple 'encoded-word's to represent long strings of unencoded text,
without having to separate 'encoded-word's where spaces occur in the
unencoded text.)
>>
So the RFC is correct as it stands. The text in section 2 is specifically talking about multiple encoded-words on multiple lines. Section 6.2 covers the other case.