RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (3)

RFC 2045, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996

Note: This RFC has been updated by RFC 2184, RFC 2231, RFC 5335, RFC 6532

Source of RFC: 822ext (app)

Errata ID: 2586
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Christopher Yeleighton
Date Reported: 2010-10-28
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 1. says:

   All of the header fields defined in this document are subject to the
   general syntactic rules for header fields specified in RFC 822.  In
   particular, all of these header fields except for Content-Disposition
   can include RFC 822 comments, which have no semantic content and
   should be ignored during MIME processing.


It should say:

   All of the header fields defined in this document are subject to the
   general syntactic rules for header fields specified in RFC 822.  In
   particular, all of these header fields
   can include RFC 822 comments, which have no semantic content and
   should be ignored during MIME processing.


Notes:

A header field Content-Disposition is not defined in this document. Therefore, the header fields defined in this document do not contain a field Content-Disposition and the exception is not necessary. It is also misleading because it looks as if the exception affected the Content-Disposition field defined in RFC2813 while it does not.

Errata ID: 512
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ned Freed
Date Reported: 2005-02-24
Verifier Name: Alexey Melnikov
Date Verified: 2009-08-29

Section 5.1 says:

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="

It should say:

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <"> /
                   "/" / "[" / "]" / "?" / "="

Notes:

Missing alternative separator on the second line.

Errata ID: 7120
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Maciej Szumski
Date Reported: 2022-09-07
Verifier Name: RFC Editor
Date Verified: 2022-09-07

Section 2.4 says:

Note that this does NOT imply thay they have no meaning at all

It should say:

Note that this does NOT imply that they have no meaning at all

Notes:

Fixing a typo: 'thay' instead of 'that'.

Status: Held for Document Update (1)

RFC 2045, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996

Note: This RFC has been updated by RFC 2184, RFC 2231, RFC 5335, RFC 6532

Source of RFC: 822ext (app)

Errata ID: 3442
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Kwadronaut
Date Reported: 2013-01-03
Held for Document Update by: Barry Leiba
Date Held: 2013-01-03

Section 8. says:

   body is often desirable.  For example, it may be useful to mark an
   "image" body as "a picture of the Space Shuttle Endeavor."

It should say:

   body is often desirable.  For example, it may be useful to mark an
   "image" body as "a picture of the Space Shuttle Endeavour."

Notes:

That orbiter was called the Endeavour, little typo.

---
Verifier notes:
Little typo, indeed, and perhaps the draft's authors weren't aware of the NASA spelling. Still, little insignificant typos aren't what RFC errata are all about, so this goes in the "hold for document update" bin.

Status: Rejected (1)

RFC 2045, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996

Note: This RFC has been updated by RFC 2184, RFC 2231, RFC 5335, RFC 6532

Source of RFC: 822ext (app)

Errata ID: 3950
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Peter Occil
Date Reported: 2014-04-03
Rejected by: Barry Leiba
Date Rejected: 2014-04-03

Section 4 says:

   NOTE TO IMPLEMENTORS:  When checking MIME-Version values any RFC 822
   comment strings that are present must be ignored.  In particular, the
   following four MIME-Version fields are equivalent:

     MIME-Version: 1.0

     MIME-Version: 1.0 (produced by MetaSend Vx.x)

     MIME-Version: (produced by MetaSend Vx.x) 1.0

     MIME-Version: 1.(produced by MetaSend Vx.x)0

It should say:

   NOTE TO IMPLEMENTORS:  When checking MIME-Version values any RFC 822
   comment strings that are present must be ignored.  In particular, the
   following three MIME-Version fields are equivalent:

     MIME-Version: 1.0

     MIME-Version: 1.0 (produced by MetaSend Vx.x)

     MIME-Version: (produced by MetaSend Vx.x) 1.0

Notes:

Under RFC 822, a comment placed between two lexical symbols, in the case of the fourth example given, between the dot and the zero, is equivalent to a single space. Accordingly, the fourth example would result in the field "MIME-Version: 1. 0", which is not exactly equivalent to the previous three examples.
--VERIFIER NOTES--
It is exactly equivalent, because, while the lexical parsing puts a blank in, the parsing of the MIME-Version value then ignores the blank.

Report New Errata



Advanced Search