Re: Communciator 4.02 Imap EXPUNGE problem

["Barry Leiba, Multimedia Messaging" <[e-mail]>]

On Mon, 25 Aug 97 13:06:34 -0700 Mark Crispin <[e-mail]> wrote:
> But, it assumes that when the official, documented, mechanism fails, an
> unofficial and undocumented alternative will work in a defined manner.

There are often multiple, valid ways of doing things.  In the absence of a 
statement to the contrary, and because the IMAP spec give one a strong 
reason to believe that multiple clients can connect to the same mail store, 
this is a reasonable assumption -- that's all I'm trying to say.

> SEARCH is an excellent example in which one may want to do a FETCH in the 
> mean time.  It is what section 5.5 envisions.  My personal belief is that 
> client implementors should lobby to get section 5.5 supported in servers 
> with a non- instantaneous SEARCH.

Absolutely -- I agree with this completely.

However, the facts are that servers don't support this now, that even when 
they do there's no way the client can know whether the server does or not, 
and that it's easier for both the client and the server to code it the 
other way.  My server (a research project, not a product) will not process 
concurrent commands, but will happily handle the selection of the same 
mailbox from two (or more) sessions.  It's also easier for a client to deal 
with the responses on separate sockets than intermixed on the same socket, 
especially in the general case.  This is partly because of the untagged 
response thing... if all responses were tagged to indicate which command 
caused them, and untagged responses were reserved for asynchronous 
communications, it would be much easier to implement this on the client 
side.

Perhaps we should add a CAPABILITY token for this -- some token that the 
server returns in the CAPABILITY response that indicates its support for 
multiple concurrent commands in the same session.

> EXPUNGE is a different can of worms.  You have sequence numbers changing.  A
> message can disappear out from under the client.  UID FETCH is much 
> more practical than FETCH in this case, but you still can have messages
> disappearing.  Lots of clients have had real problems with this!

A *message* can disappear, but a sequence number can't.  And a well written 
client can avoid problems in that area.

> Many mail stores require an exclusive lock when doing an EXPUNGE (either
> refusing an EXPUNGE when the share count is greater than 1, or blocking all
> sharers until the EXPUNGE is complete).

Those tend to be the mail stores on Unix file systems.  That's the past, 
but not the future; more and more, mail servers are being deployed with 
database back-ends, and they can deal with this situation well and 
efficiently.  This isn't to say that clients should ignore these concerns; 
quite the contrary -- this is precisely *why* I think there needs to be a 
statement somewhere about this issue.

>  1) multiple server processes can select the same mailbox, and it is not
>     detrimental (e.g. kill other server behavior) to attempt to do so.
>  2) EXPUNGE is permitted while another process has the mailbox selected.
>  3) EXPUNGE does not block other processes which have the mailbox selected.
>  4) the message being fetched can't be expunged in mid-FETCH
>  5) EXPUNGE takes enough time that a performance benefit would be realized
>     by doing it.
> I know of no servers in which all of the above are true.

I do.  More than one.  They use database back-ends.

> There are extant mail stores which do not (can not) permit multiple
> simultaneous access to a mailbox.  This isn't something that a server
> implementor can do anything about.

I understand, and let me stress this:  I am *not* in any way disparaging 
anyone's server for not supporting this sort of thing.  Again, this is 
exactly why something needs to be said about it -- because someone 
implementing a client and testing against servers that use  more flexible 
back-ends might be unaware of the problems associated with using those 
kinds of mail stores.

> It may be reasonable to add something at SELECT (and maybe also STATUS) time
> to report whether or not that mailbox offers multiple simultaneous access.

Yes; perhaps another untagged OK response, along the line of
   * OK [MULTI] Multiple simultaneous accesses are allowed on this mailbox.

> But, I consider it to be much more important to press ahead of deploying 5.5
> if client implementors really want this capability.  That is what the 
> protocol defines as what should be done, and that is what people should be
> implementing.

Yes.
Nevertheless, if you want to deprecate a client behaviour that clearly is 
following the protocol and that "on the surface, [...] seems reasonable", 
then you need to do it somewhere where the client implementers are going to 
find it.  It's not reasonable to assume that they will test their clients 
against your server and will happen to use one of the two (of the nearly a 
dozen) mail stores that show the problem.  But a few words in an 
"implementer's guide" document warning that clients that assume that they 
can do this will run into trouble under certain circumstances... would be 
more useful.

Barry Leiba, Multimedia Messaging  ([e-mail])
http://www.research.ibm.com/people/l/leiba