[Chandler-dev] Chandler IMAP server parcel

[Grant Baillie]

On 10 Jul, 2006, at 13:43, Andi Vajda wrote:

> ...
>
>> In IMAP, a mailbox uid (a.k.a. "UIDVALIDITY value") has to be a  
>> non-zero 32-bit unsigned value. It's also supposed to be unique  
>> for the mailbox at that path (i.e. deleting & recreating the  
>> mailbox should give a new UID). So, a UUID (128 bits IIRC) won't  
>> work here: Most implementations use a timestamp (an increasing  
>> sequence of integers is also possible).
>
> Understood. I guess the word UID confused me.
>
>> However, as you point out, an initialValue isn't really required,  
>> either, and doesn't have the right behaviour w.r.t. deletion and  
>> recreation. Also, a random int could theoretically collide. Maybe  
>> the best thing is to override __init__ to make validityUID a  
>> computed value (like a timestamp).
>
> In that case, a random number can work or, the hash value of a UUID.
> hash(UUID()) is a 32 bit number.

It's probably a largely theoretical issue, since people don't  
typically delete & recreate mailboxes at a given path very  
frequently, but won't hash(UUID()) repeat values at some point?  
IMAP's uniqueness requirement (for clients to be able to sync a given  
mailbox without re-downloading the entire message list every time) is  
that the triple of (mailbox path, mailbox UID validity, message UID)  
uniquely identifies a given mailbox.

>> A similar comment applies to your comments about UUIDs for uidNext  
>> & UIDs: these also have to be 32-bit positive unsigned ints, and  
>> have the additionial requirement of increasing monotonically as  
>> messages are added to the mailbox.
>
> There, hash(UUID()) wouldn't work. The hash value cannot be  
> predicted with regards to its order and can be negative. Oh well.  
> Back to timestamps... with all the bugs that this may imply.

Some servers do this, but most just keep incrementing an integer to  
generate UIDs for messages in a mailbox.

--Grant