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

