MBOX-Line: From arnt at gulbrandsen.priv.no  Tue Sep 19 03:26:21 2006
To: imap-protocol@u.washington.edu
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] Avoiding connection-loss
In-Reply-To: <Pine.OSX.4.64.0609181137520.368@pangtzu.panda.com>
References: <009901c6daf1$1026f580$2d65a8c0@ProImage.local>
	<Pine.OSX.4.64.0609180815470.368@pangtzu.panda.com>
	<5273.1158594140.711631@invsysm1>
	<Pine.OSX.4.64.0609180855530.368@pangtzu.panda.com>
	<KKoUp6qRrcfZ2zeBmqURBg.md5@libertango.oryx.com>
	<Pine.OSX.4.64.0609181137520.368@pangtzu.panda.com>
Message-ID: <+zIRTx+YE8iB3/J6OY9jzQ.md5@libertango.oryx.com>

Mark Crispin writes:
> On Mon, 18 Sep 2006, Arnt Gulbrandsen wrote:
>>> However, it is one certain client that ever allows an IDLE to go for 
>>> so long, and we can be confident that client will never use 
>>> UIDNEXT.
>> Uh. Mine allows IDLE to go on for 50 seconds longer and uses UIDNEXT.
>
> RFC 2177 states:
>
>    [...] clients using IDLE are advised to terminate the IDLE and
>    re-issue it at least every 29 minutes to avoid being logged off.
>
> You like cutting things that close?

Yes. In my professional capacity I need to add workarounds and so on. 
Privately I like to follow the protocol and expect the other guy to do 
the same.

> Do you really mean to say that your client increments its copy of 
> UIDNEXT every time EXISTS shows a new message (since UIDNEXT is 
> normally NOT presented except at SELECT time!), and then issues an 
> error message if a new message has a UID that is not .GE. that client 
> calculated value?

No. MSN/UID arithmetic. The following sequence is somewhat contrived, 
but it's short and I expect you get the idea:

S: * 1000 EXISTS
S: * OK [UIDNEXT 2001]
S: * 1001 EXISTS
S: * 1001 EXPUNGE
S: * 1001 EXISTS
C: a UID FETCH 2002 ENVELOPE

There is fallback code to handle unexpected UIDNEXT increases, but not 
decreases.

>> It's not a great matter, but I urge you to reconsider this. It is the 
>> reference implementation, after all.
>
> The protocol violation is the kludge to prevent IDLE from ever timing 
> out. Removing that kludge would be better, if only ********* would 
> fix its broken client.
>
> It's also not clear, given the definition of UIDNEXT, that it is even 
> a violation.  The text says "when new messages are added to a 
> mailbox, even if those new messages are subsequently expunged."  
> After all, no messages were actually added to the mailbox; the 
> EXISTS/EXPUNGE pair is a fake.
>
> OK, granted, that's a slimy argument to make, but no slimier than 
> other arguments made by other people in the past.  Don't I get to 
> wallow in the slime too, just once?  ;-)

I was going to say "can't you do that wearing your pine hat?"  but after 
a night's sleep I'm not so sure. Here are two different answers. My 
opinion is somewhere in between, wavering.

1. Your server is the reference implementation. As I understand it, a 
reference implementation is one that implements the protocol 
completely, accurately, meticulously, and above all, without dubious 
hacks.

2. Your server has moved towards being an ordinary IMAP server for many 
years. For example, there isn't any command-line option to serve 
IMAP4rev1 without extensions if a client wishes to test that that 
works. A bit of a hack in the name of interoperability does veeeery 
little additional harm.

But wouldn't it be better to extend the 30-minute timeout than to throw 
a spanner in the works of clients that do MSN/UID arithmetic?

Arnt

