> On Fri, 2005-05-27 at 10:51 -0700, Kevin Baker wrote: >> Thanks for the explination I totally understand now. >> >> That being said, what is the actual harm in one message >> id >> being even a second off for the UID. They will both be >> entered in the mailstore, even if they are slightly out >> of >> order. > > It matters because if a client sees a mailbox and the > highest UID is 287 > and UID 286 comes in later it will NEVER KNOW about UID > 286 which means > mail is lost and the user is confused. > > RFC2060 actually _encourages_ IMAP client authors to make > this > optimization.
Interesting I wasn't aware that mail clients do this. So most mail clients download new messages only when there is an id above the last check...? makes sense and enforces the reason for the sequence. Makes sense and enforces the reason for the sequence. >> Ultimately the Mail client will sort by the header >> information and if the clocks are different then they >> will >> be out of order. > > No. You're confusing Received-time and UID-time. Wasn't really confusing them just pointing out that the client does not sort by UID-time.. As you pointed out above not really relevant as the message would be lost if RFC is not followed. <snip: explanation of mail client behavior> >> I realize this might bend the RFC slightly... but the >> added functionality is great and it will not break any >> mail clients. I am all for complete RFC compliance, but >> if >> we are talking about a matter of a second here and there >> due to processor lag I think we are probably going >> overboard. > > No. It's a very serious violation of RFC2060. This > "optimization" breaks > client optimizations. It breaks _most_ mail clients in > very subtle ways. > Point taken, thanks for your clarification. This is the reason to bring these things up. Good explanations like this pop up in the forums an make it so that people who are less familiar with the RFC can understand. Also this sort of discussion is how this entire GUID for Load Balance concept came up to begin with. Revisiting misinterpreted RFC requirements. Kevin
