Subj : Directly include binary data in messages
To   : Tim Schattkowsky
From : Rob Swindell
Date : Fri Feb 11 2022 12:40 pm

  Re: Directly include binary data in messages
  By: Tim Schattkowsky to All on Fri Feb 11 2022 03:11 pm

 > Hello All,
 >
 > w.r.t. the embedding of images I actually also consider a variant where the
 > images are included in a more binary-style manner to conserver memory. The
 > idea is, to introduce a Kludge for including Binary attachments directly in
 > the mail similar to MIME but simpler to handle and more space-conserving:
 >
 > @BIN <filename> <CRC32 in hex> <almost binary data>

Control paragraphs should begin with ^A<tag>:
ftsc.org/docs/fts-4000.001

So assuming '@' represents Ctrl-A, that would just mean putting a colon after "BIN". But why "BIN"? Wouldn't "IMAGE" be more approrpriate?

What purpose is the filename? Since you're using space-delimeters for this control paragraph, you couldn't have spaces in the filename unless you had some special escaping or quoting syntax support. I would recommend just eliminating the filename unless it provides some important function.

Is the CRC32 exactly 8 hex digits or not? (i.e. if the first n-hex-digits of the CRC value are 0, are they still included?). I assume you mean the IEEE-802.3 CRC-32 algo/polynominal? There *are* multiple 32-bit CRC algorithms, so it would best to be specific. en.wikipedia.org/wiki/Cyclic_redundancy_check

"<almost binary data>" is encoding what image format? JPEG, GIF, PNG or what? If you want to be flexible, include a mime-type string for the format of the decoded data (e.g. "image/jpeg"). Are you limiting this to bitmap images or are vector graphics (e.g. SVG) okay?

 > Where <almost binary data> uses a simple encoding that essentially aims at
 > avoiding $00, $0d and $0a so the resulting string still forms a valid line
 > of 8-Bit characters. The checksum is also intended to detect any charset
 > violence or 7-Bit fun that might have happend to the message on the way.

I would go with base64 encoding to reduce interoperability issues.

 > Admittedly, I still have the idea to make the most out of the 63k maximum
 > message length I spuspect for unsplit messages. W.r.t. this, the above
 > mechanism actually has the drawback of being incompatible with @SPLIT and
 > this limiting the size of an attachment effectively to one 63k message.

Is there really a "63k maximum message length" required by some FTSC standard? SBBSecho definitely doesn't recognize or impose any such limit.

 > One main benefit here is the space saving compared to base64. THis is a
 > general thing: Do you think base64 (or the like) are still necessary or is
 > betting on 8-bit binary transmission ok?

I could think of all kinds of character sequences that could cause issues with existing software. These issues would be avoided by just using base64-encoding. yEnc is another encoding that's more efficient than base64, but I would just stick with base64 as it's just going to avoid a lot of potential issues from the outset.
-- 
                                            digital man (rob)

Synchronet/BBS Terminology Definition #41:
IBM = International Business Machines (Corporation)
Norco, CA WX: 84.3øF, 18.0% humidity, 0 mph NE wind, 0.00 inches rain/24hrs

.