--On Wednesday, August 17, 2016 13:02 +0530 Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:
Or perhaps not want compression at all. SMTP has different
problems than IMAP, which I think simple compression will not
fix: Submit sees a single message per connection, plain SMTP
sees mostly spam. Why implement compression, then?
That seems to me to be a key question, perhaps _the_ key
question.
Relays in SMTP are also much more under the control of the
recipient domain, while NNTP, at least from my perspective, acts
like more of a mesh. Other issues put more of a premium on
rapid delivery with SMTP than with NNTP. For many situations,
email also gains much more from viewing compression as something
dealt with as an end-to-end compressed body part issue rather
than as a transport option.
Noting that transport-time compression capability and associated
SMTP extensions have been proposed many times and never gone
anywhere, can we take this discussion up a notch and address the
question of what the requirement for this capability looks like
and what problem it solves? "We can figure out how to do it" is
obviously an important piece of the puzzle, but it seems to me
that is the easy part... and a part that doesn't lead to a lot
of demand or deployment.
john
(who still believes that fewer options promote simplicity
and, in turn, leads to fewer bugs, less unanticipated
vunerability to attack, and better interoperability)
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp