Simon Josefsson wrote: > Andreas Aardal Hanssen <[EMAIL PROTECTED]> writes: > > > On Wed, 22 Jan 2003, Alexey Melnikov wrote: > >>> RENAME, on the other hand, is broken on almost all servers. > >>Maybe. But it is not impossible to fix RENAME in servers staying complaint > >>with IMAP4rev1. > > > > Compliant is one thing, but bumping UIDVALIDITY for source and destination > > mailboxes when renaming means that most offline clients have to re-scan > > the folder and download headers. > > > > Which means that RENAME in practise will be _slower_ than > > create, copy, delete. So why do we need RENAME? > > Not all clients are offline clients, so not all clients need to > perform the re-scan.
So, if the server doesn't bump UIDVALIDITY, the disconnected client doesn't have to rescan. And finally, if the server doesn't support UIDPLUS, the disconnected client has to perform rescan after COPY anyway. > >>And I don't buy the argument that a server can't store 4bytes UIDVALIDITY > >>somewhere when mailbox is deleted/renamed. > > > > Do you understand the problem with UIDVALIDITY and RENAME? Not only do you > > have to store your 4 bytes, but you will have to store all UIDVALIDITY > > values that any folder has had ever, after renames, forever. This is to > > prevent the situation where the same UID/UIDVALIDITY points to two > > different messages at two different times. > > Assuming the UIDVALIDITY value must grow, as the specification says, I > guess you only have to store the highest last used one. This seems > like a rather trivial thing to implement, compared with all other > complex things in IMAP. Exactly. > But I agree that the current situation is no good. Either clarify the > document, or if doesn't seem possible to do so, remove RENAME. I agree. I was just arguing than the first can and should be done. I know several clients that use RENAME. Alexey
