RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (1)

RFC 822, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982

Note: This RFC has been obsoleted by RFC 2822

Note: This RFC has been updated by RFC 1123, RFC 2156, RFC 1327, RFC 1138, RFC 1148

Source of RFC: Legacy
Area Assignment: app

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

Reported By: Wolf Lammen
Date Reported: 2009-10-02
Verifier Name: Pete Resnick
Date Verified: 2011-05-16

Section 3.1.4 says:

                    :sysmail              quoted string
                    @                     special
                    Some-Group            atom
                    .                     special
                    Some-Org              atom
                    ,                     special
                    Muhammed              atom
                    .                     special
                    (I am  the greatest)  comment
                    Ali                   atom
                    @                     atom
                    (the)                 comment
                    Vegas                 atom
                    .                     special
                    WBA                   atom

It should say:

                    ":sysmail"            quoted string
                    @                     special
                    Some-Group            atom
                    .                     special
                    Some-Org              atom
                    ,                     special
                    Muhammed              atom
                    .                     special
                    (I am  the greatest)  comment
                    Ali                   atom
                    @                     special
                    (the)                 comment
                    Vegas                 atom
                    .                     special
                    WBA                   atom

Status: Held for Document Update (3)

RFC 822, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982

Note: This RFC has been obsoleted by RFC 2822

Note: This RFC has been updated by RFC 1123, RFC 2156, RFC 1327, RFC 1138, RFC 1148

Source of RFC: Legacy
Area Assignment: app

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

Reported By: Peter Backes
Date Reported: 2007-11-21
Held for Document Update by: Pete Resnick

Section 3.1.4. says:

                    Muhammed              atom
                    .                     special
                    (I am  the greatest)  comment
                    Ali                   atom
                    @                     atom
                    (the)                 comment
                    Vegas                 atom
                    .                     special
                    WBA                   atom

It should say:

                    Muhammed              atom
                    .                     special
                    (I am  the greatest)  comment
                    Ali                   atom
                    @                     special
                    (the)                 comment
                    Vegas                 atom
                    .                     special
                    WBA                   atom

Notes:

Apparently an artifact introduced by copying and incompletely adapting the example in RFC733, section III.B.e, which uses the atom "at" instead of the special "@".

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

Reported By: Thomas Lane
Date Reported: 2012-11-14
Held for Document Update by: Pete Resnick
Date Held: 2013-01-28

Section 3.3 says:

quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                            ; quoted chars.


[...]

domain-literal =  "[" *(dtext / quoted-pair) "]"

[...]

comment     =  "(" *(ctext / quoted-pair / comment) ")"

It should say:

quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                            ; quoted chars.
                                            ; Bare LF MUST NOT
                                            ; follow the
                                            ; quoted-pair \ CR


[...]

domain-literal =  "[" *(dtext / quoted-pair) "]" ; Bare LF MUST NOT
                                                 ; follow the
                                                 ; quoted-pair \ CR

[...]

comment     =  "(" *(ctext / quoted-pair / comment) ")" ; Bare LF MUST NOT
                                                        ; follow the
                                                        ; quoted-pair \ CR


Notes:

In Section B.1, the intent is made clear that an implementer should be able to read fields with minimal processing, and find their ends anywhere CRLF is not followed by a LWSP-char.

The current BNF allows the sequence \ CR LF, where \ CR is a quoted-pair, inside a quoted-string, domain-literal, or comment in a structured field. An unstructured field may be any sequence of text, so the last character of an unstructured field could be \, and the field would end with \ CR LF. So, robust minimal processing of fields does not work without this correction.

Example:

-- Unstructured field terminates here.
Subject: evil = "this \[CRLF]
[CRLF]

-- Structured field does not terminate here, as written.
Structured-Field: evil = "this \[CRLF] <-- quoted-pair, bare LF as qtext"
[CRLF]

Conclusion: The plan in appendix B does not work if the quoted-pair \ CR may be followed by a bare LF: the implementer would need to know whether a field is structured or unstructured to know where it terminates. So, this must just be an oversight.

I realize this oversight is eliminated in less obsolete documents 2822 and 5322, but (1) many other RFCs reference RFC 822 and not the less obsolete documents, and (2) the less obsolete documents do not specifically discuss this issue or release receivers from parsing messages generated according to this specification.

--VERIFIER NOTES--
It is unclear whether the original authors of 822 would have required no bare LF after a CR quoted-pair or would have changed appendix B to accommodate quoted-pairs. The IESG guidelines for errata say that errata on obsolete document that are still in use should be treated the same as errata on current documents. Since it's not clear where the error is, and since this has been dealt with in 2822/5322, this erratum is marked as "Hold".

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

Reported By: Sebastian Haller
Date Reported: 2016-01-07
Held for Document Update by: Barry Leiba
Date Held: 2016-01-07

Section A.3.3 says:

     cc       :  Important folk:
                   Tom Softwood <Balsa@Tree.Root>,
                   "Sam Irving"@Other-Host;,
                 Standard Distribution:
                   /main/davis/people/standard@Other-Host,
                   "<Jones>standard.dist.3"@Tops-20-Host>;

It should say:

     cc       :  Important folk:
                   Tom Softwood <Balsa@Tree.Root>,
                   "Sam Irving"@Other-Host;,
                 Standard Distribution:
                   /main/davis/people/standard@Other-Host,
                   "<Jones>standard.dist.3"@Tops-20-Host;

or

                   <"Jones>standard.dist.3"@Tops-20-Host>;

or

                   <"<Jones>standard.dist.3"@Tops-20-Host>;

Notes:

According to 3.4.6 of the RFC, brackets must occur in matched pairs. There is not matching "<" for the closing ">" after "Tops-20-Host".

----- Verifier Notes -----
RFC 822 has long been obsolete, first by RFC 2822 and then by RFC 5322, and I hope everyone is using 5322 by now. The examples were completely re-done in 2822, and this issue is long gone.

Status: Rejected (1)

RFC 822, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982

Note: This RFC has been obsoleted by RFC 2822

Note: This RFC has been updated by RFC 1123, RFC 2156, RFC 1327, RFC 1138, RFC 1148

Source of RFC: Legacy
Area Assignment: app

Errata ID: 7573
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Ulrich Windl
Date Reported: 2023-07-24
Rejected by: Orie Steele
Date Rejected: 2024-05-03

Section 3.1.1 says:

        inserted.  Thus, the single line
            To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
        can be represented as:
            To:  "Joe & J. Harvey" <ddd @ Org>,
                    JJV@BBN
        and
            To:  "Joe & J. Harvey"
                            <ddd@ Org>, JJV
             @BBN
        and
            To:  "Joe &
             J. Harvey" <ddd @ Org>, JJV @ BBN

It should say:

        inserted.  Thus, the single line
            To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
        can be represented as:
            To:  "Joe & J. Harvey" <ddd @ Org>,
             JJV@BBN
        and
            To:  "Joe & J. Harvey"
             <ddd@ Org>, JJV
             @BBN
        and
            To:  "Joe &
             J. Harvey" <ddd @ Org>, JJV @ BBN

Notes:

Possibly arising from mis-interpreting RFC 733 section III.B.a (Folding and unfolding of headers) which says: "The general rule is that wherever there can be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char can instead be inserted."
This may be interpreted that when folding at one while space character an arbitrary amount of white space characters may be inserted at the next line, also saying that one white space in a header is equivalent to multiple white space characters.
subsequent revisions (RFC 2822, RFC 5322) are increasingly more clear on that:
"The general rule is that wherever this specification allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP."
--VERIFIER NOTES--
Per https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/

It appears this has been clarified in subsequent revisions (RFC 2822, RFC 5322)



Report New Errata



Advanced Search