Subj : Directly include binary data in messages
To   : Tim Schattkowsky
From : Oli
Date : Sun Feb 13 2022 11:45 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 <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.

---
 * Origin: Birds aren't real (2:280/464.47)

.