Text 7330, 399 rader
Skriven 2013-03-11 01:01:06 av FidoNews Robot (2:2/2.0)
Ärende: FidoNews 30:10 [03/08]: Ftsc Information
================================================
specify only port numbers per flag if required.
Ideally, a node should use the flags specifically intended for this
purpose, but that is not always the case. Be prepared to look for
addresses under any flag of the same type.
Multihomed systems
------------------
Multihomed systems or systems that are otherwise reacheable by more
than one address, may - instead of adding another A or AAAA record
to the DNS zone of the host name - repeat the flag(s) carrying the
address with another address.
Example: INA:host1.example1.tld,INA:host2.example2.tld,IBN
This method is not to be used to signal that a system is IPV4 and
IPv6 capable. Additional IPv6 capability should be advertised by
adding an AAAA record to an already listed host name.
Alternate fields
----------------
If the address is not attached to any of the Internet capability
flags, it may be present in another field (see FTS-5000).
Because of this, systems using Internet capability flags should
avoid entering data in such fields that may be mistaken for Internet
related information. For example, a node with an email flag should
not use a system name that could be confused with an email address.
DNS Distributed Nodelist
------------------------
"Precompiled" IP connection information may also be obtained from
one of the local or publicly available DNS Distributed Nodelist
(DDN) services. This is documented in FTS-5004.
Indirect Delivery
-----------------
Not all Internet tunneling methods require the originating node and
the destination node to make a direct, realtime connection. Relays
though the FTP or email servers of an ISP may serve as an example.
To avoid unusual delays, nodes using such 3rd party relays should
check regularly for new mail -- daily for non-CM nodes, and hourly
for CM nodes is recommended.
Where multiple protocols are available, the originating node should
select the most direct method, and avoid protocols that may be using
relays.
Standard Flags
--------------
Default
Flag port Description
--------------------------
INA (none) This flag sets the default Internet address used
for any non-email based flag that does not specify
its own. This flag does not carry a port number.
IP (none) Mostly used during the introduction of IP capable
systems to the nodelist, is similar to the INA flag
but may or may not specify an Internet address.
Both usages are deprecated in favour of INA.
IBN 24554 Binkp (FTS-1026 - FTS-1029)
IFC 60179 RAW ifcico (FTS-1024)
IFT 21 FTP (RFC-0959); Note there is currently no widely
accepted authentication scheme for FTP transfers by
Fidonet mailers.
ITN 23 Telnet connection using FTS-1 or any other protocol
designed for classic POTS and modem.
IVM 3141 Vmodem connection using FTS-1 or any other protocol
designed for classic POTS and modem.
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.
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.
V32 implies V22
V32B implies V22 V32
V34 implies V22 V32 V32B
V90C implies V22 V32 V32B V34
V90S implies V22 V32 V32B V34
V42 implies MNP
V42B implies V42 MNP
V32T implies V22 V32 V32B
VFC implies V22 V32 V32B
HST implies MNP
H14 implies HST MNP
H16 implies HST H14 MNP V42 V42B
X2C implies V22 V32 V32B V34
X2S implies V22 V32 V32B V34
ZYX implies V22 V32 V32B V42 V42B MNP
Z19 implies V22 V32 V32B V42 V42B MNP ZYX
Please note also that:
. the V90C and V90S flags are mutually exclusive.
. the X2C and X2S flags are 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 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, 19990627: Initial Release.
Principal Author David Hallford
Rev.2, 20000422: 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, 20040904: 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 20130104 - 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, 20130310 - 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 correcting
spelling errors.
- Added repeating of flags in case of systems
--- Azure/NewsPrep 3.0
* Origin: Home of the Fidonews (2:2/2.0)
|