RFC Errata
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.