RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search