On Tue, 17 Jun 2003 07:08:00 -0700 (PDT) Mark Crispin <[EMAIL PROTECTED]> wrote:
If UIDs do not persist in a mailbox, then STATUS should return a higher
UIDVALIDITY value than any previous UIDVALIDITY returned for that mailbox
(including a previous STATUS command).
It's not that obvious. At least, not for my brain.
The same STATUS could return UIDNEXT, which may change during the next STATUS poll, but still - why should we generate new UIDVALIDITY for each STATUS? BTW, what should the STATUS UIDNEXT command return if the mailbox does not keep UIDs?
Yes, assigning new UIDVALIDITY every time solves all those problems (i.e. it does not matter what STATUS returns for UIDNEXT), but believe me or not, there are too many clients that connect, check the mailbox status (some use STATUS, some even use SELECT), and disconnect - and do this VERY often (several times per second) :-(. Changing UIDVALIDITY for each of those polls is either unsafe (one can run out of 32-bit values very quickly), or impossible (if the server uses the timer value in seconds).
On the other hand, it's a bad client accessing a bad mailbox, so - who cares, and I'd vote for your clause: "any previous UIDVALIDITY returned for that mailbox
(including a previous STATUS command)".
BTW, you DO have definitions for UIDVALIDITY (and UIDNEXT) - I've overlooked them :-( -
--
Associated with every mailbox are two values which aid in unique
identifier handling: the next unique identifier value and the unique
identifier validity value.
---
But it's still better to specify that they are integer positive 32-bit values - right there.
Hence the suggestion of using a 32-bit time value (unsigned), which won't expire until 2106 so none of us will need to worry about fixing it.
You never know :-)))
-- Mark --
Sincerely, Vladimir
