= Сообщение: 5977 из 7128 ====================================== FTSC_PUBLIC = От : Oli 2:280/464.47 12 Feb 22 09:46:28 Кому : Tim Schattkowsky 12 Feb 22 09:46:28 Тема : Directly include binary data in messages FGHI : area://FTSC_PUBLIC?msgid=2:280/464.47+620773dc На : area://FTSC_PUBLIC?msgid=2:240/1120.29+315a7fa0 = Кодировка сообщения определена как: LATIN1 ================================= ============================================================================== 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 <filename> <CRC32 in hex> <almost binary data>
TS> Where <almost binary data> 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.
