‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, August 27, 2020 12:21 AM, Grant Taylor
<gtay...@gentoo.tnetconsulting.net> wrote:
> email email email
> SMTP SMTP POP3S/IMAPS
> A) [1]---(TCP)---[2]---(TCP)---[3]---(TCP)---[4]
>
> Now what you are proposing:
>
> email email email
> TBD TBD TBD
> HTTPS HTTPS HTTPS
> A) [1]---(TCP)---[2]---(TCP)---[3]---(TCP)---[4]
>
> The number of layers has increased from three to four.
that's true if "SMTP" is a single layer.
which is also how networking engineers including
those highly skilled ones in standard bodies
commonly commonly talk about protocols (e.g. based
on layers of that sort). so i see why it makes
sense that you did it this way.
but i this way of looking at protocols (despite
being common) is wrong. i also disagree with the
network layering proposed by osi or the other ones
commonly published in books. i specially disagree
with using such layering for studying the
complexity of protocols.
so i suggest that if we want to study the
complexity of messaging systems, we better not
count SMTP as a single thing (like how it is
normally done in books and talks), but instead
talk about it based on the fundamental tasks that
it actually does. this way, SMTP becomes at least
2 layers:
1. "resource exchange" layer where binaries are
made into a single giant text file by base64
encoding and then partitioned by rfc822.
this part overlaps with http* and is much
less efficient (rightfully, since email had
to be backwards compatible as it is
critical).
2. "resource use" where the mail server parses
such exchanged resources (e.g. email bodies,
attachments, etc) and then acts upon them
(e.g. forward them, discard them, etc).
and so will pop* and imap.
this way, if we ignore the problem of maintaining
backwards compatibility, then having http* in the
"resource exchange" layer would be more efficient
and simpler as there will be less protocols doing
the "resource exchange" task (instead of having
each do its own).
i also think that the kind of resource that email
exchanges is fundamentally identical to a subset
of resources that are natively exchanged in the
web.
so i think the only reason that smtp/pop/imap have
different resource exchange protocols is purely
due to backwards compatibility due to how things
evolved historically.
-----
i suspect that we actually agree on everything,
but speak different languages (possibly due to how
books commonly talk about protocols and layering),
or assume things beyond what's written.
e.g. we agree that:
1. smtp/pop*/imap make the best messaging
system today, and is not going away any time
soon, thanks to its wide spread. most likely
i'll be dead and still have multiple active
smtp/imap/pop account.
2. smtp/imap/pop are imperfect and have many
shortcomings that are "rightfully" not solved
"cleanly" due to historical reasons and its
critical nature which imposed on us
the constraint of having to maintaining its
backwards compatibility.
3. trying new protocols is fine. and is also
fine to have sub-communities that use
different messaging protocols if they find it
more fitting.
e.g. i'll probably end up using smtp/imap for
talking to people in general, and use hillarymail
[1] for talking to a closer nerdy community.
[1] https://github.com/al-caveman/hillarymail
