On Wed, 22 Jan 2003, Cyrus Daboo wrote: > It seems to me that the problem here is the requirement to keep the > UIDVALIDITY the same when doing RENAME.
Where is that required? What's required is that the last-assigned UID has to be saved, unless the UIDVALIDITY changes. > 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. That's a way of solving the problem, since then the last-assigned UID becomes moot. > 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. Correct. And since this should be atomic, this can effectively lock the entire hierarchy for a substantial period of time while all this is being done. > 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. Yup. This is another issue that leads me to question the value of a RENAME in IMAP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
