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.
The JAM specification limits the length of and "FTSKLUDGE" to 255 bytes. It also would put the @BIN data in the .JHR file. JAM is not an "official" standard, but unfortunately half of Fidonet is based on this quirky format. (The specification is well written and easy to understand, but I never liked the way it separates header and kludge lines from the message body).
I have no idea how the different implementations would handle long (>255) kludge lines.
Quote from the spec:
The SubField structure is made up of an ID, a length specifier, and a block of data. Zero or more subfields may follow the fixed-length binary header. SubFields are not stored in any specific order and are not terminated by any specific character unless otherwise specified.
SubField: ushort LoID; // Field ID, 0-65535 ushort HiID; // Reserved for future use ulong datlen; // Length of buffer that follows uchar Buffer[datlen]; // DATLEN bytes of data end;
--------------------------------------------------------------------- Defined LoID codes --------------------------------------------------------------------- [...]
ID=2000, Name=FTSKLUDGE
An FTS-compliant "kludge" line not otherwise represented here. All data not relevant to the actual kludge line, including leading and trailing white space and ^A (01H) characters should be removed. DATLEN must not exceed 255 characters. The FTS kludges INTL, TOPT, and FMPT must never be stored as separate SubFields. Their data must be extracted and used for the address SubFields.
