RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (2)

RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996

Source of RFC: 822ext (app)

Errata ID: 504

Status: Verified
Type: Technical

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

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: Reported (1)

RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996

Source of RFC: 822ext (app)

Errata ID: 4913

Status: Reported
Type: Editorial

Reported By: John Drinkwater
Date Reported: 2017-01-19

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.

Status: Held for Document Update (1)

RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996

Source of RFC: 822ext (app)

Errata ID: 2823

Status: Held for Document Update
Type: Editorial

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.

Status: Rejected (1)

RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996

Source of RFC: 822ext (app)

Errata ID: 3749

Status: Rejected
Type: Technical

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