76 lines
3.1 KiB
Plaintext
76 lines
3.1 KiB
Plaintext
MBOX-Line: From dave at cridland.net Tue Sep 19 09:55:13 2006
|
|
To: imap-protocol@u.washington.edu
|
|
From: Dave Cridland <dave@cridland.net>
|
|
Date: Fri Jun 8 12:34:38 2018
|
|
Subject: [Imap-protocol] Avoiding connection-loss
|
|
In-Reply-To: <Pine.OSX.4.64.0609190849330.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>
|
|
<+zIRTx+YE8iB3/J6OY9jzQ.md5@libertango.oryx.com>
|
|
<Pine.OSX.4.64.0609190849330.368@pangtzu.panda.com>
|
|
Message-ID: <5290.1158684915.280900@invsysm1>
|
|
|
|
On Tue Sep 19 16:58:03 2006, Mark Crispin wrote:
|
|
> There's a problem with your example. UIDNEXT is only sent at
|
|
> SELECT time. It is not sent during UID FETCH or other routine
|
|
> operations. Also, there's no reason to believe that that UID FETCH
|
|
> would work; UIDNEXT is only a prediction and not a promise.
|
|
>
|
|
> So you can only be affected if you
|
|
> (1) keep a mathematical calculation of minimum UIDNEXT as a result
|
|
> of
|
|
> EXISTS
|
|
> (2) use that calculation between sessions.
|
|
>
|
|
>
|
|
True, all true. Except that Arnt is not the only one who uses the
|
|
property of UIDNEXT that it is at least 1 higher than the maximal UID
|
|
ever used, and usually precisely that - as in, it will increase by
|
|
precisely one on the addition of any message, and will never decrease.
|
|
|
|
I certainly use a combination of UIDNEXT values and counted EXPUNGE
|
|
messages to detect whether there have been unwitnessed EXPUNGEs
|
|
between SELECTs.
|
|
|
|
|
|
>> 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.
|
|
>
|
|
> It would be easy to achieve this. Elect me Dictator of the World,
|
|
> so I can outlaw broken IMAP clients that make such kludges
|
|
> necessary!! As Dictator of the World, I promise a world of only
|
|
> perfect IMAP! ;-)
|
|
>
|
|
>
|
|
I'll mention it to NOMCOM.
|
|
|
|
> But the question is if any client is actually affected. As noted
|
|
> above, UIDNEXT is only sent at SELECT time.
|
|
|
|
I think mine might be under certain circumstances. I don't think it
|
|
would actually choke, but I believe it might cause an additional
|
|
round-trip that proved to be a waste of effort. It'd almost certainly
|
|
pipeline a UID SEARCH with the terminating DONE, in any case, and
|
|
then it would generate another - I think - on a subsequent SELECT of
|
|
the same mailbox.
|
|
|
|
I have to say that I'm generally unconvinced if timeouts of this
|
|
nature are the correct thing to do anyway. I think maybe sending
|
|
untagged OK responses and seeing whether they work, and do not block,
|
|
might be a more useful thing to do, but I fully admit to not having
|
|
thought this through.
|
|
|
|
Dave.
|
|
--
|
|
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
|
|
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
|
|
- http://dave.cridland.net/
|
|
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
|
|
|