Vitold wrote (2020-11-09):
VS> I do not exclude the possibility of using the 39th version of the
VS> proposal in the future, but I need to make sure that this will work with
VS> my nodes.
VS> In any case, increasing count requests about support some feature is
VS> increase chance of select one specific implementation in favor of another.
O>> Btw, it's an FSC not an FTS.
VS> You right. It would be convenient to have a standard that would support
VS> every tosser to support one single same coding scheme.
I compiled a list of the supported packet formats for popular tossers 4 years ago. I don't know if anything has changed since then and it might be not 100% accurate, but it looks like FSC-0039 is the standard that most tossers use for outbound packets and that every tosser can read.
| Name | Read | Write |
|-------------------|------------|--------|
| Crashmail (Amiga) | 39, 45, 48 | 39 |
| Crashmail II | 39, 45, 48 | 39 |
| Daydream BBS | 39, 48 | 48 |
| FastEcho | 39, 45, 48 | 39 |
| Fidogate | 39 | 39 |
| FMail | 39, 48 | 39 |
| GEcho | 39, 45, 48 | 39 |
| Husky hpt | 39, 48 | 39 |
| ifmail | 39 | 39 |
| LoraBBS | 39, 45 | 39 |
| MBSE | 39 | 39 |
| Mystic | 39, 48 | 39 |
| OpenXP | 39 | 39 |
| SBBSecho | 39, 45, 48 | 45, 48 |
| Soupgate | 39 | 39 |
| Squish | 39 | 39 |
| Watergate | 39, 48 | 39 |
| WWIV BBS v5 | 39 | 39 |
VS> I review ASCII version of PKTv3 format with the text data representation,
VS> since there is less bit field hacks, but as far as I understand today,
VS> there are no tossers with this coding scheme support.
I don't know any tosser that support PKTv3. If there is a need for a better packet format, I would start with a new proposal for a sane binary format. ASCII formats are usually harder to parse than a clean binary format.
I guess it would be better to discuss stuff like this in NET_DEV.
---
* Origin: (2:280/464.47)
|