Brandon Long <blong(_at_)google(_dot_)com> writes:
I would be remiss if I didn't mention that one of my colleague's here at
Google thinks this is all silly, and we should instead figure out how to
not base64 encode the messages in the first place, but I think that's a
higher barrier than this.
We specified the NNTP protocol as being basically binary-clean (you still
have to do dot-stuffing, and you have to have a newline at the end of the
message, but it's mostly there), and most implementations *mostly* cope,
but clients are another matter entirely. (Ideally, we'd want an even more
binary-clean transport, but the NNTP one is close enough.)
Note that, in the NNTP world, yEnc has some traction as an encoding
format. I tried to convince the author to write it up as a MIME encoding,
with absolutely no luck, but it should be possible to do. I think Ned
Fried took a crack at it? It's basically a minimal encoding to deal only
with the flaws found in actual NNTP implementations (such as not coping
with nuls and unmatched CR or LF characters) and dot-stuffing, and is
pretty close to not compressing.
It's kind of a horrible hack, but at least for a while it was very widely
used in the binary Usenet groups since it avoids having to bloat things
with base64 and is pretty close to the unencoded size. However, I've not
seen it used for anything more general-purpose.
http://www.yenc.org/
--
Russ Allbery (eagle(_at_)eyrie(_dot_)org)
<http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp