Hi, On 28 Jan 2003 10:01:16 +0200, Timo Sirainen <[EMAIL PROTECTED]> wrote... > On Tue, 2003-01-28 at 09:42, Mark Keasling wrote: > > > x RENAME foo bar > > > x OK [NEW-UIDVALIDITY 123456] Renamed. > > > 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. > > It would be, if that NEW-UIDVALIDITY tag was standardized. That was the > pretty much the point of the mail, there's no use writing the code if it > never gets into any standard.
The new-uidvalidity tag would only indicate the case were the uidvalidity was changed (or perhaps not changed) and the uids were preserved. It would not say anything about the other cases where the uids changed. The client should not be making any assumptions in any case. If you give the client the new uidvalidity and old uids, when it doesn't get that information most likely the client being lazy will assume that neither changed. This could lead to some nasty suprises and finger pointing when the validity didn't change but the uids changed in a way that breaks the client. The protocol makes no guarantees about the state of the mailbox after a rename other than the tuple name:validity:uid will be unique for any message ever contained by that name. A partial guarantee of the state of the mailbox after a rename should not added to the confusion. > I think I'll anyway implement the UIDVALIDITY changing the way I said > before, at least that makes sure the RENAME can't break things. > Announcing the NEW-UIDVALIDITY isn't that important, it would only be a > way for clients that support it to know that the UIDs were left > untouched even while UIDVALIDITY was changed. When implementing a server, implement in the way that is most efficient for your mailstore. As long as you adhere to the protocol, clients "shouldn't" have any difficulty. From the server side, you shouldn't need to worry about what some client may or may not be caching or what may happen with broken clients; but back in reality, it may be wise to keep in mind the limits of your audience... Regards, Mark Keasling <[EMAIL PROTECTED]>
