47 lines
1.9 KiB
Plaintext
47 lines
1.9 KiB
Plaintext
MBOX-Line: From imantc at gmail.com Mon Mar 9 14:19:35 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Imants Cekusins <imantc@gmail.com>
|
|
Date: Fri Jun 8 12:34:54 2018
|
|
Subject: [Imap-protocol] If Crispin were creating IMAP today how would
|
|
it be different?
|
|
In-Reply-To: <B03452330F6149E180E449A493F28C2B@gmail.com>
|
|
References: <54FAEB94.4070508@lavabitllc.com> <54FBF289.3010202@psaux.com>
|
|
<7164.1425831184@parc.com>
|
|
<1425907661.1215497.237833469.1EDA571D@webmail.messagingengine.com>
|
|
<6506.1425915329@parc.com>
|
|
<B03452330F6149E180E449A493F28C2B@gmail.com>
|
|
Message-ID: <CAP1qinZdV1LW6XiWfqfk2A+TC6HsYsAWtT-KSffTNdOFqG_Tjw@mail.gmail.com>
|
|
|
|
> 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.
|
|
|