On Fri, Aug 21, 2020 at 09:35:42PM -0700, tim Rowledge wrote:
> 
> 
> > On 2020-08-21, at 6:30 PM, Phil B <pbpublist at gmail.com> wrote:
> > 
> > Tim,
> > 
> > Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table)  At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day)
> > 
> > Phil
> 
> 
> > On 2020-08-21, at 6:29 PM, Vanessa Freudenberg <vanessa at codefrau.net> wrote:
> > 
> > Hi Tim,
> > 
> > our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. 
> > 
> > Vanessa
> 
> Hunh. Fascinating. So maybe there is a tiny bit of sense to the code I was peering tiredly at. Though given it was creating the base64 string right there, probably not in this case. I do love how the software word is so full of kludge upon jury-rig upon WAG!
> 
> Thanks for the enlightenment. 
> 



Tim,

I fear that you have been spending too much time immersing yourself the
gratuitous improvements of modern technology. Surely you still remember
how to connect your computer with a proper rotary dial phone and acoustic
coupler. Once connected, you would use uuencode/uudecode (like base64)
to send binary stuff to the uucp network in a shar archive.

Naturally you would want to add line terminators in your encoded data,
othewise people might not be able to view it in their vi text editor or
text mail client.

:-)

Dave

--