Publication: FSP-xxxx Revision: 1 Title: The PING and TRACE flags Author(s): Michiel van der Vlist Issue Date: 17 April 2021 =====================================================================
Status:
This document is a Fidonet Standards Proposal (FSP) - it specifies the best current practices for the Fidonet community, and requests discussion and suggestions for improvements. It is released to the public domain, and may be used, copied or modified for any purpose whatever.
--------------------------------------------------------------------- Contents: 0. Definitions 1. Introduction. 2. The problem. 3. The solution. 4. Considerations A. References B. History C. Contact data ---------------------------------------------------------------------
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 centuries 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 practise 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 practise works well, but that it is not complient 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 should never be addressed to "PING".
4. Considerations -----------------
Making the TRACE function optional by seperating 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 ommit 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 complient 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 complient with the new specs, it just does not advertise all functionality.
A. References -------------
[FTS-5] "The distribution nodelist", Ben Baker, Rick Moore. February 1989. Obsoleted by FTS-5000.
FTS-5000] "The distribution nodelist". FTSC Members, Administrator and Honoured Guests Januari 2014.
[FTS-5001] "Nodelist flags and userflags". FTSC Members, Administrator and Honoured Guests Augustus 2017.
A PING robot survey. Michiel van der Vlist Fidonews 38:07, 15 Februari 2021.
Ping robot survey, a follow up. Michiel van der Vlist Fidonews 38:15, 12 April 2021.
B. History ----------
Rev,1, 2021-04-17: Initial release.
C. Contact Data ---------------
Michiel van der Vlist Fidonet: 2:280/5555 E-mail: pa0mmv at vrza dot org
