1 |
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ |
2 |
On Thursday, August 27, 2020 12:21 AM, Grant Taylor <gtaylor@×××××××××××××××××××××.net> wrote: |
3 |
|
4 |
> email email email |
5 |
> SMTP SMTP POP3S/IMAPS |
6 |
> A) [1]---(TCP)---[2]---(TCP)---[3]---(TCP)---[4] |
7 |
> |
8 |
> Now what you are proposing: |
9 |
> |
10 |
> email email email |
11 |
> TBD TBD TBD |
12 |
> HTTPS HTTPS HTTPS |
13 |
> A) [1]---(TCP)---[2]---(TCP)---[3]---(TCP)---[4] |
14 |
> |
15 |
> The number of layers has increased from three to four. |
16 |
|
17 |
that's true if "SMTP" is a single layer. |
18 |
|
19 |
which is also how networking engineers including |
20 |
those highly skilled ones in standard bodies |
21 |
commonly commonly talk about protocols (e.g. based |
22 |
on layers of that sort). so i see why it makes |
23 |
sense that you did it this way. |
24 |
|
25 |
but i this way of looking at protocols (despite |
26 |
being common) is wrong. i also disagree with the |
27 |
network layering proposed by osi or the other ones |
28 |
commonly published in books. i specially disagree |
29 |
with using such layering for studying the |
30 |
complexity of protocols. |
31 |
|
32 |
so i suggest that if we want to study the |
33 |
complexity of messaging systems, we better not |
34 |
count SMTP as a single thing (like how it is |
35 |
normally done in books and talks), but instead |
36 |
talk about it based on the fundamental tasks that |
37 |
it actually does. this way, SMTP becomes at least |
38 |
2 layers: |
39 |
|
40 |
1. "resource exchange" layer where binaries are |
41 |
made into a single giant text file by base64 |
42 |
encoding and then partitioned by rfc822. |
43 |
this part overlaps with http* and is much |
44 |
less efficient (rightfully, since email had |
45 |
to be backwards compatible as it is |
46 |
critical). |
47 |
|
48 |
2. "resource use" where the mail server parses |
49 |
such exchanged resources (e.g. email bodies, |
50 |
attachments, etc) and then acts upon them |
51 |
(e.g. forward them, discard them, etc). |
52 |
|
53 |
and so will pop* and imap. |
54 |
|
55 |
this way, if we ignore the problem of maintaining |
56 |
backwards compatibility, then having http* in the |
57 |
"resource exchange" layer would be more efficient |
58 |
and simpler as there will be less protocols doing |
59 |
the "resource exchange" task (instead of having |
60 |
each do its own). |
61 |
|
62 |
i also think that the kind of resource that email |
63 |
exchanges is fundamentally identical to a subset |
64 |
of resources that are natively exchanged in the |
65 |
web. |
66 |
|
67 |
so i think the only reason that smtp/pop/imap have |
68 |
different resource exchange protocols is purely |
69 |
due to backwards compatibility due to how things |
70 |
evolved historically. |
71 |
|
72 |
----- |
73 |
|
74 |
i suspect that we actually agree on everything, |
75 |
but speak different languages (possibly due to how |
76 |
books commonly talk about protocols and layering), |
77 |
or assume things beyond what's written. |
78 |
|
79 |
e.g. we agree that: |
80 |
|
81 |
1. smtp/pop*/imap make the best messaging |
82 |
system today, and is not going away any time |
83 |
soon, thanks to its wide spread. most likely |
84 |
i'll be dead and still have multiple active |
85 |
smtp/imap/pop account. |
86 |
|
87 |
2. smtp/imap/pop are imperfect and have many |
88 |
shortcomings that are "rightfully" not solved |
89 |
"cleanly" due to historical reasons and its |
90 |
critical nature which imposed on us |
91 |
the constraint of having to maintaining its |
92 |
backwards compatibility. |
93 |
|
94 |
3. trying new protocols is fine. and is also |
95 |
fine to have sub-communities that use |
96 |
different messaging protocols if they find it |
97 |
more fitting. |
98 |
|
99 |
e.g. i'll probably end up using smtp/imap for |
100 |
talking to people in general, and use hillarymail |
101 |
[1] for talking to a closer nerdy community. |
102 |
|
103 |
[1] https://github.com/al-caveman/hillarymail |