RFC Errata
Found 3 records.
Status: Reported (3)
RFC 9051, "Internet Message Access Protocol (IMAP) - Version 4rev2", August 2021
Source of RFC: extra (art)
Errata ID: 6826
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Hontvári Levente
Date Reported: 2022-02-02
Throughout the document, when it says:
18. RFC822, RFC822.HEADER, and RFC822.TEXT FETCH data items were deprecated. Clients should use the corresponding BODY[] variants instead.
It should say:
18. RFC822, RFC822.HEADER, and RFC822.TEXT FETCH data items were removed. Clients should use the corresponding BODY[] variants instead.
Notes:
Contrary to the original text, these data items are not deprecated but they were completely removed from the text of the RFC. As far as I see other deprecated items are not removed completely but moved to a '...obsolete...' token in the formal syntax.
Errata ID: 7246
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mechiel Lukkien
Date Reported: 2022-11-12
Section 7.5.2. says:
BINARY[<section-binary>]<<number>> An <nstring> or <literal8> expressing the content of the specified section after removing any encoding specified in the corresponding Content-Transfer-Encoding header field. If <number> is present, it refers to the offset within the DECODED section data.
It should say:
BINARY[<section-binary>] An <nstring> or <literal8> expressing the content of the specified section after removing any encoding specified in the corresponding Content-Transfer-Encoding header field.
Notes:
While a FETCH _request_ can be "partial" with <...> for both BODY[] and BINARY[], only a FETCH _response_ for BODY[] can have an optional offset. A FETCH _response_ for BINARY[] cannot have an optional offset. At least according to the ABNF, which I believe is leading.
See lines 6756 and 6757: msg-att-static = "BODY" section ["<" number ">"] SP nstring / "BINARY" section-binary SP (nstring / literal8)
And line 6987: section-binary = "[" [section-part] "]"
RFC 3516, IMAP4 Binary Content Extension, from which the original text was probably copied, appears to have the same issue but no errata.
Errata ID: 7323
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicholas Evans
Date Reported: 2023-01-26
Section 6.4.4.4. says:
S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported
It should say:
S: B283 NO [BADCHARSET (UTF-8)] KOI8-R is not supported
Notes:
The BADCHARSET response code is described in 7.1 as "Optionally followed by a parenthesized list of charsets", and in the formal syntax as:
resp-text-code =/ "BADCHARSET" [SP "(" charset *(SP charset) ")" ]
Although a client's parser might use a generic resp-text-code (atom [SP 1*<any TEXT-CHAR except "]">]) as a fallback, the server should parenthesize even when only one charset is sent.