= Сообщение: 5985 из 7128 ====================================== FTSC_PUBLIC = От : Rob Swindell 1:103/705 12 Feb 22 13:39:13 Кому : Tim Schattkowsky 12 Feb 22 13:39:13 Тема : Re^2: Directly include binary data in messages FGHI : area://FTSC_PUBLIC?msgid=31444.ftsc_pub@1:103/705+266dd9d5 На : area://FTSC_PUBLIC?msgid=2:240/1120.29+32b1a387 = Кодировка сообщения определена как: CP437 ================================== ============================================================================== 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)
