Re: RENAME and imap compliance

[Cyrus Daboo]

It seems to me that the problem here is the requirement to keep the UIDVALIDITY the same when doing RENAME. That effectively forces the server to cache UIDVALIDITY for mailboxes for all time to avoid a clash.

I propose the following solution: remove that constraint and require the renamed mailbox to get a new UIDVALIDITY value as if it were simply being created. However, the message UIDs MUST remain the same and the server SHOULD return the new UIDVALIDITY in the RENAME's OK response or as an untagged response. This will allow the client doing the rename to simply change its cached uidvalidity value to the new one at the same time the mailbox is renamed, and avoids the need for it to rescan for UIDs - i.e. it provides the same benefit as the current state of affairs without forcing servers to keep track of old uidvalidities.

The only problem with this is the hierarchical rename because the uidvalidities on the child mailboxes will also be changed and I think it may be too much to have those new uidvalidities returned as untagged responses - particularly if the hierarchy is large.

Its worth noting that the current rename behaviour is only of benefit to the client actually doing the rename. Other clients that connect after the rename will have no knowledge of what happened and will be forced to do a full resync of their caches for the new state. That problem could be solved by having some form of global (mailstore-wide) UID for mailboxes and allow referencing of mailboxes in the protocol by the GUID. That is something that could be partially implemented via mailbox annotations, but really ought to be implemented as a dedicated extension.

--
Cyrus Daboo