[imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

[Adrien de Croy <[e-mail]>]

Seems to me we're getting bogged in the implementation details, or at 
least going too far down that path.  We don't even have a clearly 
defined set of objectives for the features we want the protocol to provide.

here's my first cut off-the-cuff list:

* mail access
for obvious reasons.

* mail submission
For reasons I've stated already including ease of administrative and 
configuration and support.  This breaks down into:
- composing messages on the server
- providing delivery information (e.g. destination address)

* storage of mail client configuration
So that clients can be dumb, and you can hook a new client to your 
mailstore and you don't need to configure anything else.

* server-side mail processing rules
Save downloading headers + MOVE etc to process filtering rules.  Also 
saves synchronising such rules amongst multiple clients

* ability for server to "comment" on anything, e.g:
- that destination email address you gave me doesn't resolve (with MX or 
A) or is otherwise bad.
- that attachment you uploaded contains a virus
- that subject is offensive...
- etc etc etc
this could be part of a broader notification framework.  In the cases 
where the IMAP server co-exists (as in WinGate for example) with SMTP 
delivery agent, then delivery information could be communicated back to 
the connected client.  If we allow for it in the protocol, it can 
provide benefit where it's available, and causes no issues if it isn't.  
The general idea though is that anything should be able to be remarked 
upon by the server.

* address book
* calendaring
* Any other feature to compete with Exchange.
* Any other feature we think would give us an edge.

In terms of design, I'd propose the following:

* single port.  This minimises problems traversing firewalls etc.
* ability to access all mail (in all folders) through a single 
connection, and receive notifications about all state changes to 
anything of importance (probably with client-controlled filter)
* layered protocol.  Bottom layer deals with connection security (e.g. 
negotiating TLS) authentication, and advertisement of and connection to 
sub-services.  Next layer are the sub-services e.g. mail, calendar, 
config etc.  This eases gateway development, since a calendar gateway 
can simply connect through to the calendar sub-service.
* compact yet extensible protocol message structure.

The debate of text-based vs binary protocols will forever rage, I tend 
to prefer binary, since then you don't need to parse text which requires 
escaping of characters which would otherwise be protocol delimiters.  
Some of the downsides of text-based protocols can be averted by using 
length prefixes instead of searching for (and therefore needing to 
escape) delimiters.  Even a mixture.  Literal+ is a damn good design in 
my view, since it allows a large literal to be transferred without it 
having to survive parsing.  It also allows any character set to go 
through.  HTTP is a nightmare in this respect.

* configuration attributes to be clearly defined (e.g. take a page from 
various MIBs) so that attributes can be re-used between different 
clients to the maximum extent.  Clients can store arbitrary 
configuration attributes against the mail account.


Regards

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/