RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 records.

Status: Verified (2)

RFC 9051, "Internet Message Access Protocol (IMAP) - Version 4rev2", August 2021

Source of RFC: extra (art)

Errata ID: 7323
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Nicholas Evans
Date Reported: 2023-01-26
Verifier Name: Murray Kucherawy
Date Verified: 2023-07-28

Section 6.4.4.4. says:

        S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported

It should say:

        S: B283 NO [BADCHARSET (KOI8-R)] 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.

Errata ID: 8030
Status: Verified
Type: Editorial
Publication Format(s) : PDF

Reported By: David Harris
Date Reported: 2024-07-14
Verifier Name: RFC Editor
Date Verified: 2024-07-15

Section 6.3.10 says:

The client is designed so that it keeps two 'Deleted Items' mailboxes,
one for each namespace

C: A005 CREATE "Delete Items"
S: A005 OK CREATE command completed
C: A006 CREATE "#mh/Deleted Items"
S: A006 OK CREATE command completed

It should say:

The client is designed so that it keeps two 'Deleted Items' mailboxes,
one for each namespace

C: A005 CREATE "Deleted Items"
S: A005 OK CREATE command completed
C: A006 CREATE "#mh/Deleted Items"
S: A006 OK CREATE command completed

Notes:

Simple typographic error in mailbox name. "Delete Items" should be "Deleted Items".

Status: Reported (5)

RFC 9051, "Internet Message Access Protocol (IMAP) - Version 4rev2", August 2021

Source of RFC: extra (art)

Errata ID: 7343
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Nicholas Evans
Date Reported: 2023-02-13

Section 9 says:

resp-cond-auth  = ("OK" / "PREAUTH") SP resp-text
                    ; Authentication condition

resp-cond-bye   = "BYE" SP resp-text

resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
                    ; Status condition

...

resp-text       = ["[" resp-text-code "]" SP] [text]


It should say:

resp-cond-auth  = ("OK" / "PREAUTH") [SP resp-text]
                    ; Authentication condition
                    ;
                    ; Servers SHOULD send the trailing SP when resp-text
                    ; is empty.
                    

resp-cond-bye   = "BYE" [SP resp-text]
                    ; Servers SHOULD send the trailing SP when resp-text
                    ; is empty.

resp-cond-state = ("OK" / "NO" / "BAD") [SP resp-text]
                    ; Status condition
                    ;
                    ; Servers SHOULD send the trailing SP when resp-text
                    ; is empty.

...


resp-text       = "[" resp-text-code "]" [SP [text]] / [text]
                    ; Servers SHOULD send then trailing SP when
                    ; resp-text-code is present but text is empty.

Notes:

Appendix E, Changes from RFC 3501 / IMAP4rev1, item 23 states that "resp-text ABNF non-terminal was updated to allow for empty text."

In the spirit of Appendix E. 23, resp-text should allow "[" resp-text-code "]" without a trailing SP. Similarly, resp-cond-auth, resp-cond-bye, and resp-cond-state should also allow the trailing SP to be dropped when resp-text is empty. In all of these cases, the missing SP does not change the semantics of the response, so clients should not require it to be present. However, for compatibility with clients that strictly adhere to the formal syntax as-is, servers should conservatively send the trailing SP even when text or resp-text is empty.

This aligns with existing practice, as some existing IMAP4rev1 servers already fail to send these trailing spaces, and some liberal clients already allow them to be missing.

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: 7518
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Joó Ádám
Date Reported: 2023-05-18

Section 4.1.1. says:

   A set of messages can be referenced by a sequence set containing
   either message sequence numbers or unique identifiers.  See Section 9
   for details.  A sequence set can contain ranges of sequence numbers
   (such as "5:50"), an enumeration of specific sequence numbers, or a
   combination of the above.  A sequence set can use the special symbol
   "*" to represent the maximum sequence number in the mailbox.  A
   sequence set never contains unique identifiers.

It should say:

Why am I required to fix someone else's sloppy writing?

Notes:

The first and last sentences are in direct contradiction. Clarification is needed.

Errata ID: 7593
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML

Reported By: Simon Ser
Date Reported: 2023-08-07

Section 6.3.10 says:

  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"
      ("FLAG1" "FLAG2"))) NIL NIL
  S: A001 OK NAMESPACE command completed

  C: A002 LIST (SPECIAL-USE) "" "*"
  S: * LIST (\NonExistent \Archive) "/" Archives
  S: * LIST (\NonExistent \Drafts) "/" Drafts
  S: * LIST (\NonExistent \Junk) "/" Junk
  S: * LIST (\NonExistent \Sent) "/" "Sent Mail"
  S: * LIST (\NonExistent \Trash) "/" "Deleted Items"
  S: A002 OK LIST Completed

  C: A003 LIST (SPECIAL-USE) "#mh/" "*"
  S: * LIST (\NonExistent \Archive) "/" "#mh/Archives"
  S: * LIST (\NonExistent \Drafts) "/" "#mh/Drafts"
  S: * LIST (\NonExistent \Junk) "/" "#mh/Junk"
  S: * LIST (\NonExistent \Sent) "/" "#mh/Sent Mail"
  S: * LIST (\NonExistent \Trash) "/" "#mh/Deleted Items"
  S: A003 OK LIST Completed

It should say:

  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"
      ("FLAG1" "FLAG2"))) NIL NIL
  S: A001 OK NAMESPACE command completed

  C: A002 LIST "" "*"
  S: * LIST (\NonExistent \Archive) "/" Archives
  S: * LIST (\NonExistent \Drafts) "/" Drafts
  S: * LIST (\NonExistent \Junk) "/" Junk
  S: * LIST (\NonExistent \Sent) "/" "Sent Mail"
  S: * LIST (\NonExistent \Trash) "/" "Deleted Items"
  S: A002 OK LIST Completed

  C: A003 LIST "#mh/" "*"
  S: * LIST (\NonExistent \Archive) "/" "#mh/Archives"
  S: * LIST (\NonExistent \Drafts) "/" "#mh/Drafts"
  S: * LIST (\NonExistent \Junk) "/" "#mh/Junk"
  S: * LIST (\NonExistent \Sent) "/" "#mh/Sent Mail"
  S: * LIST (\NonExistent \Trash) "/" "#mh/Deleted Items"
  S: A003 OK LIST Completed

Notes:

The SPECIAL-USE LIST option is part of the IMAP4rev1 SPECIAL-USE extension, but has not been carried over in IMAP4rev2.

Errata ID: 8001
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Yasumasa Shimizu
Date Reported: 2024-06-25

Section Appendix E says:

   1.   Support for 64-bit message and body part sizes.
...
   30.  Loosened requirements on servers when closing connections to be
        more aligned with existing practices.

It should say:

   1.  Support for 64-bit message and body part sizes.
...
   30.  Loosened requirements on servers
        when closing connections to be more aligned with existing practices.
   31.  Response of the SUBSCRIBE command and the UNSUBSCRIBE command
        is changed from tagged NO to tagged OK
        if the mailbox is already subscribed/unsubscribed.

Notes:

RFC3501 6.3.6 says:

The SUBSCRIBE command adds the specified mailbox name to the server's set of "active" or "subscribed" mailboxes as returned by the LSUB command. This command returns a tagged OK response only if the subscription is successful.

According to this, SUBSCRIBE command returns a tagged NO response if the mailbox is already subscribed.
however, RFC 9501 6.3.7 says:

The SUBSCRIBE command adds the specified mailbox name to the server's set of "active" or "subscribed" mailboxes as returned by the LIST (SUBSCRIBED) command. This command returns a tagged OK response if the subscription is successful or if the mailbox is already subscribed.

This can be said that there are not compatible between IMAP4rev1 and IMAP4rev2.
This problem also occurs in UNSUBSCRIBE command.
I think this should be written in Appendix E.

Status: Held for Document Update (1)

RFC 9051, "Internet Message Access Protocol (IMAP) - Version 4rev2", August 2021

Source of RFC: extra (art)

Errata ID: 6826
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Hontvári Levente
Date Reported: 2022-02-02
Held for Document Update by: Murray Kucherawy
Date Held: 2023-07-28

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.

Report New Errata



Advanced Search