Text 12491, 91 rader
Skriven 2022-02-15 20:52:23 av Tim Schattkowsky (2:240/1120.29)
  Kommentar till text 12483 av Oli (2:280/464.47)
Ärende: Re: Directly include binary data in messages
====================================================
//Hello Oli,//

on *15.02.22* at *11:55:18* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Directly include binary data in messages"*.

 TS>> Just walking that path (for the fun of it), one could do something like

 TS>> @BLOB: <ID> <filename> <filesize> <CRC32>
 TS>> @DATA: <ID> <Offset> <encoded binary data>
 TS>> ..
 TS>> @DATA: <ID> <Offset> <encoded binary data>

 O> Crashmail II truncates the FTSKLUDGE field at 100 chars, if I understand
 O> the C code correctly. I wouldn't mind fixing my local Crashmail tosser,
 O> but upgrading the Windows version or getting it in Debian is another
 O> thing.

One could do 80 character lines to be on the ridicously safe side.

 O> Why not use a variation of yEnc now and then develop a modern (but still
 O> simple and easy to parse) message format for FTN?

I think we can very well separate the payload from the message format in this
discussion as long as we stick to a certain baseline. Wheter or not this
baseline includes trust in 8-Bit transport as the de-facto standard is
debatable, but might not be the deal breaker. 

 O> Or how many workarounds on top of workarounds we you want to put on the
 O> FTS-1 message format?

While there are a lot of shortcomings in FTS-1, I have doubt that breaking
compatibility with the standard message format is a good idea since the few
existing systems today still seem to use quite heterogeneous software
configuration also on sometimes exotic operating systems that need to be kept
interoperable. I think this is causing more problems than it solves.  
 
 O> I don't think there is much that can be done without breaking compatibility
 O> somewhere. 

Depending. I would say, that using Email-style MIME would basically solve the
thing and is a simple counterexample to your assertion. Actually, it has been
in heavy use during the early years of the millenium (as fido email gatways
where popular), but with limited to non-existent client support. I still store
tens of thousands of such gated emails that all look ok to me. Some of the have
been @SPLIT-victims, but look fine (for recombination).  

I would also like to point out, that any discussion about message length is
clearly misleading in this context as the current standard ist not limiting
message length and citing actualy implementation shortcomings is no argument
for overriding the standard, as any new standard would require new
implementations anyway. So it is much simpler to say, that this time we
actually MEAN that messages may be of arbitrary length, which in reality means
that systems should be prepared at least for messages in the 10MB-range just
like typical email severs are.

 O> That is what you get, if the organization for standardization
 O> only documents workarounds and hacks years or decades later instead of
 O> deliberately developing standards in the open. (The advantage is, that it
 O> is still a very simple format in comparison to Internet Mail).

While I agree with your dissatisfaction, I still think this is just managing
the reality. Since there is only limited (if at all) maintennance for the
software in use, any radical change needs to be backed by enough developers to
keep everybody connected. 

This brings us to an interesting point: interoperability between any old and
new standard will probably be non-trivial, if the new standard adds significant
new capabilities. However, if it does not, there is no good reason to introduce
it!  

Dont get me wrong. *I love the idea of getting rid of FTS-1*, but it is much
easier to come up with a new message format idea than to actually implemented
such a transition in the field. For now, I think the basic transport is
operational and we should concentrate on the payload. 

I think the major points are
- message size limitations
- line size limitations
- 8-Bit transport
- integrity of white space and control characters in messages (CR,LF,$9,ESC,
...)

For the latter, I really think we might give a try and see what happens. Any
message format on top of FTS-1 can still add simple error detection to ensure
message integrety und otherwise assume binary correct (or yenc-level) transport
of content in non-kludge lines of a limited length as a baseline.  

Regards,
Tim
--- WinPoint 399.2
 * Origin: Original WinPoint Origin! (2:240/1120.29)