‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, August 27, 2020 8:15 PM, Grant Taylor
<gtay...@gentoo.tnetconsulting.net> wrote:
> On 8/27/20 7:00 AM, Caveman Al Toraboran wrote:
>
> > but i this way of looking at protocols (despite being common) is wrong.
>
> Why do you think that it is wrong?
>
> What is not factually correct about it?
it depends on how you use it:
- if you use it for what it is made for
(making speech about protocols easier), then
that's fine. not perfect, but not wrong
either.
- but if you use it to do some complexity
analysis as you did earlier by counting such
layers, then, you're wrong. because even
though smtp appears as a single layer in
such common diagrams, it is functionally 2
layers (one being a resource exchange layer
overlapping with http).
> > 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.
>
> If you're going to make such a statement, which is fine to do, you must
> provide information ~> evidence as to why you are doing so and why you
> think what you think.
see above or previous emails. you're basically
abusing such diagrams to perform protocol
complexity analysis.
i was trying to be indirect by blaming the common
protocol layering for leading you to this
mistake. what's happening is that you're
simply abusing them to do what they are not made
for.
for details you can re-read my previous email(s)
on how smtp is functionally at least 2 layers.
> > 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:
>
> I think that I see part of a problem.
>
> RFC 822 - Standard for the format of ARPA Internet Text Message - is
> what defines what I was referring to as the opaque blob sent between
> systems.
>
> I will argue that the content of the opaque blob that SMTP transfers is
> independent of SMTP itself.
>
> > 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).
> >
>
> SMTP* does not support binary in any (original) capacity. As such,
> email service, which /rides/ /on/ /top/ /of/ SMTP, is where the encoding
> ""hack was placed. This /encoding/ and / or /formatting/ is completely
> independent of the SMTP protocol used to exchange opaque blobs between
> mail servers.
i'm amazed how you skipped the real point that i'm
making about your incorrect layer-based protocol
complexity analysis, and —instead— moved to talk
about how email's inefficient binary encoding is
due to rfc822 and not rfc821.
it's irrelevant at several levels:
- doesn't justify your layer-based complexity
analysis earlier, either way.
- no one discussed which rfc is the reason why
smtp is being used for inefficient binary
transfer.
- the fact that attachments are inefficiently
sent over smtp as per rfc822 is by itself due
to bad historical design decisions in smtp
that lead people to commonly use rfc822 with
smtp.
the several next paragraphs that you wrote are
simply talking about whether smtp (rfc821) was
born with a horrible binary encoding, or was it
born retarded enough to push people to end up
adding rfc822 to it in order to minimise
suffering. which is irrelevant at many levels, so
i'm skipping over them to save space/time.
> > this way, if we ignore the problem of maintaining backwards
> > compatibility,
>
> That is a HUGE if. One that I do not accept at all. You absolutely
> MUST have backwards compatibility in some way. Even if that
> compatibility is something that acts as an edge gateway between SMTP and
> your new method. You MUST have backward compatibility in some way.
also irrelevant.
yes, that hypothetical "if" statement is indeed
"huge". so? it's a hypothetical if statement to
show another point: that your complexity analysis
by counting layers is wrong.
i'm once again amazed how you skipped the main
point, and went on to write about how HUGE that
hypothetical "if" statement is.
(for the record i'm not suggesting to drop smtp's
backwards compatibility, nor suggesting it would
be easy.)
> > 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).
>
> So you want to take two completely different protocols that serve two
> completely different functions and force them into a third completely
> different protocol that serve yet another completely different function.
they are not "completely" different. in fact
emails/attachments are resources of the same kind
as website material. http* is just dedicated for
this part (resource exchange layer of such data
type) and unsurprisingly it does it better than
smtp's independently invented resource exchange
layer.
> I feel the need to back up and call out what HTTP is. (HTTPS included
> because it's really just HTTP wrapped in encryption.)
>
> C: HTTP/1(.0)
> C: GET <path>
> S:
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> S: 200 ...
>
> Notice how the HTTP /protocol/ doesn't care what the opaque blob is either.
irrelevant for several reasons:
1. doesn't justify your layer-based complexity
analysis earlier which my text was about.
2. doesn't apply to http/2.
3. even pre-h2 uploads/downloads files using
efficiently encoded binaries. unlike smtp that
lead us, through historical mistakes, to use
rfc822.
4. http* is as a standalone resource exchange
layer, so apps that need such a thing can
simply run behind a web server, or a http
library.
this is not true for smtp if you want to only
use smtp's resource exchange layer (you'd have
to butcher it out of some implementation's
code; which is also a pure waste of time since
it's less efficient than today's http*)
> > 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.
>
> It's not backwards compatibility.
>
> SMTP is for sending email from server to server.
> POP3 is about pulling email from a single mailbox down to the local client.
> IMAP is about remotely accessing multiple different mailboxes on a
> remote server.
>
> They do three fundamentally different things.
>
> SMTP is akin to the postal service exchanging post between businesses.
>
> POP3 is you collecting email from your inbox in the mail room and taking
> it back to your desk.
>
> IMAP is you going to the file room to access a file in one of the many
> file cabinets.
>
> They are very different actions on what is potentially the same content.
> But what is done and how it is done is completely different.
so? how does the fact that they are 3 different
protocols for different uses reject the fact that
they are stuck with inefficient designs due to
backwards compatibility? (rhetorical questions.)
are you trying to say that, if we didn't have the
backwards compatibility constraint today, and we
were about to make a mail protocol, we'd still
make smtp/pop/imap the way they are today?
(rhetorical question.)
anyway i'm out of this. massive waste of time. i
could've finished server-side hillarymail by it.
