RFC 5465, "The IMAP NOTIFY Extension", February 2009

Errata ID: 2318
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Woodhouse
Date Reported: 2010-07-06
Verifier Name: Barry Leiba
Date Verified: 2012-05-02

Section 3.1 says:

               (Time passes.  The client decides it wants to know about
               one more mailbox.  As the client already knows necessary
               STATUS information for all mailboxes below the Lists
               mailbox, and because "notify set status" would cause
               STATUS responses for *all* mailboxes specified in the
               NOTIFY command, including the ones for which the client
               already knows STATUS information, the client issues an
               explicit STATUS request for the mailbox to be added to
               the watch list, followed by the NOTIFY SET without the
               STATUS parameter.)
         C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES)
         S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
         S: d STATUS completed

         C: e notify set (selected MessageNew (uid
            body.peek[header.fields (from to subject)]) MessageExpunge)
            (subtree Lists MessageNew) (mailboxes misc MessageNew)
         S: e OK done

It should say:

               (Time passes.  The client decides it wants to know about
               one more mailbox.  As the client already knows necessary
               STATUS information for all mailboxes below the Lists
               mailbox, and because "notify set status" would cause
               STATUS responses for *all* mailboxes specified in the
               NOTIFY command, including the ones for which the client
               already knows STATUS information, the client issues a
               NOTIFY SET without the STATUS parameter, followed by an
               explicit STATUS request for the newly-added mailbox.
               Note that if these two commands were issued in the reverse
               order, that would be a client bug; changes may occur in
               the mailbox between the completion of the STATUS command,
               and the issuing of the NOTIFY command.  The client may
               never be notified of such changes.)
         C: d notify set (selected MessageNew (uid
            body.peek[header.fields (from to subject)]) MessageExpunge)
            (subtree Lists MessageNew) (mailboxes misc MessageNew)
         S: d OK done

         C: e STATUS misc (UIDVALIDITY UIDNEXT MESSAGES)
         S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
         S: e STATUS completed

Notes:

The order of the STATUS and NOTIFY commands is changed. The original sequence is buggy, because any changes to the folder which occur between the two commands will not be noticed by the client.

Rather than just fixing it, my suggested correction also highlights the potential error -- if the authors of the RFC can do it, and especially since it's been shown as an example in the RFC until now, then it's worth making sure we highlight the problem.

Report New Errata