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)
