RFC Errata
RFC 3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003
Note: This RFC has been obsoleted by RFC 9051
Note: This RFC has been updated by RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 3445
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Slusarz
Date Reported: 2013-01-06
Rejected by: Barry Leiba
Date Rejected: 2013-01-08
Section 6.3.1 says:
OK [UIDNEXT <n>]
The next unique identifier value. Refer to section
2.3.1.1 for more information. If this is missing,
the client can not make any assumptions about the
next unique identifier value.
It should say:
OK [UIDNEXT <n>]
The next unique identifier value. Refer to section
2.3.1.1 for more information.
Notes:
The UIDNEXT response to a SELECT/EXAMINE command is a "REQUIRED OK untagged response" (see Sections 6.3.1 & 6.3.2; see also Appendix B #34). The UIDNEXT response code requires a nz-number per the ABNF (Section 9). Therefore the UIDNEXT value can never be "missing" from a SELECT/EXAMINE, and no assumptions about client behavior should be mentioned.
As currently phrased, the UIDNEXT text implies that the response MAY be missing, which is in direct conflict with the requirements in Sections 6.3.1/6.3.2 that UIDNEXT MUST always be present. REQUIRED appears to be the proper requirement based on the previously mentioned change entry.
See discussion on the IMAP protocol discussion list (http://thread.gmane.org/gmane.mail.imap.general/3163).
--VERIFIER NOTES--
Look at the paragraph above the responses in Section 6.3.1. It says this:
The SELECT command selects a mailbox so that messages in the
mailbox can be accessed. Before returning an OK to the client,
the server MUST send the following untagged data to the client.
Note that earlier versions of this protocol only required the
FLAGS, EXISTS, and RECENT untagged data; consequently, client
implementations SHOULD implement default behavior for missing data
as discussed with the individual item.
The text that you're suggesting removing is there very purposefully,
and should NOT be removed. That said, I think this is not very clear,
and I would like to see a future document update re-word things to
make it clearer.
The point is that these are REQUIRED in the current version of the protocol,
but that because they were optional in an earlier version, and that version is
not distinguishable from this one in operation, clients SHOULD support the
earlier version by taking the actions specified in the even that some or all of
these untagged OK responses are missing.