> 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)
