Re: [Imap-protocol] If Crispin were creating IMAP today how would it be different?

> human readable text protocol is still a very good idea since it makes it easier to debug just by logging input/output of the protocol.

Binary can be transformed to text easier than current "text"-flavoured
formats. It is possible to open any major encoding in good text
editors, or convert between encodings via libraries for display in
browser. Binary however is much easier to interpret in code than text.
Current standards (i.e. case insensitive commands, mixture of
encodings within a single text block, injection of CRLF which is not
part of the text), complicate interpreting a lot. It also consumes a
lot of CPU resources - visibly.

SMTP protocol would benefit from a few very clear (as in: explicit
sequence of bytes) instructions and explicit expectations about each
immediate payload: what follows (type, encoding), what byte length is
expected.

Email server does not need to guess: is it over yet? how much more to
expect? It needs to know with each command, what payload to prepare
for. It does not need to analyze / parse each line of the content as
it trickles in.

Something like this:
n1 bytes: command
n2 bytes: args (type: header, body, mime, etc)
n3 bytes: length
n4 bytes: content

both the specs and the code would be a few times shorter than what
they are with the current standard.

no guesswork.
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol