AN> Am 15.02.22 schrieb Tim Schattkowsky@2:240/1120.29 in FTSC_PUBLIC:
AN> Hallo Tim,
TS>> Dont get me wrong. *I love the idea of getting rid of FTS-1*, but TS>> it is much easier to come up with a new message format idea than TS>> to actually implemented such a transition in the field. For now, I TS>> think the basic transport is operational and we should concentrate TS>> on the payload.
AN> Just a small idea concerning compatibility:
AN> If there would be something like a replacement of FTS-1 (I would call AN> it FTS-2 - I hope this name isn't already taken), this would imply AN> that all software which handles mails would have to be adapted.
AN> Could it be an option to make this software capable of accepting links AN> with old software, and convert (gate?) messages between FTS-1 AN> and FTS-2, so that users with retro software could still take part in AN> the net, just without some new-fangled stuff? This would make it AN> neccessary that all backbone/fidoweb/whatever-it- is-called systems AN> and other uplinks use software that is compatible with FTS-1 and AN> FTS-2 so that everyone could get a full feed.
Just going along that line, but without rewriting FTS-1, or using the idea as a gating method from the new FTS to FTS-1:
We do have mails and we do have files. Both we can send quite fine currently (with the known limitations). How about working with "file areas" going parallel to the message areas holding files being referenced in the message areas? Same would work with netmails. In this case you would just need a kludge linking one or multiple files and the editors, tossers, etc. supporting these method on the sending end need to handle the link between both correctly and incorporate the files with tics to the outbound, but no need to change mailers or any software on the receiving end (except an reader to know how to show the file links) or intermediate systems. All old software (or maybe text-only editors) would either not recognize the attachment at all, or could provide just a (local) link to the attached file. If the file link is provided with a plain text mark in the message content, too, even those systems would work, but the user has to go manually looking for the file in the corresponding "file area".
Biggest issue with this would be routing of private files (attached to netmails), I think. Without consulting the docs I think that is non-default behaviour currently to route private files. But it would just need a change of handling, not of the protocol used.
