Re: [Imap-protocol] Missing UIDNEXT during mailbox synchronization
Michael M Slusarz <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <20121228130129.Horde.VTgbGtjlIvg0wUwlkp5dDg6@bigworm.curecanti.org> |
Quoting Bron Gondwana <[email protected]>: > And yet: > > B. Changes from RFC 2060 > > 34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT > responses in SELECT and EXAMINE. They are required now, but weren't > in older versions. > > Sounds like it's supposed to be there in 3501. Also listed with REQUIRED. Agreed that some (most) of the text indicates that this should be required. But the text I quoted previously explicitly indicates that UIDNEXT might not be available. So there is, at worst, an ambiguity. From a practical perspective: at least one (somewhat widely used) IMAP server fails to issue the response, so a competent client should be able to work around its absence regardless of whether it is semantically incorrect. >> For cache purposes, you can workaround a missing UIDNEXT response by >> doing a 'UID FETCH * (UID)' in the mailbox. > > Ouch. I assume this means this is a slow operation server-side (at least in Cyrus). I personally don't care since it is a viable way of working around a possible RFC violation. Performance isn't an issue here. >> For empty mailboxes, use >> the returned UID value (which is defined as the UIDNEXT value). >> Otherwise, you can add 1 to the returned value and use this as the >> UIDNEXT-ish value. > > The more interesting question is: what do you need to know it for anyway? To determine if the mailbox has changed to prevent an issuance of an unneeded FETCH/SORT command. Flag changes are irrelevant (if CONDSTORE isn't available), since clients can be designed to not care about these changes michael _______________________________________________ Imap-protocol mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol