(Rats... I sent this to the IMAP Extensions list first. Here it is again, to the correct list.)
> 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. Yes, I think that's what Timo is proposing. > 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 Why? NEW-UIDVALIDITY doesn't exist now; Timo is defining it. As such, Timo gets to propose the definition as HE wants it, not as the proverbial lazy implementer might want it. I think he's proposing this: 1. If the server can do this reasonably (for some value of "reasonably" that's up to the server to determine), it MAY leave the UIDs of the messages unchanged and send back a NEW-UIDVALIDITY value in the response. 2. If the server chooses not to do (1) because it's unable to guarantee that the UIDs have not changed, or because the process is, for whatever reason, not deemed to be "reasonable", then it MUST NOT send back NEW-UIDVALIDITY. 3. In any case, the server MUST meet the current requirements for setting the UIDVALIDITY value of the new mailbox. 4. If the client receives NEW-UIDVALIDITY, it MAY use that information to keep its cache valid, without having to refresh it from the newly renamed mailbox. 5. If the client does not receive NEW-UIDVALIDITY, does not understand it, or, for whatever reason, chooses not to handle it, it MUST treat the newly renamed mailbox as is required now. It will see a mailbox with the new name and with a UIDVALIDITY value that it has not yet encountered (because of (3) above). It MUST, therefore, treat it as a new mailbox, discarding anything it thinks it already knows about it. Timo, please correct me if I've misstated anything here, or missed anything. I think this is a reasonable approach, giving the server the option of improving the situation, and giving the client a chance to behave more efficiently when a mailbox is renamed, but not breaking any existing implementations nor requiring anyone to change if they don't want to. It does not address any of Mark's other issues with RENAME, of course, and for implementations that must deal with mailstores that expose those issues, this is a real problem. I suppose a server can always respond "NO" to any RENAME command, and thus require the client to use alternatives, but I suspect that most clients would just expose the "NO" to the user, and make the user deal with it. I would support a move to change the new IMAP draft to suggest that a server that has trouble with RENAME MAY say "NO", and that a client that receives a "NO" to RENAME SHOULD try the CREATE/move alternative before exposing the failure to the end-user. Maybe we should define a response code to go with the "NO", � la "TRY-CREATE", that would give a savvy client a hint that the server doesn't like RENAME and wants the client to try alternatives. The reason I don't want to deprecate RENAME outright is that for many servers it IS a reasonable thing to do (though, yes, most (all?) servers do not implement it strictly according to the spec; it'd be nice to have that fixed). Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba
