Hi, On 29 Jan 2003 11:44:52 +0200, Timo Sirainen <[EMAIL PROTECTED]> wrote... > On Wed, 2003-01-29 at 08:18, Mark Keasling wrote: > > What is needed is an easy way for the server make the unique identifier > > guarantee while still permitting the user to rearrange things. A mailbox > > name is not a guaranteed unique identifier. It should be removed from > > the unique identifier equation. In its place, use a value that unlike > > the mailbox name is completely controlled by the server. > > 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. Removing or changing the behavior of existing protocol causes such incompatibility. The idea is to fix the protocol while at least maintaining the status quo for installed base. Any change must take into account the mix of old clients, old servers, new clients and new servers. 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. > If it wasn't for the requirement of growing UIDVALIDITY, that itself > could be used as the unique identifier. Most (if not all) clients would > likely handle lower UIDVALIDITY just as well as higher. > > The whole issue is really rather just theoretical, I doubt this has > caused many problems with users. I'd want it fixed in any case though :) I doubt that there has been a significant impact. However, it is a "hole" of sorts in the protocol and may exploited one day in a way no one has thought of yet. The issue may be theoretical; but such things have a way of causing significant inconvenience when you least expect it. In reality though is the issue big enough that there is enough momentum to fix it. There are two related issues. Your NEW-VALIDITY tag addresses one issue. Namely that of notifying the client of the mailbox's new validity value which changed as a result of rename and that of the renamed mailbox having a validity value and set of uids which violate protocol requirements. You are changing the validity value in an attempt to prevent the second issue from occuring which creates the need for client notification. I'm proposing a permanent id tag which if proves to be a reasonable solution would eliminate the possiblity of uid ambiguity. The id is unique on the server, never changes and stays in the mailbox regardless of how many times the name is changed. But it is only an idea. It looks to me like it may solve the problem as I understand it. It does not replace the need for a NEW-VALIDITY tag if the mailbox's validity value changed as a result of rename. Newer clients that recognize the id can use it for safer offline caching. They can not be caught offguard if a newly renamed mailbox happens to end up with the same name and validity value of an old mailbox that the client knew of but didn't know was gone because the server must guarantee the permanent id to be unique. The problem of mailboxname:validity:uid refering to multiple messages after a rename occurs is corrected by the replacement of non-unique mailboxnames with a unique permanent id. Old clients which don't recognize the id are already required to ignore it. They are stuck with the current status. The updated protocol is "fixed" and old clients aren't broken in the process. Having a permanent id associated with a mailbox might be less intrusive to a server's design and have less impact on its performance than requiring the server to try to update the validity values of all of the mailboxes in a renamed hierarchy just because there is a chance that one of mailboxes may end up duplicating a mailboxname:validity pair in a way that some day causes a disconnected client to have a bad cache day. Of course, it could also be impossible to implement in a reasonable fashion. My assumption is that if the mailbox already contains the validity value which is updated periodically, is it difficult/impossible to add an additional value to hold a permanent id that the server assigns when the mailbox is created? Regards, Mark Keasling <[EMAIL PROTECTED]>
