= Сообщение: 2331 из 7124 ====================================== FTSC_PUBLIC = От : Fred Riccio 1:132/174 27 Mar 17 10:17:52 Кому : Ward Dossche 27 Mar 17 10:17:52 Тема : Repost: Proposed changes: FTS-5001.006 - Part 3 FGHI : area://FTSC_PUBLIC?msgid=1:132/174+58d8e65d На : area://FTSC_PUBLIC?msgid=2:292/854+a4057252 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== 27 Mar 17 15:54, Ward Dossche wrote to Fred Riccio:
WD> The message displays grunged on my system, obviously too long.
WD> Can you chop it up pls?
----- FTS-5001.006.Part3 begins -----
Email Flags -----------
To use the flag for any Email method providing for return receipts (currently ITX and ISE) a node *must* have them enabled and send such receipts within 24 hours of receiving a file.
Flag Description --------------------------
IEM Indicates an unspecified mail tunnelling method (old usage, similar to IP), or sets the default email address for other flags (similar to INA)
ITX TransX encoding for email tunnelling with receipts enabled. IUC uuencoding of mail bundles IMI MIME encoding of mail bundles ISE SEAT protocol for Email tunnelling with receipts. enabled; should always be accompanied by IUC and/or IMI. > EVY Voyager-compatible > EMA Everything not defined by the aforementioned individual flags
The e-mail flags do not carry a port number.
Reliability -----------
It should be noted that only some of these Internet based methods (currently IBN, IFC, ITN, IVM, ITX and ISE) can give the sender a proof of receipt of a file by the addressee, like FTS-0001 does.
Other methods have no guarantee of reliability, so they shouldn't be used to transmit critical data.
Also, nodelist segment maintainers should take into account the presence of at least one of these reliable protocols when deciding on application for Fidonet membership by nodes without a dial-up connection.
5.10. Robot flags -----------------
PING ----
Specified as exactly "PING" with no arguments. Nodes flying this flag will adhere to the following functionality:
1) PING-function:
If a message destined to "PING" 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 inbound-queue without further follow-up.
2) TRACE-function:
If a message destined to "PING" arrives at a node which flies the PING-flag but is merely passing-through to another destination then the in-transit node will notify the sender of this occurrence and will forward the original mail unaltered towards its final destination.
WARNING: the sender's name (in either direction) must *NEVER* be "PING".
5.11. Flag Redundancies -----------------------
Only the smallest possible set of flags should be used in each entry.
Since different people might have different perception of modem flag redundancies, the FTSC decided to provide a standard table.
The relation "implies" means either that the first protocol requires all the others as a fallback or that to all practical purposes all modems which have been manufactured until today (and conceivably even future ones) implemented the other protocols anyway.
For example, the protocol V.32bis implies V.32 because it's required as a fallback; on the other hand, V.32Terbo implies V.32bis because practically all modems with V.32Terbo also had V.32bis to connect to existing modems, even though it wasn't required in the protocol specifications.
Please note also that: . the V90C and V90S flags are mutually exclusive. . the X2C and X2S flags are mutually exclusive. . no modem has at the same time the US Robotics proprietary protocols and the ZyXEL ones; so, use of any flag in the group HST, H14, H16, X2S and X2C is incompatible with any of the ZYX and Z19 flags, and vice versa. . all X? flags are mutually exclusive. . the CM flag is incompatible with any of the #??, !?? or T?? flags. . the CM flag implies ICM; ICM should not be used unless CM is impossible.
6. User flags -------------
It is impossible to document all user flags in use. The FTSC makes no attempt at it. This document lists those flags which got at least some kind of official sanction or were deemed of technical interest by FTSC.
6.1 Format Of User Flags ------------------------
U,x..x
A user-specified string, which may contain any alphanumeric character except blanks. This string may contain one to thirty-two characters of information that may be used to add user-defined data to a specific nodelist entry. The character "U" must not be repeated, eg, ",U,XXX,YYY,ZZZ" not ",U,XXX,U,YYY,UZZZ". The 32 character limitation is per userflag, not for the total of all userflags.
New implementations must place a comma after the initial "U" before the user flags. Some implementations will not place a separating comma between the "U" and the first user flag, but this practice is deprecated. Implementations should be prepared to read flags in this format, and must strip the "U" from the flag before analysis in this case.
Entries following the "U" flag must be of a technical or administrative nature. While experimentation of new software functions using this flag is encouraged, advertisement is strictly prohibited.
For applications other than those shown, or if you have questions concerning the use of this field, please contact your Regional or Zone Coordinator.
Developers should note that the distinction between "normal" flags and user flags is a non-technical, purely political one. It often happened that a user flag was "promoted" to regular status, and the reverse could conceivably happen. It is recommended that, while parsing nodelist entries, no distinction at all be done between the two categories of flags.
6.2. Mail Oriented User Flags -----------------------------
Flag Meaning
ZEC Zone EchoMail Coordinator. Not more than one entry in the zone segment may carry this flag and that entry must be the current Zone EchoMail Coordinator.
REC Regional EchoMail Coordinator. Not more than one entry in any region may carry this flag and that entry must be the current Regional EchoMail Coordinator.
NEC Network EchoMail coordinator. Not more than one entry in any net may carry this flag and that entry must be the current Network EchoMail Coordinator of that Net.
NC Network Coordinator. This flag is ONLY to be used by the Network Coordinator of a net which has split the duties of NC and Host and the NC does NOT occupy the Net/0 position in the nodelist.
SDS Software Distribution System
SMH Secure Mail Hub
RPK Regional Pointlist Keeper. This user-flag identifies the person who compiles the region-pointlist (only 1 entry per region allowed)
NPK Net Pointlist Keeper. This user-flag identifies the person who compiles the net-pointlist (only 1 entry per net allowed)
ENC This node accepts inbound encrypted mail and will route it like other mail
CDP This node will accept points auto-created by the CD-point software.
A. References -------------
[FTS-0005] "The distribution nodelist", Ben Baker, Rick Moore. February 1989.
[FSC-0009] "Nodelist Flag Changes Draft Document", Ray Gwinn, David Dodell. November 1987.
[FSC-0040] "Extended Modem Handling", Michael Shiels. February 1990.
[FSC-0062] "A Proposed Nodelist flag indicating Online Times of a Node", David J. Thomas. April 1996.
[FSC-0075] "ISDN capability flags in the Nodelist", Jan Ceuleers. October 1993
[FSC-0091] "ISDN nodelist flags", Arjen Lentz. October 1995.
[FRL-1036] "IPv6 numbers in the nodelist". March 2010
[Policy] "FidoNet Policy Document" v4.07 - June 9, 1989.
B. History ----------
Rev.1, 1999-06-27: Initial Release. Principal Author David Hallford
Rev.2, 2000-04-22: new draft by Gino Lucrezi; major changes: - reorganization of flags classification - rewrite for clarification of internet connection flags - note on difference between "regular" and "user" flags - description of flag redundancies new draft by Gino Lucrezi with input from others - removed Andreas Klein from authors - ENC flag - distinction of direct and indirect IP connectivity - requirement for return receipts with ITX and ISE - additional requirement for IP-nodes with CM flag - clarification on some flag redundancies new draft by Gino Lucrezi with input from others - corrected Z3MH and added note on changing of ZMHs
Rev.2, 2004-09-04: re-re-draft by FTSC. - Changed header style - Added Introduction and Purpose sections - Added Syntax section - Rewrite of Internet connectivity section - Removed IP flag conversions - Merged IP flags and default ports tables - Added ifcico to compatibility table - Fixed Txy flag status (user flag >normal flag) - Removed ISDN conversions and redundant 300 bps limit (specified in FTS-5000) - Removed 32 character flag limitation - Removed obsolete flag: V21 - Removed obsolete flag: V33 - Removed obsolete flag: MAX - Removed obsolete flag: K12 - Updated V?? flags - Added ICM flag - Added PING flag - Added flag redundancy table
Rev.3 2013-01-04 - There is no version 3. The above version 20040904 should have been labelled version 3, but due to a clerical error it was also labelled version 2. So there are two version 2's. Rather than attempting to correct the error, which would probably not have succeeded as it is next to impossible to recall a file that was hatched many years ago, it was decided to leave things as they are, skip version 3 and carry on with version 4.
Rev.4, 2013-03-10 - Updated the paragraph on DDN in section 5.9 to reflect that the DDN project is now documented in separate document FTS-5004. - Upgraded the description of the MN flag - Removed reference to port numbers for e-mail flags. - Added IPv6 where literal IP numbers are referenced. - Removed reference to Z5 and Z6. (#nn flags) - Added "binkd w/SRIF FREQ processor" to list of programmes qualifying for XW freq flag. - Dropped NSMH, RSMH, ZSMH and ISMB. Obsolete. - Clarified meaning of ITN and IVM flag. - Various small changes in wording and correc- ting spelling errors. - Added repeating of flags in case of systems having multiple adresses.
> Rev.5, 2014-07-01 - Reformatted to comply with FTA-1002.003 - Added INO4 flag - Corrected some spelling errors
> Rev.6, 2017-03-27 - Added EVY and EMA flags > - History: Changed second occurance of history > Rev 4 to Rev 5
