I have a user who is having trouble importing echomail mail from
clrghouz (my mailer/tosser) using BBBS (other users appear to not be affected).
In FTS-0001, section C.1 regarding a packed message, it states:
PakdMessage = 02H 00H (* message type, old type-1 obsolete *)
origNode (* of message *)
destNode (* of message *)
origNet (* of message *)
destNet (* of message *)
So assume this scenario, an echomail message originates from node 1/1,
and is sent to it's hub 2/2. The hub then sends the message onto node
3/3.
When the hub (2/2) exports and packs the message for 3/3, is the "origNode", "origNet" 2 (for the hub), or 1 (because that is where the message originated from).
From my testing, I think both at least hpt and mbse use 2 for the origNode/origNet - but FTSC says "of message", which I originally interpretted that it needed to be "1" since the "message" originated
from 1/1.
It also says this "Due to routing, the origin and destination net and
node of a packet are often quite different from those of the messages within it", which would be true for netmail, but is it also true for echomail?
Have I missed an FTSC document that states echomail should use the
hub's details?
So assume this scenario, an echomail message originates from node 1/1, and is sent to it's hub 2/2. The hub then sends the message onto node 3/3.
When the hub (2/2) exports and packs the message for 3/3, is the "origNode", "origNet" 2 (for the hub), or 1 (because that is where the message originated from).
It also says this "Due to routing, the origin and destination net and node of a packet are often quite different from those of the messages within it", which would be true for netmail, but is it also true for echomail?
It can be. In the early days of FidoNet, it was quite possible for a node to participate in echomail conferences via routed mail. In this scenario, echomail is simply netmail with an AREA: line.
PakdMessage = 02H 00H (* message type, old type-1 obsolete *)
origNode (* of message *)
destNode (* of message *)
origNet (* of message *)
destNet (* of message *)
From my testing, I think both at least hpt and mbse use 2 for the origNode/origNet - but FTSC says "of message", which I originally interpretted that it needed to be "1" since the "message" originated from 1/1.
packed message headers usually reflect the last-hop (or hub)
address and not the originating node address.
packed message headers usually reflect the last-hop (or hub)
address and not the originating node address.
I see originating node addresses in packed msg headers. They are preserved by anything I am using. As far as I am aware that is the correct operating procedure.
It seems BBBS doesnt like it, and nothing else I've tested
complains.
But from my testing, and I guess confirmed too by Rob, many
things use the "last hop" in the packed message header.
What "should" it be?
(To me, the FTSC implies it should be the originating node.)
Hey Rob!
packed message headers usually reflect the last-hop (or hub)
address and not the originating node address.
I see originating node addresses in packed msg headers. They are preserved by anything I am using. As far as I am aware that is the correct operating procedure.
GEcho, FrontDoor, D'Bridge and InterEcho, packed echomail
message header's contained the last hop address as the origin
address
if you would include a REPLY-Header to not break all
conversations involving you ;)
So I thought so to, which is what I implemented.
It seems BBBS doesnt like it, and nothing else I've tested complains.
But from my testing, and I guess confirmed too by Rob, many things use
the "last hop" in the packed message header.
What "should" it be? (To me, the FTSC implies it should be the
originating node.)
It should be the originating node. I will verify in the MBSE
code that it does not change this.
What "should" it be? (To me, the FTSC implies it should be the
originating node.)
It should be the originating node. I will verify in the MBSE code that it does not change this.
I guess, now it's far too late to fix all the buggy, abandonware
out there.
I guess, now it's far too late to fix all the buggy, abandonware
out there.
Who in their right mind would want to do that?
It's as easy to fix as fixing the bugs in MS-DOS
abandon it for better software.
I guess, now it's far too late to fix all the buggy, abandonware
out there.
Who in their right mind would want to do that?
It's as easy to fix as fixing the bugs in MS-DOS -- abandon it for better software.
It should be the originating node. I will verify in the MBSE
code that it does not change this.
I pointed out this origNode error many years ago (because it made a program of mine more difficult to get functioning properly).
The response was the usual "this is how we've always done it" and nothing more happened. I guess, now it's far too late to fix all the buggy, abandonware out there.
BTW, this is still a real name echo, yes?
I consider it unlikely that anything will change in that regard. The documentation should be corrected to document actual practice, but that raises the issue of the copyright on FTS-0001.
I consider it unlikely that anything will change in that regard.
The documentation should be corrected to document actual practice,
but that raises the issue of the copyright on FTS-0001.
What about it ?
Randy Bush's copyright notice as published in FTS-0001.016 does not
allow distributing it unless it is without modification and at no
charge. To proceed with updating it, we would need to secure Randy
Bush's permission first.
The alternative would be to completely rewrite it from scratch.
The alternative would be to completely rewrite it from scratch.
Good luck.
What about it ?
Randy Bush's copyright notice as published in FTS-0001.016 does not allow distributing it unless it is without modification and at no charge. To proceed with updating it, we would need to secure Randy Bush's permission first.
I consider it unlikely that anything will change in that regard.
The documentation should be corrected to document actual practice,
but that raises the issue of the copyright on FTS-0001.
What about it ?Randy Bush's copyright notice as published in FTS-0001.016 does not
allow distributing it unless it is without modification and at no
charge. To proceed with updating it, we would need to secure Randy
Bush's permission first.
The alternative would be to completely rewrite it from scratch.
MvdV> I tried that and failed.Randy Bush's copyright notice as published in FTS-0001.016 does not
allow distributing it unless it is without modification and at no
charge. To proceed with updating it, we would need to secure Randy
Bush's permission first.
MvdV> Good luck.The alternative would be to completely rewrite it from scratch.
I've once offered a working method of bypassing any and all of
fu...nny copyrights.
Yes, and the new document could be based just on existing open
software.
Randy Bush's copyright notice as published in FTS-0001.016 does not
allow distributing it unless it is without modification and at no
charge. To proceed with updating it, we would need to secure
I wonder why you all are so concerned about that copyshit...
When does that copyright expire? I'm not familiar with US copyright law.
Randy Bush's copyright notice as published in FTS-0001.016 does
not allow distributing it unless it is without modification and
at no charge. To proceed with updating it, we would need to
secure
When does that copyright expire? I'm not familiar with US copyright
law.
When does that copyright expire? I'm not familiar with US copyright AL>DH> law.
In general, US copyright protection for works created after January 1,
1978 lasts for the life of the author plus an additional 70 years.
To proceed with updating it, we would need to secure Randy Bush's
permission first.
That was never expected to work.
The alternative would be to completely rewrite it from scratch.
I wonder why you all are so concerned about that copyshit...
In general, US copyright protection for works created after January
1, 1978 lasts for the life of the author plus an additional 70
years.
I don't know the implications of a Canadian breaking US copyright
When does that copyright expire? I'm not familiar with UScopyright
law.
In general, US copyright protection for works created after
January 1, 1978 lasts for the life of the author plus an
additional 70 years.
I think you are terribly mistaken.
The US is a signatory of the Berne Convention and has ratified it,
plus there are other implications when going "international" ...
I consider it unlikely that anything will change in that regard. The documentation should be corrected to document actual practice, but that raises the issue of the copyright on FTS-0001.
It's as easy to fix as fixing the bugs in MS-DOS
-- abandon it for better software.
FTS-1 doesn't deal with echomail. If any FTSC doc needed "correction" (I'd say "clarification") in this regard, it'd be FTS-4.
It's as easy to fix as fixing the bugs in MS-DOS
-- abandon it for better software.
You mean use FreeDOS? ;)
Bj”rn Felten wrote to Richard Menedetter <=-
It's as easy to fix as fixing the bugs in MS-DOS
-- abandon it for better software.
You mean use FreeDOS? ;)
LOL! Yeah, that's probably a better alternative. More easily
available is the dos emulator in Windows (CMD.EXE).
How is that "more easily available" than FreeDOS?
How is that "more easily available" than FreeDOS?
Microsoft's Windows was the dominant desktop operating system (OS) worldwide as of July 2023, with a market share of around 70 percent.
You're information is outdated. In July 2023 it was:
- Android - 40%
- MS Windows - 29%
- iOS - 17%
and others.
Vitaliy Aksyonov wrote to Bj?rn Felten <=-
17 Oct 23 18:10, you wrote to Dan Clough:
How is that "more easily available" than FreeDOS?
Microsoft's Windows was the dominant desktop operating system (OS) worldwide as of July 2023, with a market share of around 70 percent.
You're information is outdated. In July 2023 it was:
- Android - 40%
- MS Windows - 29%
- iOS - 17%
Bj”rn Felten wrote to Dan Clough <=-
How is that "more easily available" than FreeDOS?
Microsoft's Windows was the dominant desktop operating system
(OS) worldwide as of July 2023, with a market share of around 70
percent.
What I do know is that to actually have/use that OS, you have to either purchase it,
Re: Question on FTS-0001
By: Rob Swindell to Andrew Leary on Sun Oct 15 2023 02:03 pm
FTS-1 doesn't deal with echomail. If any FTSC doc needed "correction" (I'd say "clarification") in this regard, it'd be FTS-4.
I'd disagree.
The question that I started was (and I'll paraphrase) what was the origNet/origNode represent in a packed message header.
The answers I've seen are:
* Its the source message address,
* Its the last hop's address
It should be known as one or the other.
The english description "orig..." implies it is from the source of the message, ie: the originator, but convention seems to be that it represents the last hop.
That should be clarified and updated.
Or you can purchase a desktop computer. When was the last time you
bought a desktop computer, other than an Apple variant, that did *not*
have Windows pre-installed?
FTS-1 doesn't deal with echomail. You can wish it did, but it just doesn't.
When was the last time you bought a desktop computer,
other than an Apple variant,
that did *not* have Windows pre-installed?
Bj”rn Felten wrote to Dan Clough <=-
Dan Clough -> Bj”rn Felten skrev 2023-10-18 02:52:
What I do know is that to actually have/use that OS, you have to either purchase it,
Or you can purchase a desktop computer.
When was the last time you bought a desktop computer, other than an
Apple variant, that did *not* have Windows pre-installed?
Re: Question on FTS-0001
By: Rob Swindell to deon on Tue Oct 17 2023 11:24 pm
FTS-1 doesn't deal with echomail. You can wish it did, but it just doesn't.
I dont wish it did.
FTS-0001 talks about packed messages - which is what I'm talking about.
I'm not sure what your refering to though...
Re: Question on FTS-0001
By: deon to Rob Swindell on Wed Oct 18 2023 07:04 pm
Re: Question on FTS-0001
By: Rob Swindell to deon on Tue Oct 17 2023 11:24 pm
FTS-1 doesn't deal with echomail. You can wish it did, but it just doesn't.
I dont wish it did.
FTS-0001 talks about packed messages - which is what I'm talking about.
I'm not sure what your refering to though...
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 6 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 08:53:01 |
| Calls: | 45 |
| Files: | 21,492 |
| Messages: | 62,819 |