RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 records.

Status: Verified (4)

RFC 5162, "IMAP4 Extensions for Quick Mailbox Resynchronization", March 2008

Note: This RFC has been obsoleted by RFC 7162

Source of RFC: lemonade (app)

Errata ID: 1807
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Timo Sirainen
Date Reported: 2009-07-14
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 1 says:


It should say:

   Once a "CONDSTORE enabling command" is issued by the client, the
   server MUST automatically include both UID and mod-sequence data in
   all subsequent untagged FETCH responses (until the connection is
   closed), whether they were caused by a regular STORE/UID STORE, a
   STORE/UID STORE with UNCHANGEDSINCE modifier, or an external agent.
   Note that this rule doesn't affect untagged FETCH responses caused by
   a FETCH command that doesn't include UID and/or MODSEQ FETCH data
   item, or UID FETCH without the MODSEQ FETCH data item.

Notes:

Rationale:

It's very difficult for clients to make use of unsolicited FETCH responses without the UID field. This is made even worse by the text that says "servers SHOULD NOT send UIDs for previously expunged messages [in VANISHED replies]". Since it's not a MUST NOT, a conversation with an RFC compliant server could be for example:

A1 NOOP
* 0 EXISTS
A1 OK
A2 NOOP
* 10 EXISTS
* VANISHED 1000:2000
* 3 FETCH (FLAGS (\Seen) MODSEQ (14749))
* 5 FETCH (FLAGS (\Seen) MODSEQ (14749))
* VANISHED 2000:3000
A2 OK NOOP Completed

The client couldn't do anything with the information from FETCH replies, because it can't know what messages they refer to.

Errata ID: 1808
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Timo Sirainen
Date Reported: 2009-07-14
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 3.4 says:

   If at least one message got expunged, the server MUST send
   the updated per-mailbox modification
   sequence using the HIGHESTMODSEQ response code (defined in
   [CONDSTORE]) in the tagged OK response.

      Example:    C: A202 CLOSE
                  S: A202 OK [HIGHESTMODSEQ 20010715194045319] done

It should say:

   The server MUST NOT send the updated per-mailbox modification
   sequence using the HIGHESTMODSEQ response code (defined in
   [CONDSTORE]) in the tagged OK response, as this might cause loss of
   synchronization on the client.

      Example:    C: A202 CLOSE
                  S: A202 OK done

Notes:

Rationale:

The HIGHESTMODSEQ can't be used reliably unless server sends to client all changes done by other clients. Even then it's difficult for both clients and servers to implement this. For example:

C1: 2 STORE 1 +FLAGS.SILENT \Deleted
S1: * 1 FETCH (MODSEQ 1)
S1: 2 OK

C2: 1 STORE 2 +FLAGS.SILENT \Deleted
S1: * 2 FETCH (MODSEQ 2)
S2: 1 OK

C1: 3 CLOSE
S1: 3 [HIGHESTMODSEQ 3]

The client probably thought that only message 1 was expunged, so it
doesn't register the second expunge. And it probably never will if it
uses QRESYNC to find out only about new expunges.

And even worse example would be if the second client had also removed
the \Deleted flag from message 1. Then the first client would have
registered wrong message to be expunged.

Errata ID: 1809
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Timo Sirainen
Date Reported: 2009-07-14
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 5 says:

   After completing a full synchronization, the client MUST also take
   note of any unsolicited MODSEQ FETCH data items received from the
   server.  Whenever the client receives a tagged response to a command,
   it calculates the highest value among all MODSEQ FETCH data items
   received since the last tagged response.  If this value is bigger
   than the client's copy of the HIGHESTMODSEQ value, then the client
   MUST use this value as its new HIGHESTMODSEQ value.

   Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
   value with a MODSEQ FETCH data item value as soon as it is received
   because servers are not required to send MODSEQ FETCH data items in
   increasing modseqence order.  This can lead to the client missing
   some changes in case of connectivity loss.

It should say:

   After completing a full synchronization, the client MUST also take
   note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ
   response codes received from the server.  Whenever the client receives
   a tagged response to a command, it checks the received unsolicited
   responses to calculate the new HIGHESTMODSEQ value.  If the
   HIGHESTMODSEQ response code is received, the client MUST use it even
   if it has seen higher mod-sequences.  Otherwise, the client calculates
   the highest value among all MODSEQ FETCH data items received since the
   last tagged response.  If this value is bigger than the client's copy
   of the HIGHESTMODSEQ value, then the client MUST use this value as its
   new HIGHESTMODSEQ value.

      Example:    C: A1 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen
                  S: * 1 FETCH (UID 6 MODSEQ (103))
                  S: * 2 FETCH (UID 7 MODSEQ (101))
                  S: * OK [HIGHESTMODSEQ 99] VANISHED reply with
		      MODSEQ 100 is delayed
                  S: A1 OK [MODIFIED 3] done

                  C: A2 STORE 3 +FLAGS.SILENT \Seen
                  S: * 3 FETCH (UID 8 MODSEQ (104))
                  S: A2 OK [HIGHESTMODSEQ 99] Still delaying VANISHED

                  C: A3 NOOP
                  S: * VANISHED 8
                  S: A3 OK [HIGHESTMODSEQ 104] done

   Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
   value with a MODSEQ FETCH data item value as soon as it is received
   because servers are not required to send MODSEQ FETCH data items in
   increasing modseqence order.  Some commands may also delay EXPUNGE
   (or VANISHED) replies with smaller mod-sequences. These can lead to
   the client missing some changes in case of connectivity loss.

Notes:

Rationale:

Otherwise clients could lose changes in case of connectivity loss.

Errata ID: 1810
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Timo Sirainen
Date Reported: 2009-07-14
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 1 says:


It should say:

   Server implementing QRESYNC MUST send untagged events to client in a
   way that client doesn't lose any changes in case of connectivity loss.
   In particular this means that if server sends MODSEQ FETCH data items
   while EXPUNGE (or VANISHED) replies with lower mod-sequences are being
   delayed, the server MUST send HIGHESTMODSEQ response code with a lower
   value than the EXPUNGE's mod-sequence. See example in section 5.

Notes:

This is related to the other errata in section 5, which describes what the client's behavior should be. This describes what the server's behavior should be. Would have been nice to put them into the same section, but that probably would require larger changes.

Status: Held for Document Update (1)

RFC 5162, "IMAP4 Extensions for Quick Mailbox Resynchronization", March 2008

Note: This RFC has been obsoleted by RFC 7162

Source of RFC: lemonade (app)

Errata ID: 1365
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Pete Resnick

Section 1. (ff.) says:

   A client making use of this extension MUST issue "ENABLE QRESYNC"
   once it is authenticated.  A server MUST respond with a tagged BAD
   response if the QRESYNC parameter to the SELECT/EXAMINE command or
   the VANISHED UID FETCH modifier is specified and the client hasn't
   issued "ENABLE QRESYNC" in the current connection.

It should say:

   A client making use of this extension MUST issue "ENABLE QRESYNC"
   once it is authenticated.  A server MUST respond with a tagged BAD
   response if the QRESYNC parameter to the SELECT/EXAMINE command or
   the VANISHED UID FETCH modifier is specified and the client hasn't
|  issued "ENABLE QRESYNC", or the server has not positively responded
|  to that command with "ENABLED QRESYNC", in the current connection.

Notes:

Rationale:
According to RFC 5161, the option enablement handshake is only
complete, and hence the option(s) enabled on the server, if the
server has sent a positive (untagged) "ENABLED <option>" response
to the ENABLE command.
For clarity, RFC 5162 should unambiguously reflect this causality
chain.

This same issue recurs in Section 3.1 (last paragraph on page 4)
and Section 3.6 (4th paragraph on page 13).

Status: Rejected (2)

RFC 5162, "IMAP4 Extensions for Quick Mailbox Resynchronization", March 2008

Note: This RFC has been obsoleted by RFC 7162

Source of RFC: lemonade (app)

Errata ID: 3322
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Jan Kundrát
Date Reported: 2012-08-16
Rejected by: Pete Resnick
Date Rejected: 2013-01-28

Section 3.6 says:

A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
or because messages were expunged in other connections (i.e., the
VANISHED response without the EARLIER tag) also decrements the number
of messages in the mailbox; it is not necessary for the server to
send an EXISTS response with the new value.  It also decrements
message sequence numbers for each successive message in the mailbox
(see the example at the end of this section).  Note that a VANISHED
response caused by EXPUNGE, UID EXPUNGE, or messages expunged in
other connections SHOULD only contain UIDs for messages expunged
since the last VANISHED/EXPUNGE response sent for the currently
opened mailbox or since the mailbox was opened.  That is, servers
SHOULD NOT send UIDs for previously expunged messages, unless
explicitly requested to do so by the UID FETCH (VANISHED) command.

Note that client implementors must take care to properly decrement
the number of messages in the mailbox even if a server violates this
last SHOULD or repeats the same UID multiple times in the returned
UID set.  In general, this means that a client using this extension
should either avoid using message numbers entirely, or have a
complete mapping of UIDs to message sequence numbers for the selected
mailbox.

It should say:

A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
or because messages were expunged in other connections (i.e., the
VANISHED response without the EARLIER tag) also decrements the number
of messages in the mailbox; it is not necessary for the server to
send an EXISTS response with the new value.  It also decrements
message sequence numbers for each successive message in the mailbox
(see the example at the end of this section).

Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or
messages expunged in other connections MUST only contain UIDs for
messages expunged since the last VANISHED/EXPUNGE response sent for
the currently opened mailbox or since the mailbox was opened.  That is,
servers MUST NOT send UIDs for previously expunged messages, unless
explicitly requested to do so by the UID FETCH (VANISHED) command.
This is required to prevent a possible race condition where new arrivals
for which the UID is not yet known by the client are expunged.

Notes:

If the servers were allowed to send VANISHED responses referring to non-existing UIDs, there's a possible race condition when new arrivals are expunged. This is due to the sequence-UID assymetry of EXISTS vs. VANISHED.

New arrivals are reported through EXISTS and their UIDs are not known to the client. Suppose the following scenario where two messages exist and their UIDs are 10 and 11. Two more messages arrive:

* 4 EXISTS
* VANISHED 12:20

The client has no way of knowing whether the two new arrivals have UIDs falling into the 12:20 range. As such, the client doesn't know whether there are two, three or four messages in the mailbox at this point.

See http://mailman2.u.washington.edu/pipermail/imap-protocol/2012-June/001781.html for details.
--VERIFIER NOTES--
This is a clear change to the intention of the document and is too large a change to be appropriate to an erratum. There is a problem here, but it is more properly handled by new work, which is being undertaken as http://datatracker.ietf.org/doc/draft-kundrat-qresync-arrived/

Errata ID: 3323
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Jan Kundrát
Date Reported: 2012-08-16
Rejected by: Pete Resnick
Date Rejected: 2012-11-04

Throughout the document, when it says:

The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command
also tells the server that it SHOULD start sending VANISHED responses
(see Section 3.6) instead of EXPUNGE responses.

It should say:

The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command
also tells the server that it MUST start sending VANISHED responses
(see Section 3.6) instead of EXPUNGE responses.

Notes:

The explicit allowance for EXPUNGE being sent instead of VANISHED means that clients still have to maintain a full sequence-to-UID mapping, otherwise there is a risk of losing synchronization. Given that QRESYNC itself is an optional extension, I find it hard to imagine a case where the server cannot send a proper VANISHED response.

If this errata gets accepted, it will require rather heavy editing of the document; the notion of EXPUNGE responses being allowed is followed throughout the whole RFC, including the examples.
--VERIFIER NOTES--
The fact that this is a change to a normative requirement of the document, and (as the notes say) the fact that it would cause extensive changes to the rest of the document, makes it inappropriate as an erratum.

Report New Errata



Advanced Search