RFC Errata
Found 5 records.
Status: Verified (4)
RFC 5465, "The IMAP NOTIFY Extension", February 2009
Source of RFC: lemonade (app)
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.
Errata ID: 1694
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-23
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06
Section 8, pg.18 says:
message-event = ( "MessageNew" [SP
"(" fetch-att *(SP fetch-att) ")" ] )
[[...]]
| ;; The fett-att list may only be present for the
;; SELECTED/SELECTED-DELAYED mailbox filter
;; (<filter-mailboxes>).
It should say:
message-event = ( "MessageNew" [SP
"(" fetch-att *(SP fetch-att) ")" ] )
[[...]]
| ;; The fetch-att list may only be present for the
;; SELECTED/SELECTED-DELAYED mailbox filter
;; (<filter-mailboxes>).
Notes:
Location is near bottom of page 18.
Rationale: confusing typo; s/fett/fetch/
Errata ID: 1804
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Barry Leiba
Date Reported: 2009-07-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-05
Section 3.1 says:
page 7
C: b notify set status (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew)
Page 8
C: e notify set (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew) (mailboxes misc MessageNew)
It should say:
page 7
C: b notify set status (selected (MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge))
(subtree Lists (MessageNew))
Page 8
C: e notify set (selected (MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge))
(subtree Lists (MessageNew)) (mailboxes misc (MessageNew))
Notes:
Incorrect syntax in example... each "events" set needs to be in parentheses.
Errata ID: 3824
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jan-Philipp Litza
Date Reported: 2013-12-06
Verifier Name: Barry Leiba
Date Verified: 2013-12-06
Section 3 says:
IMAP servers that support this extension advertise the NOTIFY capability. This extension adds the NOTIFY command as defined in Section 5.1.
It should say:
IMAP servers that support this extension advertise the NOTIFY capability. This extension adds the NOTIFY command as defined in Section 3.1.
Notes:
Wrong section reference.
Status: Reported (1)
RFC 5465, "The IMAP NOTIFY Extension", February 2009
Source of RFC: lemonade (app)
Errata ID: 4833
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2016-10-17
Section 5.2, 7 says:
Section 5.2 paragraph 4: ... The FETCH response(s) MUST follow any ESEARCH ADDTO responses. Section 7 paragraph 2: Note that the EXISTS response MUST precede any FETCH responses, and together they MUST precede the ESEARCH response.
Notes:
As the RFC is internally inconsistent on this point, servers can have either behavior. I know of at least one deployed implementation that follows the MUST in section 7 rather than the one in section 5.2.
At this point I can't suggest specific corrected text, so this is a hold-for-document-update issue.