I was wondering if certain portions of HTTP/2 have been considered for
inclusion in some sort of way SMTP?
Compression is out of the question, primarily because of relaying and the fact
it would just be decompressed right after. Data consumption isn't a big
problem, since most SMTP servers are in datacenters with unlimited data
(bandwidth style billing).
Klensin made a post about it s long time ago with more details; I think its in
the archive somewhere
Maybe the multiple resources per TCP connection/binary framing is a good idea.
For SMTP, I suppose it will be something like having multiple independent
packets with the MAIL FROM,MAIL TO, and other "outside" information of a
message, another type of packet with the body message, and then a another
packet type for just a general command. Each of these could be in any order,
and the server would respond in any order. Kind of like pipelining, but even
faster since the client doesn't need to wait for the DATA go ahead. This fixes
the problem with QMTP since it doesn't support the whole SMTP command set,
while an implementation like this would.
It would still be over TCP; Quic is a different discussion altogether.
Sent with ProtonMail Secure Email.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp