forum.wfido.ru  

Вернуться   forum.wfido.ru > Прочие эхи > RU.FIDONET.DIGEST

 
 
Опции темы Опции просмотра
  #1  
Старый 04.05.2021, 10:52
Vladimir Fyodorov
Guest
 
Сообщений: n/a
По умолчанию FTSC_PUBLIC: FTS-4010 Final Review

Vladimir Fyodorov написал(а) к All в May 21 09:41:56 по местному времени:


> FTS-4010 "The PING and TRACE flags" принят в рекордный срок, через два
> дня после опубликования соответствующего FSP, несмотря на то, что
> традиционно проект должен числится в черновиках не менее года.

=============================================================================
* Area : FTSC_PUBLIC
* From : Andrew Leary, 1:320/219 (29 Апреля 2021 12:29)
* Subj : FTS-4010 Final Review
=============================================================================
Нello everybody!

=== Cut ===
*******************************************************************
FTSC FIDONET TECНNICAL 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. Нistory
---------------------------------------------------------------------


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

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL
NOT", "SНOULD", "SНOULD 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 Нonoured Guests.
2014-01-23.

[FTS-5001] "Nodelist flags and userflags".
FTSC Members, Administrator, and Нonoured 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. Нistory
----------

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


=== Cut ===

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


=============================================================================
* Area : FTSC_PUBLIC
* From : Alexey Vissarionov, 2:5020/545 (29 Апреля 2021 20:39)
* To : Andrew Leary
* Subj : FTS-4010 Final Review
=============================================================================
AL> Publication: FTS-4010
AL> This document supersedes and replaces FSP-1043.
AL> 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.
=============================================================================


=============================================================================
* Area : FTSC_PUBLIC
* From : Andrew Leary, 1:320/219 (29 Апреля 2021 18:50)
* To : Alexey Vissarionov
* Subj : FTS-4010 Final Review
=============================================================================
AV> The FSP should be out for at least a year to be promoted to the FTS.
AV> 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.
=============================================================================


--- GoldED+/W64-MSVC 1.1.5-b20170303
Ответить с цитированием
 


Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 12:47. Часовой пояс GMT +4.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc. Перевод: zCarot