RFC Errata
Found 7 records.
Status: Verified (7)
RFC 5322, "Internet Message Format", October 2008
Note: This RFC has been updated by RFC 6854
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 1905
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wolf Lammen
Date Reported: 2009-10-09
Verifier Name: Pete Resnick
Date Verified: 2011-06-11
Section 4.1 says:
obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
It should say:
obs-unstruct = *( (*CR 1*(obs-utext / FWS)) / 1*LF ) *CR
Notes:
It looks to me, as if the rule for obs-unstruct matches any US_ASCII character sequence, and is, hence, either overly complicated, or simply wrong. For example: CR LF 'A' is matched by the original rule (loop matches CR first, then LF 'A'). If I understand the accompaying text right, the intention was to allow for reversed sequences LF CR, as well as bare CR and LF sequences, but strictly forbid any occurrence of CR LF (in that order). This would be expressed by my rule, that basically states that any sequence of CR either is at the end, or is followed by a non-LF, or an FWS
[Alexey: removed unchanged ABNF rules, corrected an obvious error in the description of the change.]
Errata ID: 1908
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wolf Lammen
Date Reported: 2009-10-11
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-24
Section 4.2 says:
In the obsolete syntax, any amount of folding white space MAY be inserted where the obs-FWS rule is allowed. This creates the possibility of having two consecutive "folds" in a line, and therefore the possibility that a line which makes up a folded header field could be composed entirely of white space. obs-FWS = 1*WSP *(CRLF 1*WSP)
It should say:
In the obsolete syntax, any amount of folding white space MAY be inserted where the obs-FWS rule is allowed. This creates the possibility of having two consecutive "folds" in a line, and therefore the possibility that a line which makes up a folded header field could be composed entirely of white space. obs-FWS = 1*([CRLF] WSP)
Notes:
If I understand the relevant portions of RFC 822 right (notably section 3.1.1
["The general rule is that wherever there may be linear-white-space...
a CRLF followed by ... LWSP-char(s) may instead be inserted"], along with
section 3.1.4, section 3.3), it is permitted to extend a phrase
atom SPACE atom
by inserting linear-white-space (CRLF SPACE CRLF SPACE) instead, yielding:
atom CRLF SPACE CRLF SPACE atom
However, this is not recognized by the rules of RFC 5322, because the new
syntax forbids consecutive foldings, whereas obs-FWS requires a leading
white-space character at the beginning.
Errata ID: 3979
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2014-04-30
Verifier Name: Pete Resnick
Date Verified: 2014-04-30
Section 3.6.7; 4.5.7 says:
received = "Received:" *received-token ";" date-time CRLF obs-received = "Received" *WSP ":" *received-token CRLF
It should say:
received = "Received:" [1*received-token / CFWS]
";" date-time CRLF
obs-received = "Received" *WSP ":" [1*received-token / CFWS] CRLF
Notes:
"The 'Received:' field contains a (possibly empty) list of tokens followed by a semicolon and a date-time specification." As it was originally written, though, whitespace and comments are disallowed right after the colon if the list of tokens is empty: for example, the header field "Received: ; Wed, 30 Apr 2014 00:00:00 -0000\r\n" (with a space after the first colon) would be invalid according to the current spec; only "Received:; Wed, 30 Apr 2014 00:00:00 -0000\r\n" (without a space) would be.
Verifier note: The erratum is clearly correct. There are other possible ABNF solutions, but the one above is sufficient to fix the problem.
Errata ID: 1766
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nick Levinson
Date Reported: 2009-04-16
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-24
Section 3.4.1 says:
If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext characters), then the dot-atom form SHOULD be used and the quoted- string form SHOULD NOT be used.
It should say:
If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or one or more of "." surrounded by atext characters), then the dot-atom form SHOULD be used and the quoted-string form SHOULD NOT be used.
Notes:
Based on sec. 3.2.3 ("dot-atom = [CFWS] dot-atom-text [CFWS]" (brackets so in original) & "dot-atom-text = 1*atext *('.' 1*atext)") and on appx. A.1.2 (the example "john.q.public@example.com").
Errata ID: 2515
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Rushton
Date Reported: 2010-09-10
Verifier Name: Pete Resnick
Date Verified: 2011-05-16
Section Appendix A.5 says:
From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
It should say:
From: Pete(A nice \) chap) <pete@silly.test(his host)>
Notes:
Section 3.4.1: "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."
Errata ID: 2579
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominic Sayers
Date Reported: 2010-10-18
Verifier Name: Pete Resnick
Date Verified: 2011-05-16
Section Appendix A.5 says:
To:A Group(Some people)
:Chris Jones <c@(Chris's host.)public.example>,
joe@example.org,
John <jdoe@one.test> (my dear friend); (the end of the group)
It should say:
To:A Group(Some people)
:Chris Jones <c@public.example(Chris's host.)>,
joe@example.org,
John <jdoe@one.test> (my dear friend); (the end of the group)
Notes:
Section 3.4.1: "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."
Errata ID: 6920
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2022-04-05
Verifier Name: Orie Steele
Date Verified: 2024-04-01
Section 2.1 says:
and interpreted as US-ASCII [ANSI.X3-4.1986] characters. For brevity, this document sometimes refers to this range of characters as simply "US-ASCII characters".
It should say:
and interpreted as ASCII [ANSI.X3-4.1986] characters. For brevity, this document sometimes refers to this range of characters as simply "ASCII characters".
Notes:
The choice of "US-ASCII" as a charset name reflected circumstances at the time, but it was not then and has never been the name of a coded character set, much less the one specified in the various versions of what is now ANSI INCITS 4-1986[R2017]. The common name of the latter, both specified in the Standard and in common practice, is "ASCII" without any further qualification. "For brevity", "ASCII" is not only more accurate, but shorter. While the correction is being made, it would be wise to change the citation anchor to "[ASCII]" or, if necessary for some reason, "[ASCII1986]". The odd punctuation used in "[ANSI.X3-4.1986]" to refer to ANSI X3.4-1986 is just unnecessarily confusing.
(this erratum is being reported more or less at the request of the editor of RFC 5322 and its successor)