Subject: [ietf-smtp] oh, you want to sumbit faster, was [Proposal] confusing

From: "John R Levine" <[email-masked]>
Date: 17 Jan 2019 13:51:35 -0500

In article <[email-masked]>,
Ned Freed  <[email-masked]> 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.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Jan 2019 16:01:12 -0500

--On Thursday, January 17, 2019 13:51 -0500 John R Levine
<[email-masked]> 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.
> 

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

---

From: "John R Levine" <[email-masked]>
Date: 17 Jan 2019 17:05:38 -0500

>> Sounds to me like it's time for STARTGZIP, preferably after
>> STARTTLS. It squeezes out the redundancy in base64 pretty well.
>
> starting "It must be emphasized..." in Section 3 of RFC 1425 ...

I was going to to into more detail but then realized I suggested the exact 
same thing three years ago:

https://mailarchive.ietf.org/arch/msg/ietf-smtp/eA-WzlQvtQEE-t362edCOam0gDE

One of the less broken suggestions was CDAT which is just like DATA except 
that the dot stuffed message is sent deflated (same as gzip without the 
file headers.)  Deflate will shrink base64 pretty close to the original 
size, and also could help in the situation where a system sends a sequence 
of similar messages in an SMTP session, e.g., a bunch of order 
confirmations, or per-recipient customized bulk mail.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly