RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 13 records.

Status: Verified (10)

RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996

Note: This RFC has been updated by RFC 2646, RFC 3798, RFC 5147, RFC 6657, RFC 8098

Source of RFC: 822ext (app)

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

Reported By: Bruce Lilly
Date Reported: 2003-10-04

Section 5.1.5 says:

      Date: Mon, 22 Mar 1994 13:34:51 +0000

It should say:

      Date: Tue, 22 Mar 1994 13:34:51 +0000 

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

Reported By: Herman Meerlo
Date Reported: 2001-10-04

Appendix A states:

     discard-text := *(*text CRLF)

It should say:

     discard-text := *(*text CRLF) *text

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

Reported By: Bruce Lilly
Date Reported: 2001-12-22

Section 5.2.2.2 says:

Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail
Message-ID: <anotherid@foo.com>

It should say:

Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Message-ID: <anotherid@foo.com>
Subject: Audio mail

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

Reported By: Bruce Lilly
Date Reported: 2001-12-22

Section 5.2.3.7 says:

Content-Type: message/external-body;
              access-type=mail-server
              server="listserv@bogus.bitnet";
              expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

It should say:

Content-Type: message/external-body;
              access-type=mail-server;
              server="listserv@bogus.bitnet";
              expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Notes:

Semicolons were missing.

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

Reported By: Daniel Shahaf
Date Reported: 2021-12-27
Verifier Name: Orie Steele
Date Verified: 2024-05-03

Section 5.1.4 says:

                                    In the case where one of the
   alternatives is itself of type "multipart" and contains unrecognized
   sub-parts, the user agent may choose either to show that alternative,
   an earlier alternative, or both.


It should say:

                                    In the case where one of the
   alternatives is itself of type "multipart" and contains unrecognized
   sub-parts, the user agent may choose to either show that alternative,
   show an earlier alternative, or let the user choose which alternative
   to show.

Notes:

The quoted sentence conflicts with the following sentence later in the same section:

What is most critical, however, is that the user not
automatically be shown multiple versions of the same data. Either
the user should be shown the last recognized version or should be
given the choice.

I assume the correction should be as proposed, but other options are conceivable.

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

Reported By: Steve Bellovin
Date Reported: 2004-02-03

Section 9 says:

9.  Security Considerations

It should say:

8.  Security Considerations

Notes:

In the Table of Contents, the Security Considerations is listed to be in Section 8. However, in the text, both the Security Considerations and Authors' Addresses are in Section 9; there is no Section 8.

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

Reported By: Bruce Lilly
Date Reported: 2001-12-22

Section 5.1.5 says:

undesireble 

seperate

It should say:

undesirable

separate

Notes:

Spelling errors.

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

Reported By: Lars Kasper
Date Reported: 2005-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2009-08-29

Section 3 says:

    (2)   image -- image data.  "Image" requires a display device
          (such as a graphical display, a graphics printer, or a
          FAX machine) to view the information. An initial
          subtype is defined for the widely-used image format
          JPEG. .  subtypes are defined for two widely-used image
          formats, jpeg and gif.

It should say:

    (2)   image -- image data.  "Image" requires a display device
          (such as a graphical display, a graphics printer, or a
          FAX machine) to view the information. Subtypes are defined
          for two widely-used image formats, jpeg and gif.

Notes:

The sentence previous to the last should be deleted, as it is covered by the last sentence.

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

Reported By: ojab
Date Reported: 2021-05-15
Verifier Name: RFC Editor
Date Verified: 2024-01-16

Section 4.1.4 says:

Unrecognized subtypes which also specify an unrecognized charset 
should be treated as "application/octet- stream".

It should say:

Unrecognized subtypes which also specify an unrecognized charset 
should be treated as "application/octet-stream".

Notes:

Extra space in "application/octet- stream"

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

Reported By: Viatrix
Date Reported: 2023-02-07
Verifier Name: RFC Editor
Date Verified: 2023-02-07

Section 5.2.3.7 says:

provided in the same format but via different accces mechanisms.

It should say:

provided in the same format but via different access mechanisms.

Notes:

"accces" is a typo

Status: Held for Document Update (2)

RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996

Note: This RFC has been updated by RFC 2646, RFC 3798, RFC 5147, RFC 6657, RFC 8098

Source of RFC: 822ext (app)

Errata ID: 6776
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Brian Antos
Date Reported: 2021-12-05
Held for Document Update by: Orie Steele
Date Held: 2024-05-03

Section 5.1.1 says:

NOTE:  The CRLF preceding the boundary delimiter line is conceptually
   attached to the boundary so that it is possible to have a part that
   does not end with a CRLF (line  break).  Body parts that must be
   considered to end with line breaks, therefore, must have two CRLFs
   preceding the boundary delimiter line, the first of which is part of
   the preceding body part, and the second of which is part of the
   encapsulation boundary.

It should say:

NOTE:  The CRLF preceding the boundary delimiter line is conceptually
   attached to the boundary so that it is possible to have a part that
   does not end with a CRLF (line  break).  Body parts that must be
   considered to end with line breaks, therefore, must have two CRLFs
   preceding the boundary delimiter line, the first of which is part of
   the preceding body part, and the second of which is part of the
   encapsulation boundary.

The requirement that the encapsulation boundary begins  with
a  CRLF  implies  that  the  body of a multipart entity must
itself begin with a CRLF before the first encapsulation line
--  that  is, if the "preamble" area is not used, the entity
headers must be followed by TWO CRLFs.  This is  indeed  how
such  entities  should be composed.  A tolerant mail reading
program, however, may interpret a  body  of  type  multipart
that  begins  with  an encapsulation line NOT initiated by a
CRLF  as  also  being  an  encapsulation  boundary,  but   a
compliant  mail  sending  program  must  not  generate  such
entities.

Notes:

Recommend re-introducing the wording from the original RFC (1341) regarding preceding CRLF and the first delimiter line. Current RFC is ambiguous about handling the initial line without it.

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

Reported By: Oleg Andriyanov
Date Reported: 2016-02-01
Held for Document Update by: Barry Leiba
Date Held: 2016-02-02

Section 3 says:

          particular, formats that employ embeddded binary

It should say:

          particular, formats that employ embedded binary

Notes:

"embeddded" has triple "d".

Status: Rejected (1)

RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996

Note: This RFC has been updated by RFC 2646, RFC 3798, RFC 5147, RFC 6657, RFC 8098

Source of RFC: 822ext (app)

Errata ID: 6583
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: ojab
Date Reported: 2021-05-15
Rejected by: RFC Editor
Date Rejected: 2024-02-15

Section 5.1.2 says:

It is essential that such entities be handled correctly when they are
themselves imbedded inside of another "multipart" structure.

It should say:

It is essential that such entities be handled correctly when they are 
themselves embedded inside of another "multipart" structure.

Notes:

`imbedded` is a typo
--VERIFIER NOTES--
“Imbed” is a less common spelling of “embed” (see https://www.merriam-webster.com/dictionary/imbed). It is used in a number of early RFCs (e.g., RFCs 549, 1035, 1258, 1580, 1689, 2567, 3423, and more). It was last used in RFC 5045. Since then, “embed” has been used in the RFC Series.

Report New Errata



Advanced Search