MBOX-Line: From mbarker at buni.org  Thu Jun  7 08:36:05 2007
To: imap-protocol@u.washington.edu
From: Michael Barker <mbarker@buni.org>
Date: Fri Jun  8 12:34:39 2018
Subject: [Imap-protocol] Concurrent Mailbox Changes.
In-Reply-To: <alpine.OSX.0.99.0705260804430.3501@pangtzu.panda.com>
References: <46581509.7050201@buni.org> <1180182602.32181.1919.camel@hurina>
	<alpine.OSX.0.99.0705260804430.3501@pangtzu.panda.com>
Message-ID: <1181230565.6639.15.camel@mike-laptop>

On a similar note, what is the preferred behaviour when another client
expunges a mailbox, then new messages are added?  Should the EXISTS
response, indicating new message, be sent straight away or should it
wait until after the server has sent the EXPUNGE response?

Regards,
Michael Barker.

On Sat, 2007-05-26 at 08:09 -0700, Mark Crispin wrote:
> 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.


