RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003

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

Report New Errata