MBOX-Line: From tss at iki.fi  Fri Nov  3 07:28:10 2006
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] rfc4549
In-Reply-To: <14025.1162566286.648724@peirce.dave.cridland.net>
References: <1162561886.29374.42.camel@hurina>
	<14025.1162566286.648724@peirce.dave.cridland.net>
Message-ID: <1A340D24-AEB2-4646-B5DB-3415C574F584@iki.fi>

On 3.11.2006, at 17.04, Dave Cridland wrote:

> On Fri Nov  3 13:51:26 2006, Timo Sirainen wrote:
>> Why does it suggest fetching new messages with <lastseenuid+1>:*?  
>> Hasn't
>> this been discussed already several times here that it'll return the
>> last message also, unneededly wasting bandwidth and server resources?
>> Wouldn't <lastseenuid+1>:2147483647 be a better solution?
>
> This will only happen if UIDNEXT has changed, but there are no  
> messages with a UID equal or higher than lastseenuid+1 - the  
> document clearly states that "[...] the former command should only  
> be issued if the UIDNEXT value cached by the client differs from  
> the one returned by the server."
>
> In turn, this can only happen if new messages have arrived but have  
> also been expunged, and there are still messages in the mailbox.  
> This is pretty rare - in general, users don't expunge all the new  
> messages only, they either don't expunge many or else they expunge  
> all the messages in the mailbox entirely.
>
> I suspect that your suggestion is therefore optimizing for a rare  
> case. (Even if it weren't, <lastseenuid+1>:<uidnext> would be better).

OK, this sounds better. I don't think most people have thought it  
this far though. The only reason I even asked about this was because  
some client developer asked me if my server was broken because it  
returned the last message, and then referred to rfc4549..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20061103/562e49d0/attachment.sig>
