RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 11 records.

Status: Verified (6)

RFC 5322, "Internet Message Format", October 2008

Note: This RFC has been updated by RFC 6854

Source of RFC: IETF - NON WORKING GROUP
Area 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."

Status: Reported (5)

RFC 5322, "Internet Message Format", October 2008

Note: This RFC has been updated by RFC 6854

Source of RFC: IETF - NON WORKING GROUP
Area 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.

Errata ID: 6920
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: John Klensin
Date Reported: 2022-04-05

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)

Report New Errata



Advanced Search