60 lines
2.6 KiB
Plaintext
60 lines
2.6 KiB
Plaintext
MBOX-Line: From dave at cridland.net Tue Mar 20 15:22:44 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: Dave Cridland <dave@cridland.net>
|
|
Date: Fri Jun 8 12:34:48 2018
|
|
Subject: [Imap-protocol] [ann] lua imap server
|
|
In-Reply-To: <C6227176-73D4-455D-91D1-601384A7591E@mac.com>
|
|
References: <CBFD9662-269A-4573-8EF1-E07E7BE4671C@mac.com>
|
|
<20120319204645.GA2859@launde.brong.net>
|
|
<E9A1A407-E02D-4FE8-82EC-B5DDC8F0EDE2@mac.com>
|
|
<17068.1332195426.345309@puncture> <17068.1332235633.171765@puncture>
|
|
<C6227176-73D4-455D-91D1-601384A7591E@mac.com>
|
|
Message-ID: <20897.1332282164.343400@puncture>
|
|
|
|
On Tue Mar 20 21:33:37 2012, PA wrote:
|
|
> Thanks for the feedback though as I have to confess that sometime
|
|
> both the letter and the spirit of the protocol escapes me. Talking
|
|
> it through helps :)
|
|
|
|
Also, read the original IMAP RFCs. They're much more vague than the
|
|
newer ones, but they do give a much better insight into what the
|
|
protocol is trying to do. Unfortunately, the later RFCs concentrate
|
|
more on the mechanics and less on the model.
|
|
|
|
Loosely, a client selects a mailbox, and then you send it arbitrary
|
|
data about the mailbox whenever you feel like. The client uses this
|
|
information to update and fill its cache.
|
|
|
|
Certain things, though, you must tell the client about - particularly
|
|
mailbox size changes, although as you've noted, expunges can only be
|
|
sent when the client won't get confused.
|
|
|
|
A client may ask for specific data (via FETCH), and the server
|
|
responds (with a tagged OK) once this has been sent. I seem to recall
|
|
that (very) early servers were allowed to simply respond with OK if
|
|
the data had already been sent - that is, not send data twice even if
|
|
asked explicitly.
|
|
|
|
The modern protocol requires that if you're asked for data (via
|
|
FETCH), you must then send it, even if the client really ought to
|
|
know the data already. This makes the protocol less confusing,
|
|
particular for those of us trying to test things on telnet, but it
|
|
makes the protocol look like a request/response protocol, which it
|
|
isn't - conceptually, the FETCH command and its response, and the
|
|
data that the server sends via untagged FETCH responses, are
|
|
unrelated - with the single exception that the server has been
|
|
requested to send them.
|
|
|
|
It might be better to imagine that untagged traffic is sent through a
|
|
different connection - you'd then see the model more clearly, perhaps.
|
|
|
|
But I'm waffling...
|
|
|
|
Dave.
|
|
--
|
|
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
|
|
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
|
|
- http://dave.cridland.net/
|
|
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
|
|
|