[Imap-protocol] Concurrent Mailbox Changes.

Mark Crispin mrc at CAC.Washington.EDU
Sat May 26 08:09:26 PDT 2007


Note that the inventor of IMAP disagrees with the very last sentence of
Timo's message (see below). He thinks that the preferred order of
behavior is:
(1) which everybody thinks is the best
(5) which at least maintains consistant protocol state
(4) annoying to users, but doesn't violate protocol state
(2)/(3) which mislead some clients, breaks others, and
violates protocol state,

As far as the inventor of IMAP is concerned, (1) and (5) are the ONLY
acceptable choices.

On Sat, 26 May 2007, Timo Sirainen wrote:

> This is discussed in RFC 2180. Summing up your possibilities:

>

> 1. Keep the message around until there are no sessions that see it. This

> is the preferred behavior.

>

> 2. Give some dummy replies for the message. Such as empty flags, and

> other fields being NILs or whatever is legal for the field. The downside

> to this is that it violates the IMAP protocol if the client had already

> asked something about this message.

>

> 3. Don't return the FETCH reply for the message at all and return a

> tagged NO reply. Doing this makes some clients ask the same message

> range over and over again infinitely. This could be avoided also:

> http://mailman1.u.washington.edu/pipermail/imap-protocol/2006-September/000=

> 281.html

>

> 4. Disconnect the client anytime you can't handle the request. I used to

> do this but it was annoying when it happened.

>

> 5. Don't allow EXPUNGE until there's only session. I think this is the

> worst of the possibilities.


-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.



More information about the Imap-protocol mailing list