33 lines
1.3 KiB
Plaintext
33 lines
1.3 KiB
Plaintext
MBOX-Line: From imantc at gmail.com Sat Mar 7 08:40:26 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Imants Cekusins <imantc@gmail.com>
|
|
Date: Fri Jun 8 12:34:53 2018
|
|
Subject: [Imap-protocol] If Crispin were creating IMAP today how would
|
|
it be different?
|
|
In-Reply-To: <54FB22EB.7090707@lavabitllc.com>
|
|
References: <54FAEB94.4070508@lavabitllc.com>
|
|
<CAKHUCzzirU0YEQ02n1zEypZCvUJ+0dU0CuPxT=ZnowTk_R6jOg@mail.gmail.com>
|
|
<54FB22EB.7090707@lavabitllc.com>
|
|
Message-ID: <CAP1qinZgGpHLwmPQZ734id=avz98gBBcSdXYeL1uMxwnCF9vKw@mail.gmail.com>
|
|
|
|
Speaking of new protocols, implementations of new email protocols can
|
|
be made much easier for developers and faster for users if a switch
|
|
were made from text-based to binary formats.
|
|
|
|
With binary formats, parsing is greatly simplified. Case conversion
|
|
become unnecessary.
|
|
|
|
Specify expected data length as a number of bytes. CRLF, empty lines
|
|
lose any special meaning and become part of the text. No need for line
|
|
wrap or any text modification.
|
|
|
|
Commands and mime-types are exact binary sequence.
|
|
|
|
Encode all text as e.g. UTF-8 for transmission - here goes away back
|
|
and forth charset conversion.
|
|
|
|
Even if current command-response command sequence were kept - apart
|
|
from these simple changes, email servers would work faster and more
|
|
reliably.
|
|
|