Hi, On 28 Jan 2003 01:38:04 +0200, Timo Sirainen <[EMAIL PROTECTED]> wrote... > Since the previous thread seems to have died without agreed solution, > let's try again :) > > I don't think it's such a good idea to deprecate RENAME entirely like > Mark wants. Doing it with copy+expunge would require user to have enough > quota for a copy of the mailbox (doing it in smaller blocks would be > even more annoying), renaming large hierarchies could be even more > slower, and then there was the annotation problems. > > So, what about the UIDVALIDITY notify? I like that, it breaks nothing > and would allow clients supporting it to keep their message cache. > > x RENAME foo bar > x OK [NEW-UIDVALIDITY 123456] Renamed. > > If foo had children mailboxes, they'd all be updated to contain the same > UIDVALIDITY.
This is not as useful as you may think. If the UIDVALIDITY is changed what prevents the server from changing the UIDs as well. Just getting the UIDVALIDITY is not sufficient. After rename, a client should not make any assumptions about the mailbox and treat if as if it were new. Expecting certain server behavior limits the way a server can be implemented. Servers should be implemented in the most efficient means possible which is often dependent on the design of the mailstore. A client has no idea about the mailstore otherthan was is made visible by the IMAP protocol it is not reasonable to have expectations beyond what is defined in the protocol. The procotol says nothing about the mailboxes' uidvalidity or the uids of the messages after a rename is completed so a client has no business making any assumptions. Just because some servers behave in a certain way does not mean the all servers will exhibit the same behavior. Regards, Mark Keasling <[EMAIL PROTECTED]>
