On Wed, 2003-01-29 at 14:05, Mark Keasling wrote: > > You're forgetting the most important problem: backwards compatibility. > > Introducing a new identifier wouldn't help at all if the clients didn't > > support it. > > I don't believe I'm forgetting anything... > Adding something to the protocol does not cause backward incompatibility.
No, but neither does it fix the issue with non-supporting clients. Server is still broken with them. > Changing the mailbox's validity value may break old clients that expect > it to remain the same even though you return the NEW-VALIDITY tag since > it will be ignored because the old client doesn't understand it. Clients must not expect that. UIDVALIDITY can change at any time the server wishes so, changing it wouldn't (or shouldn't) break anything, even if the NEW-UIDVALIDITY is never sent. > I'm proposing a permanent id tag which if proves to be a reasonable > solution would eliminate the possiblity of uid ambiguity. That would require that the UIDVALIDITY isn't changed, which would mean leaving the non-supporting clients broken. I don't think RENAME deserves much changes to protocol to be supported properly, just some way to let existing clients deal with it. If it got too complex, I wouldn't be against dropping the support for it entirely either.
