RFC Errata
Found 29 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)
Status: Reported (4)
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: 5918
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcus Bointon
Date Reported: 2019-11-26
Section 2.2 says:
Header fields are lines beginning with a field name, followed by a
colon (":"), followed by a field body, and terminated by CRLF. A
field name MUST be composed of printable US-ASCII characters (i.e.,
characters that have values between 33 and 126, inclusive), except
colon.
Notes:
I'm reporting an omission rather than a correction. The description of field names in S2.2 does not describe any length limit, but it implicitly prohibits folding by not permitting WSP chars in the name. 3.6.8 defines an ABNF for field-name, but does not specify a length limit either.
As far as I can see this means that field names should be limited to 77 characters – the field name and a trailing : – after which the field body can start after FWS on the next line.
I suspect this will be open to some debate, so I'm not sure what to suggest as a correction beyond that. Nor do I know whether common clients & servers impose their own arbitrary limits on field names.
Errata ID: 6639
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brennan Vincent
Date Reported: 2021-07-12
Section 3.3 says:
zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
It should say:
zone = (FWS ( "+" / "-" ) 4DIGIT) / [FWS] obs-zone
Notes:
The current syntax does not allow space before an obs-zone. Thus, it rejects header items like:
Date: Mon, 12 Jul 2021 18:32:01 GMT
which are still being produced today by, for example, mail(1) on FreeBSD.
Errata ID: 6921
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2022-04-05
Section 2.1 says:
composed of characters with values in the range of 1 through 127 and interpreted as US-ASCII [ANSI.X3-4.1986] characters.
It should say:
composed of ASCII characters [RFC20] with values in the range from 0/1 to 7/15. --OR-- composed of octets with decimal values in the range from 1 through 127 and interpreted as US-ASCII [ANSI.X3-4.1986] characters.
Notes:
See previous erratum about "US-ASCII" versus "ASCII" or "RFC20" and apply as needed to the suggested text.
While there are several ways to fix the problem being reported here, the "range of 1 through 127" has no meaning without some qualification as to what the numbers mean. One could infer from the original form that the range is interpreted according to something in the standard, but that standard, unlike, e.g., Unicode, never uses a linear sequence of numbers to refer to code points, only the Column/Row notation shown above (plus, of course, the actual seven-bit binary coding).
Errata ID: 7382
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Paolo Schiro
Date Reported: 2023-03-11
Section 3.2.3 says:
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
It should say:
ccontent = ctext / quoted-pair
comment = "(" *([FWS] ccontent) [FWS] ")"
Notes:
Trying to getting all possible originator formats a reader can get stuck into a circular dependency between "comment" and "ccontent" definitions.
Since "ccontent" is referenced in the "comment" definition only circular dependency should be cut there I suppose.
Status: Held for Document Update (8)
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: 1906
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Wolf Lammen
Date Reported: 2009-10-10
Held for Document Update by: Pete Resnick
Date Held: 2010-04-02
Section 4.1 says:
obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
It should say:
obs-body = *(%d0-127)
Notes:
The regular expression for obs-body is overly complex and can be simplified as suggested. Alternatively, one could use
*(d0 /text / LF / CR)
should the difference to 'text' be emphazised.
[Alexey: I've edited this to only show 1 issue per erratum.]
Errata ID: 2950
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Antonio Regidor García
Date Reported: 2011-08-30
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13
Section 3.6 says:
fields = *(trace
*optional-field /
*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)
It should say:
fields = *(trace
*optional-field /
1*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)
Notes:
The original version causes an infinite loop (matching an infinite list of empty strings).
Errata ID: 3135
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ashley Willis
Date Reported: 2012-02-25
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13
Section 3.2.4 says:
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
It should say:
quoted-string = [CFWS]
DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
[CFWS]
Notes:
The text following this definition states that a "quoted-string is identical to atom, semantically." "Semantically, neither the optional CFWS outside of the quote characters nor the quote characters themselves are part of the quoted-string; the quoted-string is what is contained between the two quote characters."
The published definition allows, for example, an angle-addr of <""@ietf.org> which is equivalent to <@ietf.org>, hence invalid. The corrected definition ensures that at a minimum there is one FWS or qcontent between each DQUOTE.
Currently allowed yet invalid: <""@ietf.org>, <foo.""@ietf.org>, <"".bar@ietf.org>, and <foo."".bar@ietf.org>.
As a quoted-string must be bound by the ends of the local-part or by a dot, there is no change in regard to the currently invalid addresses such as <foo""@ietf.org>, <""bar@ietf.org>, and <foo""bar@ietf.org>.
Errata ID: 4692
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Oleg Andriyanov
Date Reported: 2016-05-13
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30
Section 3.2.4 says:
qtext = %d33 / ; Printable US-ASCII
%d35-91 / ; characters not including
%d93-126 / ; "\" or the quote character
obs-qtext
It should say:
qtext = %d32 / ; Printable US-ASCII
%d33 / ; characters not including
%d35-91 / ; "\" or the quote character
%d93-126 /
obs-qtext
Notes:
According to the Open Group's definition of the "print" class of characters in a locale [1], the SPACE character (%d32) is printable as well. So either it should be included in the "qtext" definition or the comment should state explicitly that it is excluded from "qtext" along with backslash and double quote.
[1]: pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html
----- Verifier notes -----
There are many places in the document that refer to "printable US-ASCII characters", and it's clear from the context of them that SPACE was not included there. This issue does need to be looked at when we revise this document to advance it to Internet Standard.
Errata ID: 5867
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Pete Resnick
Date Reported: 2019-10-01
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13
Section 4.5.7 says:
obs-received = "Received" *WSP ":" *received-token CRLF
It should say:
obs-received = "Received" *WSP ":"
[1*received-token / CFWS] [ ";" date-time CRLF ]
Notes:
Erratum 3979 already describes that CFWS should be allowed in an otherwise empty list of received-tokens. This adds an optional date-time after that.
Errata ID: 5905
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Edward Welbourne
Date Reported: 2019-11-13
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13
Section 3.3 says:
The time-of-day specifies the number of hours, minutes, and optionally seconds since midnight of the date indicated. The date and time-of-day SHOULD express local time.
It should say:
The time-of-day specifies the number of hours, minutes, and optionally seconds since midnight of the date indicated or, when a time-zone transition has intervened in the interval, since the nominal midnight of the zone now in effect. The date and time-of-day SHOULD express local time.
Notes:
The problem with the original text is its reading on the day of a time-zone transition.
For example, if the hour from 02:00 to 03:00 was repeated (a fall-back, as at the end of DST), then what local time refers to as 04:00 is 5 hours after midnight "of the date indicated" and what local time refers to as 23:59 is almost 25 hours after midnight. Likewise, if an hour early in the day has been skipped (a spring-forward, as at the start of DST), the time since midnight is one hour short of the local time, as normally understood; for example, 23:00 is only 22 hours after midnight.
There are zones in which transitions happen at midnight, for which 01:00 is midnight on a relevant day: at the other end of the year, there may then be a day that repeats 00:00, so may be argued to have two midnights (with a rather literal "midnight hour" in between).
I cannot think of a good replacement text, sad to say, but I have tried my (painfully verbose) best. I assume everyone has always just used the conventional meaning of local time (as per the SHOULD in the paragraph I haven't changed), without worrying about the inaccurate "since midnight" phrasing.
Errata ID: 2726
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Finch
Date Reported: 2011-02-21
Held for Document Update by: Pete Resnick
Section 3.3 says:
The zone specifies the offset from Coordinated Universal Time (UTC, formerly referred to as "Greenwich Mean Time") that the date and time-of-day represent. The "+" or "-" indicates whether the time-of- day is ahead of (i.e., east of) or behind (i.e., west of) Universal Time. The first two digits indicate the number of hours difference from Universal Time, and the last two digits indicate the number of additional minutes difference from Universal Time. (Hence, +hhmm means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) minutes). The form "+0000" SHOULD be used to indicate a time zone at Universal Time. Though "-0000" also indicates Universal Time, it is used to indicate that the time was generated on a system that may be in a local time zone other than Universal Time and that the date-time contains no information about the local time zone.
It should say:
The zone specifies the offset from Coordinated Universal Time (UTC) that the date and time-of-day represent. The "+" or "-" indicates whether the time-of- day is ahead of (i.e., east of) or behind (i.e., west of) UTC. The first two digits indicate the number of hours difference from UTC, and the last two digits indicate the number of additional minutes difference from UTC. (Hence, +hhmm means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) minutes). The form "+0000" SHOULD be used to indicate a time zone at UTC. Though "-0000" also indicates UTC, it is used to indicate that the time was generated on a system that may be in a local time zone other than UTC and that the date-time contains no information about the local time zone.
Notes:
It is not correct to say that UTC was formerly referred to as GMT. I think this was an editorial mistake: RFC 822 did not use the term UTC and said "Universal Time (formerly called Greenwich Mean Time)" which is reasonably correct for UT without a suffix.
For the purposes of RFC 5322 and for consistency with RFC 3339 and ISO 8601 I think it is best to refer to UTC throughout - though see the next erratum for notes on the obsolete syntax.
Errata ID: 3048
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pan GaoYong
Date Reported: 2011-12-08
Held for Document Update by: Pete Resnick
Date Held: 2011-12-29
Section 3.6.6. Rese says:
When resent fields are used, the "Resent-From:" and "Resent-Date:" fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.
It should say:
When resent fields are used, the "Resent-From:" and "Resent-Date:" fields MUST be set. The "Resent-Message-ID:" field SHOULD be set.
Notes:
[Verifier note: The original report only noted the second use of the word "sent". I have updated to include both. I have marked as "Hold" because (a) I believe the meaning is clear in the current and (b) it is not obvious that "set" is the correct word here; perhaps "used" is better. Left for an editing pass when this moves to Standard.]
Status: Rejected (10)
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: 2104
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Wolf Lammen
Date Reported: 2010-04-02
Rejected by: Pete Resnick
Date Rejected: 2011-06-11
Section 4.1 says:
obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
It should say:
obs-unstruct = *(*LF *CR (obs-utext / FWS)) *LF *CR
;The CR of a following CRLF MUST NOT be consumed.
Notes:
[I was notified, that errata report 1766 and 1908 has been verified, but apparently, report 1905 was left undecided. I am a bit concerned, because this report points to a true defect of RFC 5322, so, maybe, a clearer reasoning helps. This report is meant to replace my former posting 1905.]
The <obs-unstruct> rule covers field bodies of unstructured fields (as declared in section 2.2.1), that conform to obsoleted RFC 2822 or RFC 822. It is only to be used for downward compatibility when reading messages. It corresponds to <text> in RFC 822 and <obs-utext> in RFC 2822. In a conforming message, an unstructured field body is always followed by a field delimiting non-folding CRLF.
<obs-unstruct> is equivalent to *(d0-d127), so the CRLF delimiting the field is made part of the field body, as is the rest of the header section.
So my proposal refines the rule: Use any, possibly empty, sequence of ASCII characters, as long as it does not contain a CRLF outside of a folding white space.
There is a nuisance left: when applied possessively, the CR of the adjacent field delimiter CRLF is consumed as well. This cannot be overcome, no matter how you rewrite the rule, because the ABNF in RFC 5324 is not rich enough to express something like "consume all but one CR". A higher level construct like "obs-unstruct CRLF" must enforce a back-tracking step on the part of <obs-unstruct> in order to match. That is why I added the comment.
--VERIFIER NOTES--
Duplicate of erratum 1905, which I believe is correct as stated.
Errata ID: 2816
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nemo
Date Reported: 2011-05-27
Rejected by: Pete Resnick
Date Rejected: 2011-05-27
Section 3.6.2 says:
from = "From:" mailbox-list CRLF sender = "Sender:" mailbox CRLF reply-to = "Reply-To:" address-list CRLF
It should say:
from = "From:" mailbox-list CRLF sender = "Sender:" mailbox CRLF reply-to = "Reply-To:" mailbox-list CRLF
Notes:
The text in section 3.6.2 (and everywhere else Reply-To is mentioned) makes it clear that Reply-To is envisioned as referring to one or more mailboxes. But the following chain of productions:
address-list -> address -> group -> DQUOTE DQUOTE ":" ";"
...means that the following Reply-To header would be permitted by the spec:
Reply-To: "" : ;
This header has no mailbox in it at all. So either the reply-to production rule is wrong (and should be a mailbox-list instead of an address-list), or the spec needs to explain what the semantics are for a Reply-To line with no mailboxes in it.
Note also the description of "group" in section 3.4:
The group construct allows the sender to indicate a named group of recipients.
Again, this does not envision using a group in a header like Reply-To. But that is what the current reply-to construct permits.
Summary: The RFC either needs to forbid Reply-To with zero mailboxes, or it needs to explain what the semantics of such a Reply-To are.
--VERIFIER NOTES--
Reply-To has allowed address lists (as against mailbox lists) as far back as RFC 733. This would be a change to long held consensus. Not appropriate for an erratum.
Errata ID: 3088
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Redwine
Date Reported: 2012-01-11
Rejected by: Pete Resnick
Date Rejected: 2012-02-20
Section 3.3 says:
date-time = [ day-of-week "," ] date time [CFWS]
It should say:
date-time = [ day-of-week "," ] date time [comment]
Notes:
If using the [CFWS] at the end of the original text, by the rules of CFWS, the next line could contain only FWS after the CRLF, which would violate the requirement found in 3.2.2, which reads: "...where CFWS occurs in this specification, it MUST NOT be inserted in such a way that any line of a folded header field is made up entirely of WSP characters and nothing else."
--VERIFIER NOTES--
CFWS allows there to be multiple comments, including comments that go on to the second line, which is perfectly OK.
Errata ID: 3675
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Hoerl
Date Reported: 2013-06-29
Rejected by: Pete Resnick
Date Rejected: 2013-07-08
Section 3 says:
3.2.3. Atom Says:
dot-atom = [CFWS] dot-atom-text [CFWS]
3.2.4. Quoted Strings (but superseded by Errata 3135) Says:
quoted-string = [CFWS]
DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
[CFWS]
3.4.1. Addr-Spec Specification Says:
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
It should say:
3.2.3. Atom
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-lh = [CFWS] dot-atom-text [FWS]
dot-atom-rh = [FWS] dot-atom-text [CFWS]
3.2.4. Quoted Strings (but superseded by Errata 3135)
quoted-string = [CFWS]
DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
[CFWS]
quoted-string-lh = [CFWS]
DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
[FWS]
3.4.1. Addr-Spec Specification
addr-spec = local-part "@" domain
local-part = dot-atom-lh / quoted-string-lh / obs-local-part
domain = dot-atom-rh / domain-literal / obs-domain
domain-literal = [FWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
Notes:
Section 3.4.1 states "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec.", yet the ABNF specifically allows it without recourse to obsoleted terms. Given that the above statement is in fact correct, then the current ABNF should be modified as shown to reflect the above statement.
--VERIFIER NOTES--
The DRUMS Working Group made a conscious decision at the time of writing 2822 that they preferred clarity and ease of understanding of the ABNF at the expense of shift-reduce conflicts and other things that had to be limited in the text descriptions of the syntax, and that assumption carried over into 5322. This is one of those cases. While more precise, the correction is not what was intended, and there are many other cases where the text limits the more free syntax.
Errata ID: 5035
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Gene Hightower
Date Reported: 2017-06-09
Rejected by: Alexey Melnikov
Date Rejected: 2017-10-18
Section 3.3 says:
time = time-of-day zone zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
It should say:
time = time-of-day FWS zone zone = (( "+" / "-" ) 4DIGIT) / obs-zone
Notes:
The rfc5322 version of the syntax clearly forces the obs-zone to follow the time-of-day with no space. The syntax from rfc2822 seems to be what is actually in use in the real world. Why was this change made? Should it just be changed back?
--VERIFIER NOTES--
As per reply from Pete Resnick:
I believe this erratum report should be rejected. While it is true that
obs-zone does not begin with FWS, time-of-day ends with second, which
can be an obs-second, and obs-second ends with an optional CFWS.
Therefore, obs-zone is not forced to follow time-of-day with no space;
it just makes the space optional. And this allows for the original 822
syntax, which did not require space between the time-of-day and the
zone. (Somewhat goofy to allow that, but it is parseable.)
Errata ID: 5712
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor Shrubowich
Date Reported: 2019-04-29
Rejected by: Barry Leiba
Date Rejected: 2019-04-30
Section 3.2.2 says:
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
; Folding white space
It should say:
FWS = ([*WSP] CRLF 1*WSP) / obs-FWS
; Folding white space
Notes:
Both section 2.2.3 and part of section 3.2.2 ("Wherever folding appears in a message (that is, a header field body containing a CRLF followed by any WSP)") describe folding as adding CRLF followed by WSP, so CRLF is required for folding. However, the CRLF in the FWS rule is shown inside the square brackets, which would make it optional. It should not be inside the square brackets.
Square brackets: section 1.2.2 states "This specification uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation for the formal definitions of the syntax of messages." In RFC 5234, section 3.8 states "Square brackets enclose an optional element sequence".
--VERIFIER NOTES--
The FWS construct shows where folding is permitted (where CRLF *can* appear). The mechanism for actual folding is described in the text, and won't happen at each instance of FWS. Having the CRLF be optional is intentional and necessary.
Errata ID: 3400
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christoph Anton Mitterer
Date Reported: 2012-11-06
Rejected by: Pete Resnick
Date Rejected: 2012-12-10
Section 3.5. says:
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
It should say:
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
It is RECOMMENDED that message bodies are terminated by CRLF, though
this is in principle not necessary (this does not apply to messages
consisting only of a header section, as header fields are always CRLF
terminated).
Note however, that when transporting messages via SMTP the last lines
of message bodies MUST be terminated by CRLF as specified int
RFC 5321, section 4.1.1.4.
Notes:
Hi folks.
AFAIU, the definition of body allows message bodies (not header sections) that end without CRLF.
RFC5321 section 4.1.1.4. however states: "The mail data are terminated by a line containing only a period, that is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is actually the terminator of the previous line".
So SMTP forbids, what this RFC allows.
I guess the SMTP RFC can't be changed here and it makes no particular sense to restrict RFC5322 on the other hand.
My suggestion was to add this clarification.
Perhaps a similar one should be added to RFC5321, telling that Internet Messages themselves wouldn't need the last CRLF.
--VERIFIER NOTES--
It is clearly a change from WG consensus to add any normative 2119 text regarding a terminating CRLF. (See archive of the DRUMS WG, 17-18 March 1998 in a thread with a subject of "Small Clarification to msg-fmt-04".) The CRLF is not required for the message syntax. There are things other than this that 5321 cannot transport, so is also unlikely to be in scope for 5321 as an erratum either. Perhaps a discussion of this might be useful for RFC 3030, but again, it is unlikely to be an erratum.
Errata ID: 2619
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominic Sayers
Date Reported: 2010-11-10
Rejected by: Pete Resnick
Date Rejected: 2011-05-16
Section 3.4.1 says:
It is therefore
incumbent upon implementations to conform to the syntax of
addresses for the context in which they are used.
It should say:
Implementations MUST conform to the syntax of
addresses for the context in which they are used.
Notes:
The phrase "incumbent upon" is not defined in RFC 2119. If another RFC defines a standard with the force of "MUST", then it is not an option for an implementation to ignore that standard. Therefore, implementations MUST conform to their syntax.
This rewording clarifies the recognition that should be given to the RFCs that inform the particular context of the implementation.
--VERIFIER NOTES--
Conforming (or failing to conform) to the syntax of another specification does not affect the interoperability of *this* specification. Therefore, RFC 2119 language is not appropriate. However, even if it could be argued that it was, an erratum is not the appropriate place to make such a change.
Errata ID: 2620
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominic Sayers
Date Reported: 2010-11-10
Rejected by: Pete Resnick
Date Rejected: 2011-05-16
Section 3.4.1 says:
Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec.
It should say:
Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec. Comments and folding white space at the beginning and end of an addr-spec are semantically invisible.
Notes:
Section 3.2.2 says
"Runs of FWS, comment, or CFWS that occur between lexical tokens in a
structured header field are semantically interpreted as a single
space character."
but a leading or trailing space on an addr-spec would prevent it being interpreted as a valid RFC 5321 Mailbox (see http://tools.ietf.org/html/rfc5321#section-4.1.2).
This is important because this section of RFC 5322 also says
"It is therefore
incumbent upon implementations to conform to the syntax of
addresses for the context in which they are used."
Either the leading and trailing CFWS should be semantically "invisible" or additional logic is required for implementations to transform an RFC 5322 addr-spec into an RFC 5321 Mailbox.
Note: It may be true that leading and trailing CFWS is not "between lexical tokens". If so then it should be made clear what semantic interpretation to put on it in this case.
--VERIFIER NOTES--
1. "addr-spec" does not appear in 5321. 5321 and 5322 have two different definitions for "Mailbox" and "mailbox" respectively, and that is a topic for an update of these documents, not for an erratum.
2. This report does not want the CFWS to be *semantically* invisible; it wants it to be *syntactically* invisible when moving an addr-spec from a 5322 context to a 5321 context. This document does not discuss this use.
Errata ID: 3134
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ashley Willis
Date Reported: 2012-02-25
Rejected by: Pete Resnick
Date Rejected: 2012-04-28
Section Appendix A.5 says:
From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
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:
From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
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)
Notes:
Errata 2515 and 2579 change the above text, but there is no change needed to the original RFC. The quote from Section 3.4.1 says "SHOULD NOT", not "MUST NOT" ("Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."). The example in A.5 "is aesthetically displeasing, but perfectly legal." It's meant to highlight extreme cases.
--VERIFIER NOTES--
Though unstated in the text, the intention of the WG was that the examples in A.1-5 were intended to be messages that conformed to all of the MUSTs and SHOULDs of section 3. Indeed, RFC 2119 defines SHOULD NOT to mean effectively MUST NOT unless you have fully understood and weighed the reasons for choosing a different course. The description below the example says that it is "aesthetically displeasing, but perfectly legal". I don't think violating a SHOULD NOT makes it "perfectly" legal.