Subj : Re^2:  Directly include binary data in messages
To   : Tim Schattkowsky
From : Rob Swindell
Date : Sat Feb 12 2022 13:39:13

  Re: Re^2:  Directly include binary data in messages
  By: Tim Schattkowsky to Rob Swindell on Sat Feb 12 2022 09:58 pm

 > //Hello Rob,//
 >
 > on *12.02.22* at *20:10:52* You wrote in Area *FTSC_PUBLIC*
 > to *Tim Schattkowsky* about *"Re: Directly include binary data in
 > messages"*.
 >
 >  RS> MIME includes a standardized type value that is non-ambiguous for a
 >
 > I know. Still not related to your main point, that there should be no file
 > name ;)

I asked what the value of the filename was, and you said to determine the content-format of the <almost-binary-data>. I'm saying there's a better way to do that: standard mime/media types.

So... the other reason to have a filename would be to suggest a filename for the local storage system (e.g. if the reader wanted to extract the file from the message)? If that's the case, then I would propose a better tag for your control paragraph would be FILE, e.g.

<SOH>FILE: <name> <crc> <data>

But if you want message viewers to be able to potentially nicely handle (e.g. display) the content, then I would definitely suggest adding the mime/media type value as well. e.g.

<SOH>FILE: <name> <type> <crc> <data>

 >  RS> reason: filenames are not the best methods for determining a file's
 >  RS> content type. Is it .jpeg, .JPEG, .jpg, .jpe, .jfif, or .jif? All of
 >  RS> these are valid JPEG file extensions, but there's only one
 >  RS> corresponding MIME-type (aka Internet media type): image/jpeg.
 >
 > From the past when I was implementing (among many other things) a web
 > server, I also know that this is in fact not fully true because there are
 > also a lot of ambiguities when it comes to MIME types in the real world.

No ambiguities with the main/popular types and much *less* ambiguity than with filenames, for all media types.

 > Here, the clear intention would be to either go with the existing standards
 > (maybe pick a subset) or do something very simple. The thing is, that using
 > existing standards, DOS-based software will be practically not able to
 > include such functionality as library support does not exist (for obvoious
 > reasons) and MIME handling alone can easily be mode code that a whole simple
 > approach to the problem.

I think you're depending on DOS-based software to most likely just ignore/skip-past this new control paragraph. So it doesn't really matter its format/content, so long as it is very backwards-compatible.

 > Also, I am not sure that we really want to essentially deliver HTML email
 > with embedded pictures over fido.

I didn't mention HTML. I was just suggesting that if you want to insure compatibility with all existing standards-compliant FidoNet software, to use only US-ASCII non-control characters in your <almost-binary-data> encoding (base64 being the obvious best practice for this type of encoding). Whether or not DOS-based software has a base64 decoding library is pretty irrelevant. The critical thing is that it doesn't choke on a message or a packet due to the existance of your proposed/new control paragraph.
-- 
                                            digital man (rob)

This Is Spinal Tap quote #41:
Ian Faith: It say's "Memphis show cancelled due to lack of advertising funds."
Norco, CA WX: 86.4øF, 10.0% humidity, 4 mph SW wind, 0.00 inches rain/24hrs
--- SBBSecho 3.14-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.