on *13.02.22* at *10:45:50* You wrote in Area *FTSC_PUBLIC* to *Tim Schattkowsky* about *"Directly include binary data in messages"*.
O> The JAM specification limits the length of and "FTSKLUDGE" to 255 bytes. O> It also would put the @BIN data in the .JHR file. JAM is not an "official" O> standard, but unfortunately half of Fidonet is based on this quirky O> format. (The specification is well written and easy to understand, but I O> never liked the way it separates header and kludge lines from the message O> body).
O> I have no idea how the different implementations would handle long (>255) O> kludge lines.
Ouch, that is really nasty. It is always suprising how some things can also be implemented.
I already considered using a *combination of multiple Kludge lines* where each<256 Bytes (thinking of old school string handling) instead of producing one very long line. However, this would at least increase the overhead. Also in this case, it seems that the order of kludges is not preserved, so each line has to include something like a sequence number as well and even an object reference to distinguish between different binary objects in the same message.
Just walking that path (for the fun of it), *one could do something like*
Where ID,Filesize, Offset and CRC32 are 8 digit hex numbers. Filenames might be encoded in some way to allow for spaces (e.g., URL-Encoded UTF-8). The data chunks can be recombined to the original data.
The @DATA:-Lines may be of variable length and could easily be limited to at total of 255 chars. That would result in 234 chars encoded payload (assuming I am right and leaving place fuer a CRLF just in case) resulting in an overhead of ~10% compared to the 33% overhead of just using Base64. If that makes it worth it is subject to discussion as well as what the actualy encoding could be.
Mechanics may be: 1. find BLOB and allocate buffer 2. write all binary data chunks to buffer at defined offsets 3. verify chechksum to validate result 4. provide file
The *resulting file may (similar to MIME) service different purposes like being a simple binary attachment or an image referenced in the text* (e.g., by filename in an HTML mail).
There are actually *good reasons for readers to decode files to the file system* even for message display. This way, antivirus software gets a chance to scan the file and COTS for displaying file-based images or HTML off a folder can be employed if needed.
Essentially, this could be a way of *achieving something similar to multipart MIME without its overhead* and without it the resulting tool support in some places that currently probably don't care about fido anyway.
Still, I am particularly *worried about compatibility with message transport* and processing (also on gateways) and the the potential gain in storage efficiency is quite limited, which for me still makes *using a well-defined subset of MIME with Base64 more attractive* as it is likely to cause no issues on the way and may still provide limited readability on legacy systems.
Whether or not such mails might also *include HTML instead of plain text is IMHO a related but different debate*. I would tend to say for now, we are happy get a way of including images/binary data at all.
Regards, Tim --- WinPoint 399.1 * Origin: Original WinPoint Origin! (2:240/1120.29)
