1 |
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ |
2 |
On Thursday, August 27, 2020 8:15 PM, Grant Taylor <gtaylor@×××××××××××××××××××××.net> wrote: |
3 |
|
4 |
> On 8/27/20 7:00 AM, Caveman Al Toraboran wrote: |
5 |
> |
6 |
> > but i this way of looking at protocols (despite being common) is wrong. |
7 |
> |
8 |
> Why do you think that it is wrong? |
9 |
> |
10 |
> What is not factually correct about it? |
11 |
|
12 |
it depends on how you use it: |
13 |
|
14 |
- if you use it for what it is made for |
15 |
(making speech about protocols easier), then |
16 |
that's fine. not perfect, but not wrong |
17 |
either. |
18 |
|
19 |
- but if you use it to do some complexity |
20 |
analysis as you did earlier by counting such |
21 |
layers, then, you're wrong. because even |
22 |
though smtp appears as a single layer in |
23 |
such common diagrams, it is functionally 2 |
24 |
layers (one being a resource exchange layer |
25 |
overlapping with http). |
26 |
|
27 |
|
28 |
> > i also disagree with the network layering proposed by osi or the |
29 |
> > other ones commonly published in books. i specially disagree with |
30 |
> > using such layering for studying the complexity of protocols. |
31 |
> |
32 |
> If you're going to make such a statement, which is fine to do, you must |
33 |
> provide information ~> evidence as to why you are doing so and why you |
34 |
> think what you think. |
35 |
|
36 |
see above or previous emails. you're basically |
37 |
abusing such diagrams to perform protocol |
38 |
complexity analysis. |
39 |
|
40 |
i was trying to be indirect by blaming the common |
41 |
protocol layering for leading you to this |
42 |
mistake. what's happening is that you're |
43 |
simply abusing them to do what they are not made |
44 |
for. |
45 |
|
46 |
for details you can re-read my previous email(s) |
47 |
on how smtp is functionally at least 2 layers. |
48 |
|
49 |
|
50 |
> > so i suggest that if we want to study the complexity of messaging |
51 |
> > systems, we better not count SMTP as a single thing (like how it is |
52 |
> > normally done in books and talks), but instead talk about it based on |
53 |
> > the fundamental tasks that it actually does. this way, SMTP becomes |
54 |
> > at least 2 layers: |
55 |
> |
56 |
> I think that I see part of a problem. |
57 |
> |
58 |
> RFC 822 - Standard for the format of ARPA Internet Text Message - is |
59 |
> what defines what I was referring to as the opaque blob sent between |
60 |
> systems. |
61 |
> |
62 |
> I will argue that the content of the opaque blob that SMTP transfers is |
63 |
> independent of SMTP itself. |
64 |
> |
65 |
> > 1. "resource exchange" layer where binaries are made into a single |
66 |
> > giant text file by base64 encoding and then partitioned by rfc822. |
67 |
> > this part overlaps with http* and is much less efficient (rightfully, |
68 |
> > since email had to be backwards compatible as it is critical). |
69 |
> > |
70 |
> |
71 |
> SMTP* does not support binary in any (original) capacity. As such, |
72 |
> email service, which /rides/ /on/ /top/ /of/ SMTP, is where the encoding |
73 |
> ""hack was placed. This /encoding/ and / or /formatting/ is completely |
74 |
> independent of the SMTP protocol used to exchange opaque blobs between |
75 |
> mail servers. |
76 |
|
77 |
i'm amazed how you skipped the real point that i'm |
78 |
making about your incorrect layer-based protocol |
79 |
complexity analysis, and —instead— moved to talk |
80 |
about how email's inefficient binary encoding is |
81 |
due to rfc822 and not rfc821. |
82 |
|
83 |
it's irrelevant at several levels: |
84 |
|
85 |
- doesn't justify your layer-based complexity |
86 |
analysis earlier, either way. |
87 |
|
88 |
- no one discussed which rfc is the reason why |
89 |
smtp is being used for inefficient binary |
90 |
transfer. |
91 |
|
92 |
- the fact that attachments are inefficiently |
93 |
sent over smtp as per rfc822 is by itself due |
94 |
to bad historical design decisions in smtp |
95 |
that lead people to commonly use rfc822 with |
96 |
smtp. |
97 |
|
98 |
the several next paragraphs that you wrote are |
99 |
simply talking about whether smtp (rfc821) was |
100 |
born with a horrible binary encoding, or was it |
101 |
born retarded enough to push people to end up |
102 |
adding rfc822 to it in order to minimise |
103 |
suffering. which is irrelevant at many levels, so |
104 |
i'm skipping over them to save space/time. |
105 |
|
106 |
|
107 |
> > this way, if we ignore the problem of maintaining backwards |
108 |
> > compatibility, |
109 |
> |
110 |
> That is a HUGE if. One that I do not accept at all. You absolutely |
111 |
> MUST have backwards compatibility in some way. Even if that |
112 |
> compatibility is something that acts as an edge gateway between SMTP and |
113 |
> your new method. You MUST have backward compatibility in some way. |
114 |
|
115 |
also irrelevant. |
116 |
|
117 |
yes, that hypothetical "if" statement is indeed |
118 |
"huge". so? it's a hypothetical if statement to |
119 |
show another point: that your complexity analysis |
120 |
by counting layers is wrong. |
121 |
|
122 |
i'm once again amazed how you skipped the main |
123 |
point, and went on to write about how HUGE that |
124 |
hypothetical "if" statement is. |
125 |
|
126 |
(for the record i'm not suggesting to drop smtp's |
127 |
backwards compatibility, nor suggesting it would |
128 |
be easy.) |
129 |
|
130 |
|
131 |
> > then having http* in the "resource exchange" layer would be more |
132 |
> > efficient and simpler as there will be less protocols doing the |
133 |
> > "resource exchange" task (instead of having each do its own). |
134 |
> |
135 |
> So you want to take two completely different protocols that serve two |
136 |
> completely different functions and force them into a third completely |
137 |
> different protocol that serve yet another completely different function. |
138 |
|
139 |
they are not "completely" different. in fact |
140 |
emails/attachments are resources of the same kind |
141 |
as website material. http* is just dedicated for |
142 |
this part (resource exchange layer of such data |
143 |
type) and unsurprisingly it does it better than |
144 |
smtp's independently invented resource exchange |
145 |
layer. |
146 |
|
147 |
|
148 |
> I feel the need to back up and call out what HTTP is. (HTTPS included |
149 |
> because it's really just HTTP wrapped in encryption.) |
150 |
> |
151 |
> C: HTTP/1(.0) |
152 |
> C: GET <path> |
153 |
> S: |
154 |
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
155 |
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
156 |
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
157 |
> |
158 |
> S: 200 ... |
159 |
> |
160 |
> Notice how the HTTP /protocol/ doesn't care what the opaque blob is either. |
161 |
|
162 |
irrelevant for several reasons: |
163 |
|
164 |
1. doesn't justify your layer-based complexity |
165 |
analysis earlier which my text was about. |
166 |
|
167 |
2. doesn't apply to http/2. |
168 |
|
169 |
3. even pre-h2 uploads/downloads files using |
170 |
efficiently encoded binaries. unlike smtp that |
171 |
lead us, through historical mistakes, to use |
172 |
rfc822. |
173 |
|
174 |
4. http* is as a standalone resource exchange |
175 |
layer, so apps that need such a thing can |
176 |
simply run behind a web server, or a http |
177 |
library. |
178 |
|
179 |
this is not true for smtp if you want to only |
180 |
use smtp's resource exchange layer (you'd have |
181 |
to butcher it out of some implementation's |
182 |
code; which is also a pure waste of time since |
183 |
it's less efficient than today's http*) |
184 |
|
185 |
|
186 |
> > so i think the only reason that smtp/pop/imap have different resource |
187 |
> > exchange protocols is purely due to backwards compatibility due to |
188 |
> > how things evolved historically. |
189 |
> |
190 |
> It's not backwards compatibility. |
191 |
> |
192 |
> SMTP is for sending email from server to server. |
193 |
> POP3 is about pulling email from a single mailbox down to the local client. |
194 |
> IMAP is about remotely accessing multiple different mailboxes on a |
195 |
> remote server. |
196 |
> |
197 |
> They do three fundamentally different things. |
198 |
> |
199 |
> SMTP is akin to the postal service exchanging post between businesses. |
200 |
> |
201 |
> POP3 is you collecting email from your inbox in the mail room and taking |
202 |
> it back to your desk. |
203 |
> |
204 |
> IMAP is you going to the file room to access a file in one of the many |
205 |
> file cabinets. |
206 |
> |
207 |
> They are very different actions on what is potentially the same content. |
208 |
> But what is done and how it is done is completely different. |
209 |
|
210 |
so? how does the fact that they are 3 different |
211 |
protocols for different uses reject the fact that |
212 |
they are stuck with inefficient designs due to |
213 |
backwards compatibility? (rhetorical questions.) |
214 |
|
215 |
are you trying to say that, if we didn't have the |
216 |
backwards compatibility constraint today, and we |
217 |
were about to make a mail protocol, we'd still |
218 |
make smtp/pop/imap the way they are today? |
219 |
(rhetorical question.) |
220 |
|
221 |
anyway i'm out of this. massive waste of time. i |
222 |
could've finished server-side hillarymail by it. |