Re: Communciator 4.02 Imap EXPUNGE problem

[Mark Crispin <[e-mail]>]

On Mon, 25 Aug 1997 16:18:38 -0400, Eric Rizzo wrote:
> I think some sort of
> "Implementor's Guide" would be an invaluable tool for people/groups
> trying to make clients and servers that are as inter-operable as
> possible.

I agree.  But I am skeptical about the feasibility of doing it.  Much of what
would go into an such an "implementor's guide" involve matters that some would
consider to be religion.  I am increasingly reluctant to make such
recommendations.

Nevertheless, in the absence of that document (which I really hope will come
to be) here's a few notes that I've put together of fundamental principles
that I think would make the IMAP world a Much Better Place:

Server implementations:

If something is in the base specification, and is not specifically labelled as
being "implementation dependent" or "optional", then it is a requirement.
Don't take shortcuts.  If a size is called for in the spec, then that exact
size, not an estimate, is required (I realize that this is a burden on some
mail stores).

Client implementations:

Make a good attempt to understand IMAP and the design principles behind it.
Be sure to read RFC 1733.  It is very important to understand the difference
between the "disconnected" and "offline" models.

Nor should the "online" model be neglected; it is very important in the IMAP
world to get your online model right because that is what most IMAP users use.
Do not try to force a disconnected or offline view on an online user.

Survey other IMAP clients, especially those that have been around for a long
time.  There may be valuable lessons to learn in what to do (and what not to
do).

IMAP is not just another POP.  A POP client that is hacked to babble IMAP
protocol will not be a very good IMAP client.

Beta test early.  Be alert for problems.  If a long-time IMAP user indicates
that he can not (or will not) use your client, then it's very important that
you understand why.  Your client should work well with any user's environment,
so that client choice is a matter of esthetics only.

In those instances where IMAP very clearly puts forth a model of how the world
works, be extremely careful in defying it.  An example is the delete+EXPUNGE
model.

Keep scale firmly in mind.  [Managers: unplug your client developers' Ethernet
connection and make them use a 2400 bps modem during development.].  What may
seem cheap in testbeds can be disasterous in real life.  Examples:
 Bad Thing to Do			Situation When It Becomes Bad
 ---------------			-----------------------------
 A01 FETCH 1:* FULL			10,000 messages in the mailbox
 A01 LIST "" *				100,000 mailboxes.  Looping hierarchy.
 A01 FETCH 1 RFC822			message is 80MB
Try to do the minimum needed to accomplish the task at hand:
 1) Instead of doing FETCH 1:* FULL to load your browser, fetch only those
    messages which are visable in the scrolling view.  Consider using ALL
    instead of FULL at browser load time unless you really need to know about
    MIME attachments.
 2) Instead of LISTing *, use % and have a widgit to descend the hierarchy on
    user command (as in the Mac and Microsoft file browsers).  * is best
    reserved for special purposes, e.g. newsgroups.
 3) Use selective header and body part fetching unless you really need the
    full RFC822 message.

I have tested many clients.  There is an order of magnitude difference between
the slowest and fastest IMAP clients.  Always, the slow client did something
that doesn't scale well, and a fix to that behavior would have helped it
enormously.

Use aggregate IMAP sequences whenever possible, particularly on STORE (don't
do a hundred STOREs when one aggregate STORE for 100 messages will work).  In
FETCH, it may be a good idea to limit a FETCH to the size of your browser
window.

If you find yourself doing a great many IMAP commands to accomplish a single
task, you should recognize that something is wrong.  Try to find out what that
something may be.

Be prepared for the worst.  If the specification does not specifically require
a server to offer something (e.g. non-INBOX mailboxes, Kerberos, multiple
simultaneous access to the same mailbox) you should make sure that your client
works well with servers that do not offer it.  If the specification indicates
that something may be slow (e.g. STATUS or CHECK), you should make sure that
your client works well with servers where it is very slow.

Adhere strictly to IMAP syntax.  If the specification requires a CRLF, then
you should send a CRLF and not assume that an LF will do.

-- Mark --

PS: I'm really serious about the 2400 baud modem suggestion, by the way.  It's
a great learning experience -- if you have a good IMAP client, it will work
well at 2400 baud.  I know, from personal experience, that Pine and
MailManager (my old NeXT GUI client) are considerably faster at 2400 baud than
certain GUI clients on a Pentium connected via an Ethernet.

2400 baud is a great simulation of a heavily-loaded environment, and also will
prepare you for the sorts of things that you will need to do for IMAP over
radio.