Re: [imapext] a very simple little imap extension, really quite magnificently simple

[Jan Kundrát <[e-mail]>]

On Friday, 25 April 2014 14:30:20 CEST, Arnt Gulbrandsen wrote:
>    Opening a large mailbox in IMAP can take mailbox; 30 seconds is

"...can take a long time"?

>    This extension provides a way to avoid having to number the messages
>    consecutively.

Are there any other mail servers out there which actually have a problem 
with sequence numbers, besides GMail? Just wondering what is more probable 
-- GMail adding $code which makes this faster because it's a pain for their 
clients, or $developers updating N clients to make use of this extension.

>    command, and that it MUST NOT expect to receive an EXISTS response.

How is the client supposed to notice that a new mail has arrived, then? I 
see it addressed later in the doc, but it startled me when I read this.

>    While the client will still receive MSNs, it MUST NOT expect them to
>    mean anything. (RFC editor: Remove this parenthesis. It seems to be
>    easier to add support for UIDONLY by disregarding parsed MSNs than to
>    change both the parser and the layer above, so I chose to leave dummy
>    MSNs in.)

I dislike this a lot. If the MSNs do not mean anything, just send a BAD and 
possibly even terminate the connection. Otherwise the garbage which is sent 
will only lead to further confusion of a non-compliant client.

>    These rules apply from the time the server has received an ENABLE
>    command that enables UIDONLY until the TCP connection is closed.

"until the IMAP session terminates". There's no requirement for IMAP to run 
over TCP. In fact, I used to use IMAP-over-SSH-with-PREAUTH on a daily 
basis for many years, and only stopped when they cut down the SSH access. I 
expect to use that in future as well.

>    The server MUST send the UID data item in all FETCH responses,
>    including untagged FETCH responses.

Which means that you effectively require QRESYNC and its VANISHED. Without 
that option it won't work. I see that you talk about that later in the 
text, but it should probably be a hard dep on 5162-bis.

Given that this extension disables EXISTS, you need soemthing like ARRIVED 
[1]. This change on its own will complicate this dratf a lot.

Also, what about STATUS and querying the offset of first message having a 
certain property through that? Or even STATUS EXISTS?

>    The server MUST respond with BAD to any command that uses an MSN,

Add a requirement for [CLIENTBUG], please. We have these response codes for 
a reason.

>    including a UID SEARCH command that uses MSNs. This search command
>    would retrieve the UID of the last message:

"...but the reference to the "last message" is specified as a MSN."

>    The server MUST NOT send EXISTS responses at any time (not even
>    during SELECT/EXAMINE processing), and MUST send UIDNEXT when it
>    would have sent EXISTS.

And the client doesn't know how many messages are in the mailbox anymore. 
That's a rather radical change. I don't like it at all, it's a nice 
safeguard to detect broken sync and this extension takes it away.

> For example:
>
>       C: a idle
>       S: +
>       S: * OK [UIDNEXT 10240902] next UID

This *will* lead to race conditions. Basically, this extension makes an 
unspoken assumption on UIDs being assigned in a consecutive manner, without 
any gaps. I bet there is at least one server implementaiton which can sleep 
and will notice that two messages have arrived and the first of them got 
deleted. How do you convey that?

>    The server MUST send VANISHED responses (see [RFC5162], section 3.6)
>    where it would ordinarily send EXPUNGED responses. ([RFC5162] defines
>    a large extension called Quick Resync, of which VANISHED is a small
>    part. Note that neither the server nor the client need support or use
>    Quick Resync in general.)

I don't like mandating VANISHED without also requiring the rest of the 
QRESYNC functionality. I for one cannot imagine how to sync a mailbox at 
all in at least semi efficient manner when I cannot rely on UIDNEXT/EXISTS 
combination and without QRESYNC's availability at the same time.

>    This document is believed not to have any security implications.

This extension, as-is, opens up a few opportunities for client and server 
to go out of sync, and potentially could lead to loss of data. When these 
problems are mitigated, the doc IMHO still needs a brief section saying how 
that was done and what bugs and gotchas are expected when an implementor 
botches up something.

>    [RFC5162]   Melnikov, A. and D. Cridland, "IMAP4 Extensions for Quick
>               Mailbox Resynchronization", RFC 5162, March 2008.

Would be cool to have a reference to 5162-bis when it gets approved.

Cheers,
Jan

[1] http://tools.ietf.org/html/draft-kundrat-qresync-arrived-00

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/