Hello everybody!

=== Cut === *********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE *********************************************************************

Publication: FTS-4010
Revision: 1
Title: The PING and TRACE flags
Author(s): Michiel van der Vlist,
FTSC members and administrator.
Issue Date: 2021-04-27 =====================================================================

Status of this document
-----------------------

This document is a FidoNet Technical Standard (FTS).

This document specifies an optional FidoNet standard for the FidoNet
community.

This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.

This document supersedes and replaces FSP-1043.
FSP-1043 is preserved in the FTSC reference library as FRL-1040.


---------------------------------------------------------------------
Contents:
0. Definitions
1. Introduction.
2. The problem.
3. The solution.
4. Considerations
A. References
B. History ---------------------------------------------------------------------


0. Definitions
--------------

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [FTA-1006].


1. Introduction
---------------

The PING functionality as introduced by Ward Dossche just over two
decades ago and advertised by the PING flag is a very useful tool
in tracing and solving routing problems. This proposal is an update
of the original specs and introduces the TRACE flag.


2. The problem
--------------

In the original specification as documented by Ward Dossche in the
April 2001 Z2 nodelist trailer and the specification last documented
in FTS-5001.006, the PING functionality contains two parts: PING and
TRACE. According to that specification systems flying the PING flag
should support both PING and TRACE functionality.

Recent surveys by the author however have shown that not all systems
flying the PING flag also support the TRACE functionality. One could
argue that current practice is that TRACE functionality is optional.

Considering that the PING function alone is a very useful tool all
by itself for both routing systems and leaf systems and that TRACE
is only useful for routing systems, one may conclude that the above
current practice works well, but that it is not compliant with the
original and current specs.


3. The Solution
---------------

Split up the PING and TRACE functionality.


PING
----

Specified as exactly "PING" with no arguments. Nodes flying this
flag will adhere to the following functionality:

If a message destined to user "PING" (case insensitive) arrives
at its final destination and this final destination flies the
PING flag, then the receiving node will bounce the message back
to the original sender clearly quoting all the original via
lines.

If a message destined to "PING" arrives at its final destination
but this final destination does _not_ fly the PING flag then the
message may be deleted from the system without further action.


TRACE
-----

Specified as exactly "TRACE" with no arguments. Nodes flying this
flag will adhere to the following functionality:

If a message destined to user "PING" (case insensitive) arrives
at a node which flies the TRACE flag but is merely passing
through to another destination then the in-transit node will
notify the sender of this occurrence, clearly quoting the via
lines, and forward the original mail unaltered towards its final
destination.


For both PING and TRACE responses, the sender's name must never
be "PING" and the responses must never be addressed to "PING".


4. Considerations
-----------------

Making the TRACE function optional by separating the flags, is an
encouragement for developers and script writers to join the project.
They can choose to only implement the PING functionality and leave
TRACE functionality for later or omit it completely without
violating the specs. This will hopefully make more sysops join
the PING club.

Splitting up the PING and TRACE functionality by introducing the
TRACE flag is backward compatible. Systems flying the PING flag
that do not support TRACE need do nothing, they are compliant
with the new specs. Systems flying the PING flag that support
both PING and TRACE functionality may add the TRACE flag to their
listing. But if they do not, no harm is done, they are still
compliant with the new specs, it just does not advertise all
functionality.


A. References
-------------


[FTS-5] "The distribution nodelist".
Ben Baker, Rick Moore, and David Nugent.
1996-02-27. Obsoleted by FTS-5000.

FTS-5000] "The distribution nodelist".
FTSC Members, Administrator, and Honoured Guests.
2014-01-23.

[FTS-5001] "Nodelist flags and userflags".
FTSC Members, Administrator, and Honoured Guests
2017-08-13.

A PING robot survey.
Michiel van der Vlist.
Fidonews 38:07, 2021-02-15.

Ping robot survey, a follow up.
Michiel van der Vlist.
Fidonews 38:15, 2021-04-12.


B. History
----------

Rev.1, 2021-04-27: Initial release.


=== Cut ===

Please submit any comments or suggestions by 2021-05-06.

Thank you,

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Good ${greeting_time}, Andrew!

29 Apr 2021 12:29:36, you wrote to All:

Publication: FTS-4010
This document supersedes and replaces FSP-1043.
FSP-1043 is preserved in the FTSC reference library as FRL-1040.

The FSP should be out for at least a year to be promoted to the FTS.

FSP-1043 is dated 2021-04-27. Two days definitely are not enough.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... that's why I really dislike fools.
--- /bin/vi
* Origin: ::1 (2:5020/545)

Hello Alexey!

29 Apr 21 20:39, you wrote to me:

The FSP should be out for at least a year to be promoted to the FTS. FSP-1043 is dated 2021-04-27. Two days definitely are not enough.

Thank you for your input. This particular proposal is very simple, and is already in use in a significant portion of FidoNet. If you have any other comments, please feel free to share them here.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Andrew!

29 Apr 21 12:29, you wrote to All:

Hello everybody!

=== Cut === *********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE *********************************************************************

Publication: FTS-4010
Revision: 1
Title: The PING and TRACE flags
Author(s): Michiel van der Vlist,
FTSC members and administrator.
Issue Date: 2021-04-27 =====================================================================

Although limits on the maximal length of line have been lifted to some extent,
why do these two flag have a unprecedented length.

As these two flags are likely to come as a pair, 11 characters are needed
for their presense. E,g. PG and TR would only use 6.

Kees

--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

04 May 2021 13:52, you wrote to Andrew Leary:

Although limits on the maximal length of line have been lifted to
some extent, why do these two flag have a unprecedented length.

As these two flags are likely to come as a pair, 11 characters are
needed for their presense. E,g. PG and TR would only use 6.

Maybe PING:T instead of PING,TRACE ...?

Carlos
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: costa blanca, Spain (2:341/234.1)

Maybe PING:T instead of PING,TRACE ...?

Or maybe abandon that stupid PING/TRACE idea entirely? With the Fidoweb working (even with certain ZC guys and their years long grudge against major Fidoweb operators) there seems like there's any need to check the routing with a shitload of netmail.



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

On 07/06/21 17:05, Björn Felten -> Carlos Navarro wrote:
 CN>> Maybe PING:T instead of PING,TRACE ...?

  Or maybe abandon that stupid PING/TRACE idea entirely? With the

Fidoweb

working (even with certain ZC guys and their years long grudge against major
Fidoweb operators) there seems like there's any need to check the
routing with
a shitload of netmail.

I don't agree. Regardless of how many links you have, there
will always be the need for classic netmail delivery.


--
_
..-----________________--_ ________.--'-`--._____ Flavio Bessa \____==================_) \_'===================` 4:801/188
_,--___.-|__|-.______|=====/ `---' fcbessa@gmail.com
`---------._ ~~~~~| Rio de Janeiro
`-._ - - - ,' Brasil
\_____,-' Visit Zone4 Website at: https://fido.bbs.docksud.com.ar/wiki/doku.php?id=fidonet:nodos
--- Thunderbird/MacOS 78.6.0
* Origin: Andromeda - Saturn's Orbit NNTP Gateway, Brazil (4:801/188)

Hello Carlos!

07 Jun 21 21:44, you wrote to Kees van Eeten:

Although limits on the maximal length of line have been lifted
to some extent, why do these two flag have a unprecedented
length.

As these two flags are likely to come as a pair, 11 characters
are needed for their presense. E,g. PG and TR would only use 6.

Maybe PING:T instead of PING,TRACE ...?

The FTSC documents current practice in FidoNet. The PING and TRACE flags were implemented this way by ZC2, followed shortly by ZC1. Personally, if the length of the flags were a serious issue, they could easily be shortened to PNG and TRC, but this would have to be done by the *Cs, not directly by the FTSC.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hi Bj”rn,

On 2021-06-07 22:05:25, you wrote to Carlos Navarro:

Maybe PING:T instead of PING,TRACE ...?

Or maybe abandon that stupid PING/TRACE idea entirely?

It's not stupid at all! It's a very useful tool to test netmail routing, without bothering sysops, and depend on them sending replies. (You take the human factor out of it).

With the Fidoweb working (even with certain ZC guys and their years
long grudge against major Fidoweb operators) there seems like there's
any need to check the routing with a shitload of netmail.

The fidoweb is more about echomail then netmail. But of course netmail will also travel along those "none standard" routes. The more reason to have a tool that can show netmail paths, when it travels these non standard routes...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Good ${greeting_time}, Wilfred!

08 Jun 2021 09:11:54, you wrote to Bj”rn Felten:

Maybe PING:T instead of PING,TRACE ...?

Or maybe abandon that stupid PING/TRACE idea entirely?

It's not stupid at all! It's a very useful tool to test netmail
routing, without bothering sysops, and depend on them sending
replies. (You take the human factor out of it).

You too: the sysops see these messages anyway, and if there are too many, that becomes very annoying.

That's exactly the reason why I've removed the PING flag from my nodelist line and shot down the robot. Once anyone would try to send it to me, they'll get a manually crafted fuqoff reply, or, most likely, no reply at all.

The more reason to have a tool that can show netmail paths, when it travels these non standard routes...

... means the more reason to not supporting it.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: ::1 (2:5020/545)

Hi Alexey,

On 2021-06-08 13:11:30, you wrote to me:

Maybe PING:T instead of PING,TRACE ...?

Or maybe abandon that stupid PING/TRACE idea entirely?

It's not stupid at all! It's a very useful tool to test netmail
routing, without bothering sysops, and depend on them sending
replies. (You take the human factor out of it).

You too: the sysops see these messages anyway, and if there are too many, that becomes very annoying.

That's by choice. You could configure your system so it doesn't archive the received and sent PING mails, so you would see none at all.

So you are annoyed by your own inability to configure your system?

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Wilfred!

08 Jun 21 13:05, you wrote to Alexey Vissarionov:

That's by choice. You could configure your system so it doesn't
archive the received and sent PING mails, so you would see none at
all.

MBSE works this way; the only way I know that a PING or TRACE message was processed is if I check the logs.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hi Andrew,

On 2021-06-08 07:11:10, you wrote to me:

That's by choice. You could configure your system so it doesn't
archive the received and sent PING mails, so you would see none at
all.

MBSE works this way; the only way I know that a PING or TRACE message was processed is if I check the logs.

In FMail it's configurable:

Keep PING requests

Keep a copy of PING request messages after processing. These
are the received messages addressed to PING on your system.
The copy is saved in the received netmail area.

BTW: There is no option to keep TRACE requests, because
they are in transit mails destined for other systems. They
are forwarded to their destination without keeping a copy.

Keep PING responses

Keep a copy of PING response messages after they are sent.
The copy is saved in the sent netmail area.

Keep TRACE responses

Keep a copy of TRACE response messages after they are sent.
The copy is saved in the sent netmail area.


If I set them all to 'No', I get the same behaviour as in your situation.


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Good ${greeting_time}, Wilfred!

08 Jun 2021 13:05:14, you wrote to me:

Maybe PING:T instead of PING,TRACE ...?

Or maybe abandon that stupid PING/TRACE idea entirely?

It's not stupid at all! It's a very useful tool to test netmail
routing, without bothering sysops, and depend on them sending
replies. (You take the human factor out of it).

You too: the sysops see these messages anyway, and if there are
too many, that becomes very annoying.

That's by choice. You could configure your system so it doesn't
archive the received and sent PING mails, so you would see none
at all. So you are annoyed by your own inability to configure
your system?

I prefer to see what is going on. And how to configure _my_ system is _my_ choise.

And lots of messages sent to _my_ system could be annoying for _me_.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net
--- /bin/vi
* Origin: ::1 (2:5020/545)

Good ${greeting_time}, Wilfred!

08 Jun 2021 13:26:12, you wrote to Andrew Leary:

That's by choice. You could configure your system so it doesn't
archive the received and sent PING mails, so you would see none
at all.

MBSE works this way; the only way I know that a PING or TRACE
message was processed is if I check the logs.

In FMail it's configurable

In HPT you may simply rewrite the robot (that's just a few lines of Perl code) any way you wish.

Whether you _can_ do that, of course.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: ::1 (2:5020/545)

Hi Alexey,

On 2021-06-08 14:46:00, you wrote to me:

That's by choice. You could configure your system so it doesn't
archive the received and sent PING mails, so you would see none
at all. So you are annoyed by your own inability to configure
your system?

I prefer to see what is going on.

Do you read in-transit netmail?

And how to configure _my_ system is _my_ choise.

Of course, but then it's your own choice to get annoyed...


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Good ${greeting_time}, Wilfred!

08 Jun 2021 14:15:14, you wrote to me:

That's by choice. You could configure your system so it doesn't
archive the received and sent PING mails, so you would see none
at all. So you are annoyed by your own inability to configure
your system?

I prefer to see what is going on.

Do you read in-transit netmail?

No (and you can see the ENC flag in my nodelist line). But I read netmail addressed to my node.

And how to configure _my_ system is _my_ choise.

Of course, but then it's your own choice to get annoyed...

I solved this problem in the most effective way: no robot - no problem.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... that's why I really dislike fools.
--- /bin/vi
* Origin: ::1 (2:5020/545)

Hi Alexey,

On 2021-06-08 15:46:46, you wrote to me:

And how to configure _my_ system is _my_ choise.

Of course, but then it's your own choice to get annoyed...

I solved this problem in the most effective way: no robot - no problem.

I think it's the wrong solution for a non-existent problem! ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Wilfred van Velzen wrote to Alexey Vissarionov <=-

I solved this problem in the most effective way: no robot - no problem.

I think it's the wrong solution for a non-existent problem! ;)

It is a problen when you don't know how to set up your system correctly.

For the record, I support the PING and TRACE flags. I have used the PING capability quite often over the years and find it very useful. MBSE
supports PING and we're working on supporting TRACE also.

Later,
Sean

... "Talk is cheap. Show me the code." - Linus Torvalds
--- MultiMail/Linux
* Origin: Outpost BBS (1:18/200)

Hello Sean!

08 Jun 21 17:58, you wrote to Wilfred van Velzen:

For the record, I support the PING and TRACE flags. I have used the
PING capability quite often over the years and find it very useful.
MBSE supports PING and we're working on supporting TRACE also.

MBSE supports both PING and TRACE functionality.

Andrew


--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

07 Jun 2021 21:58, you wrote to me:

As these two flags are likely to come as a pair, 11 characters
are needed for their presense. E,g. PG and TR would only use 6.

Maybe PING:T instead of PING,TRACE ...?

The FTSC documents current practice in FidoNet. The PING and TRACE
flags were implemented this way by ZC2, followed shortly by ZC1. Personally, if the length of the flags were a serious issue, they
could easily be shortened to PNG and TRC, but this would have to be
done by the *Cs, not directly by the FTSC.

Yes Andrew, I know. Thank you. Just an informal comment to Kee's comment.

I just thought that, as TRACE always goes with PING, it could be as a parameter instead of a separate flag.
However, a node could perfectly have just the TRACE flag (at least Fmail supports this).

But anyway, it's a bit late :-) and I suppose it's fine like it is.

Carlos
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: costa blanca, Spain (2:341/234.1)

29 Apr 2021 12:29, you wrote to All:

=== Cut ===
Publication: FTS-4010
Revision: 1
Title: The PING and TRACE flags

[...]

PING
----

Specified as exactly "PING" with no arguments. Nodes flying this
flag will adhere to the following functionality:

If a message destined to user "PING" (case insensitive) arrives
at its final destination and this final destination flies the
PING flag, then the receiving node will bounce the message back

^^^^^^^^^^^^^^^^^^

to the original sender clearly quoting all the original via
lines.

Should the body content of the original message be included, or just the via lines?
I've seen both cases.

Carlos
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: costa blanca, Spain (2:341/234.1)

Hi Carlos,

On 2021-06-09 10:55:38, you wrote to Andrew Leary:

PING
----

Specified as exactly "PING" with no arguments. Nodes flying this
flag will adhere to the following functionality:

If a message destined to user "PING" (case insensitive) arrives
at its final destination and this final destination flies the
PING flag, then the receiving node will bounce the message back

^^^^^^^^^^^^^^^^^^

to the original sender clearly quoting all the original via
lines.

Should the body content of the original message be included, or just the via lines? I've seen both cases.

The body of the message is nice to have, but not a requirement. VIA lines are essential IMHO, but unfortunately I've seen PING responses without them...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Sean,

On Tuesday June 08 2021 17:58, you wrote to Wilfred van Velzen:

For the record, I support the PING and TRACE flags. I have used the
PING capability quite often over the years and find it very useful.
MBSE supports PING and we're working on supporting TRACE also.

I did several tests to provoke a response from your PING, but so far, six hours later, I have received no response. The last attempt was crashed to 1:18/200 at 09:25 UTC.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Andrew Leary wrote to Sean Dennis <=-

MBSE supports both PING and TRACE functionality.

I stand corrected. I misunderstood you when we discussed this last week ...

I think that the return message for a PING request should have the subject
of "PONG".

Later,
Sean

... Windows: Just another pane in the glass.
--- MultiMail/Linux
* Origin: Outpost BBS (1:18/200)

Hi Michiel,

On 2021-06-09 17:23:02, you wrote to Sean Dennis:

For the record, I support the PING and TRACE flags. I have used the
PING capability quite often over the years and find it very useful.
MBSE supports PING and we're working on supporting TRACE also.

MvdV> I did several tests to provoke a response from your PING, but so far, six
MvdV> hours later, I have received no response. The last attempt was crashed to
MvdV> 1:18/200 at 09:25 UTC.

I got a response in about 12 minutes after sending the routed netmail.

The return path:

@Via 1:18/200@fidonet @20210609.161554.UTC mbfido 1.0.7.22
@Via 1:3634/12 @20210609.161750.UTC SBBSecho 3.11-Linux r3.173
@Via 1:229/426 @20210609.121709.LST D'Bridge 4
@Via 1:229/426@fidonet @20210609.121709.LST O/T-Track+ 2.85
@Via 2:280/464 @20210609.162142.681.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Wilfred van Velzen wrote to Michiel van der Vlist:

MvdV> I did several tests to provoke a response from your PING, but so far, six
MvdV> hours later, I have received no response. The last attempt was crashed to
MvdV> 1:18/200 at 09:25 UTC.

I have not seen any messages to me from Michiel in this echo nor via
netmail. That's weird ...

I got a response in about 12 minutes after sending the routed netmail.

That's good to know it went that quickly!

@Via 1:18/200@fidonet @20210609.161554.UTC mbfido 1.0.7.22
@Via 1:3634/12 @20210609.161750.UTC SBBSecho 3.11-Linux r3.173
@Via 1:229/426 @20210609.121709.LST D'Bridge 4
@Via 1:229/426@fidonet @20210609.121709.LST O/T-Track+ 2.85
@Via 2:280/464 @20210609.162142.681.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815

That path looks correct as I am connected to both Mark Lewis for regional
mail and Nick Andre as my regular Fidonet feed.

This is the first I've heard anything about it because my system doesn't
notify me about PING and TRACE requests (as it shouldn't since this is an administrative issue).

Thanks for your report. I greatly appreciate it.

-- Sean



--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: Outpost BBS (1:18/200)

Hi Sean,

On 2021-06-09 19:40:55, you wrote to me:

MvdV> I did several tests to provoke a response from your PING, but
so far, six
MvdV> hours later, I have received no response. The last attempt was
crashed to
MvdV> 1:18/200 at 09:25 UTC.

I have not seen any messages to me from Michiel in this echo nor via netmail. That's weird ...

That's weird indeed. I hope it isn't because someone is filtering, that would be XAB...

I got a response in about 12 minutes after sending the routed
netmail.

That's good to know it went that quickly!

Some would call it slow. ;-)

@Via 1:18/200@fidonet @20210609.161554.UTC mbfido 1.0.7.22
@Via 1:3634/12 @20210609.161750.UTC SBBSecho 3.11-Linux r3.173
@Via 1:229/426 @20210609.121709.LST D'Bridge 4
@Via 1:229/426@fidonet @20210609.121709.LST O/T-Track+ 2.85
@Via 2:280/464 @20210609.162142.681.UTC FMail-lnx64(Toss)
2.1.0.18-B20170815

That path looks correct as I am connected to both Mark Lewis for regional mail and Nick Andre as my regular Fidonet feed.

I you want you could optimize your route for interzonal netmail, by sending some directly through Nick, since you already have a secure link.


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)