the usual leap of faith that everyone knows what they are talking
about?
Is there a plan to test pkt type headers or is going to be the usual leap of faith that everyone knows what they are talking about?
What's a "pkt type header" and how would one test it?
Hey Rob!
What's a "pkt type header" and how would one test it?
The latest version I have is "FSP-1042 draft 7" dated 2019-03-27, authored by Stephen Hurd of 1:103/1. The copy I have came from Andrew Leary and I assume you have a copy there given your current status in the FTSC.
Test them? That is an extremely good question. Myself I wrote a bash script that scans the first 58 bytes and looks for uniqueness between the types. So far the most used pkt type is 2+ which as far as I know isn't an accepted standard. :::snicker:::
It has been the defacto standard without ever being an actual standard. The REAL one is of course type 2 which hardly anyone can do anymore. I can.
How about you?
I still don't understand the original posted question however.
Yes, SBBSecho can both generate and accept the original type 2
packet format.
How about Type 2.2? So far I can only find one that is capable ... besides myself that is.
I could implement it in my clrghouz project if you wanted another
system to test again.
Hey Rob!
I still don't understand the original posted question however.
The orginal msg was a test of "Type 2.2 Packet" (FSP-1042 draft 7). The question was answered when it showed up beyond the link it was originally dumped on as a "Type 2.2 Packet" packed MSG which is the same regardless of the Type.
I am calling it a complete success.
Errrrr ... what was the question?
Yes, SBBSecho can both generate and accept the original type 2
packet format.
How about Type 2.2? So far I can only find one that is capable ... besides myself that is.
I like Type 2.2 because it isn't dated. Fidonet has far too many outdated datetime thingies. Seeing one disppear is a breath of fresh air.
So far the most used pkt type is 2+ which as far as I know
isn't an accepted standard. :::snicker:::
It has been the defacto standard without ever being an actual
standard.
The packed-messages themselves (in a type 2.2 packet) still
include dates that are badly formatted/specified
FSC-39 or FSC-48?
Hey Rob!
The packed-messages themselves (in a type 2.2 packet) still
include dates that are badly formatted/specified
That is true for all 3 types; 2, 2+ and 2.2. The packed msgs are exactly the same.
Hey Carlos!
FSC-39 or FSC-48?
You tell me. Without checking out either I am going out on a limb and say neither.
So *I* call FSC-48 compliant packets "Type 2+"
and FSC-39 comliant packets as "Type 2e".
but *might* be just 2e compliant.
http://wiki.synchro.net/ref:fidonet_packets
FSC-39 or FSC-48?
You tell me. Without checking out either I am going out on a limb
and say neither.
So *I* call FSC-48 compliant packets "Type 2+" and FSC-39 comliant
packets as "Type 2e". Any packet claiming to be 2+ is likely FSC-48 compliant, but *might* be just 2e compliant.
The details/differences are itemized here: http://wiki.synchro.net/ref:fidonet_packets
Hey Rob!
So *I* call FSC-48 compliant packets "Type 2+"
Okay.
and FSC-39 comliant packets as "Type 2e".
That doesn't match any of the Types in the document in question.
but *might* be just 2e compliant.
Gotta love when that happens.
http://wiki.synchro.net/ref:fidonet_packets
How does that compare to "FSP-1042 draft 7"?
13 Apr 2023 12:24, you wrote to Maurice Kinal:
FSC-39 or FSC-48?
You tell me. Without checking out either I am going out on a limb
and say neither.
So *I* call FSC-48 compliant packets "Type 2+" and FSC-39 comliant packets as "Type 2e". Any packet claiming to be 2+ is likely FSC-48 compliant, but *might* be just 2e compliant.
My tosser calls FSC-39 packets "Type 2+"...
The details/differences are itemized here: http://wiki.synchro.net/ref:fidonet_packets
Yeah, that's an excellent reference guide.
My question was about the "defacto standard" that Maurice mentioned. It may seem that the most common is FSC-39: hpt, FMail, Squish, Mystic, etc.
My question was about the "defacto standard" that Maurice mentioned. It may seem that the most common is FSC-39: hpt, FMail, Squish, Mystic, etc.
My recollection was that most packets that I see are in FSC-48 format (i.e. include the auxNet field), but I'll double-check that.
Which document is that?and FSC-39 comliant packets as "Type 2e".
That doesn't match any of the Types in the document in question.
I think the differentiation I've done between FSC-39 and FSC-48
compliant packets is important
I'll keep doing comparisons between the docs and my code see if
that'll jar it loose.
Hey Rob!
Which document is that?and FSC-39 comliant packets as "Type 2e".
That doesn't match any of the Types in the document in question.
Same as it always was, FSP-1042 draft 7.
I only see Type 2, Type 2+ an Type 2.2. Beats me what Type 2e is although I > probably have seen a document
somewhere describing it, along with a bunch of others that I have never run across in a functional tosser ... yet.
I think the differentiation I've done between FSC-39 and FSC-48 compliant packets is important
For sure but only if it doesn't muddy the waters of compatibilty. There is a big hole that exists that requires patching and I believe that is what FSP-1042 draft 7 attempts to fill.
My tosser calls FSC-39 packets "Type 2+"...
What does your tosser call FSC-48 formatted packets?
My question was about the "defacto standard" that Maurice
mentioned. It may seem that the most common is FSC-39: hpt, FMail,
Squish, Mystic, etc.
My recollection was that most packets that I see are in FSC-48 format (i.e. include the auxNet field), but I'll double-check that.
I checked the Squish source code (s_misc.c) and it's definitely writes[...]
the FSC-48 auxNet field to packet headers:
So Squish appears to generate packets that are not exactly FSC-39 or FSC-48 compliant. This conclusion was made from the source code
released on GitHub (https://github.com/sdudley/maximus/blob/master/squish/s_misc.c) so
it's always possible that earlier released versions of Squish did something different.
14 Apr 2023 11:48, you wrote to me:
My tosser calls FSC-39 packets "Type 2+"...
What does your tosser call FSC-48 formatted packets?
"Type 2+" too. That is what it shows in the toss logs.
My question was about the "defacto standard" that Maurice
mentioned. It may seem that the most common is FSC-39: hpt, FMail,
Squish, Mystic, etc.
My recollection was that most packets that I see are in FSC-48 format (i.e. include the auxNet field), but I'll double-check that.
IIUC, FSC-39.4 and FSC-48 packets are identical unless they are generated by a point system.
I have PKTs from points using FMail, WinPoint, OpenXP, HotdogEd, Aftershock. All of them are FSC-39. Will try to get some from other tossers/packages.
I got the idea that FSC-39 may be more common from a message by Oli (posted some years ago):
=== Cut ===
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.
| SBBSecho | 39, 45, 48 | 45, 48 |
I could implement it in my clrghouz project if you wanted another
system to test again.
I already called it a resounding success, which it was. What remains to be seen is whether or not any of this goes anywhere.
We'll I'll certain implement it in my project - better aligned
with my design.
But alas, it might take me a little while, work has taken me to
the Philippines this week
Sysop: | Xerxes |
---|---|
Location: | Azle, Texas |
Users: | 131 |
Nodes: | 10 (0 / 10) |
Uptime: | 97:07:11 |
Calls: | 3,190 |
Calls today: | 1 |
Files: | 195 |
U/L today: |
0 files (0K bytes) |
D/L today: |
0 files (0K bytes) |
Messages: | 366,170 |
Posted today: | 0 |