--On Thursday, January 17, 2019 13:51 -0500 John R Levine
<johnl(_at_)taugh(_dot_)com> wrote:
In article <01R238XJND6O00004L(_at_)mauve(_dot_)mrochek(_dot_)com>,
Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
As for BINARYMIME, we implemented that for SUBMIT in 2012 due
to a couple of customer requests. As I explained previously,
our view is that BINARYMIME makes sense for SUBMIT because it
is far more common for it to be bandwidth-constained than
SMTP transfers, and transcoding is acceptable at submit time.
Sounds to me like it's time for STARTGZIP, preferably after
STARTTLS.
It squeezes out the redundancy in base64 pretty well.
Might I suggest that everyone go back and reread the paragraph
starting "It must be emphasized..." in Section 3 of RFC 1425 (I
doubt it is relevant, but I didn't write that paragraph; IIR,
Marshall Rose did.). Additional options add complexity,
complexity has costs, and one of those costs involves fussing
around with, and needing multiple code paths for, different
combinations of options that might or might not be supported.
Perhaps this would be justified, but I think the standard for
adding the option should be a lot higher than "yes, we could
figure out how to do that" or even "Base64 is not a
high-compression encoding".
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp