Subj : Directly include binary data in messages To : Tim Schattkowsky From : Oli Date : Sat Feb 12 2022 09:46 am Tim wrote (2022-02-11): TS> Hello All, TS> w.r.t. the embedding of images I actually also consider a variant where TS> the images are included in a more binary-style manner to conserver TS> memory. The idea is, to introduce a Kludge for including Binary TS> attachments directly in the mail similar to MIME but simpler to handle TS> and more space-conserving: TS> @BIN TS> Where uses a simple encoding that essentially aims TS> at avoiding $00, $0d and $0a so the resulting string still forms a valid TS> line of 8-Bit characters. The checksum is also intended to detect any TS> charset violence or 7-Bit fun that might have happend to the message on TS> the way. Hi Tim, I was to about to reply to your first message with a very similar proposal / idea. I'm glad I didn't and you were faster. Saved me some time, redundant work and doubts to overcome ;-) I do like the general idea of hiding binary data in kludge lines. I also would prefer ABD (Almost Binary Data) over base64 or other 7-bit encodings. (8-bit) Messages must not be changed or converted in Fidonet. The biggest question is: would it work with current software? Potential problems: - kludge line too long - tossers - readers / editors - message base formats (storage) - message size too big - maximum allowed size to small for many regular images / files - much bigger messages - only few programs / users can display it - wasted bandwidth - wasted hard disk storage - file size limit of message bases - gateways / NNTP server - Internet Mail <-> FTN mail - some software might barf on 8-bit X-FTN-BIN headers if not properly escaped and wrapped at 998 chars - no support for converting @BIN kludge <-> MIME attachment - (8-bit corruption) Then there are more general questions: - will sysops support binaries in mail or is it annoying? - how to display images in BBS / terminal / TUI I haven't looked into the potential problems. Maybe we can setup an echo for testing and generate some test messages to see which software can or cannot handle it. Or create a set of VMs (Windows, Linux, DOS (?)) for a network simulation, which could also be useful for future experiments. My gut feeling is, that it won't work satisfactory in a heterogeneous network with some old software still used on some hubs. Or there is some limitation in one of the message base formats. Or NNTP access / gateways would blow up. Maybe we are stuck with HTTP URLs in mails and any more ambitious solution would need a new mail format. --- * Origin: Birds aren't real (2:280/464.47) .