TS> on *13.02.22* at *10:45:50* You wrote in Area *FTSC_PUBLIC* TS> to *Tim Schattkowsky* about *"Directly include binary data in messages"*.
O>> The JAM specification limits the length of and "FTSKLUDGE" to 255 O>> bytes. [...] O>> I have no idea how the different implementations would handle long (>>> 255) kludge lines.
TS> Ouch, that is really nasty. It is always suprising how some things can TS> also be implemented.
TS> I already considered using a *combination of multiple Kludge lines* where TS> each<256 Bytes (thinking of old school string handling) instead of TS> producing one very long line. [...] TS> Just walking that path (for the fun of it), *one could do something like*
Crashmail II truncates the FTSKLUDGE field at 100 chars, if I understand the C code correctly. I wouldn't mind fixing my local Crashmail tosser, but upgrading the Windows version or getting it in Debian is another thing.
Why not use a variation of yEnc now and then develop a modern (but still simple and easy to parse) message format for FTN? Or how many workarounds on top of workarounds we you want to put on the FTS-1 message format? I don't think there is much that can be done without breaking compatibility somewhere. That is what you get, if the organization for standardization only documents workarounds and hacks years or decades later instead of deliberately developing standards in the open. (The advantage is, that it is still a very simple format in comparison to Internet Mail).
