On Thu, Sep 02, 2004 at 11:29:44AM -0700, Kevin Baker wrote: > In reviewing the rfc, there is *no* "increment-only" > requiment in the rfc as defined in the current dbmail > implemenation. > > (detailed in earlier messages from this thread.) > > There are unique_id's detailed in the past messages... > > -and- > > message-ids which are as you said increment-only or > sequential per mailbox. However they can change per > session, meaning they are not static id's. The rfc > basically explains that they can change each > request/session, meaning they are really just the current > sequence in the mailbox. > > Because of this we were discussing just generating the > message-id's on client request from the imap server and > removing them from the schema. They would essentially be > just the sequence number of a message within its mailbox > generated on the fly with the client request. If the > sequence changes during mailstore syncing, they are > reordered on the next request. This seems completely > consistant with the rfc. >
Ok, I just read seciont 2.3.1.1, Unique Identifier (UID) Message Attribute, from rfc 3501 (yes, I should've read it before chiming in on this thread), and you are correct, the unique identifier SHOULD NOT change across sessions, but may. Although the rfc STRONGLY ENCOURAGES that IMAP implementations maintain UIDs across sessions, it allows implementations to change the UIDs each session. But, as the rfc points out, Persistent unique identifiers are required for a client to resynchronize its state from a previous session with the server (e.g., disconnected or offline access clients); this is discussed further in [IMAP-DISC]. It would be a shame to not support offline access. We still must come up with a method to generate message id's during a single session such that they always increase. As the databases can synchronize during an IMAP session, injecting new messages into a mailbox, the new messages must have ever increasing UIDs. This may require having a session table to map message IDs in the database to the session's UIDs. Each IMAP daemon would only need to access it's own table, so it need not be replicated or even be in the RDBMS. I still look forward to someone coming up with a clever way to maintain ever-increasing UIDs across sessions. xn
