Text 12416, 65 rader
Skriven 2022-02-11 12:40:25 av Rob Swindell (31435.ftsc_pub)
  Kommentar till text 12412 av Tim Schattkowsky (2:240/1120.29)
Ärende: Directly include binary data in messages
================================================
  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
--- SBBSecho 3.14-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)