Updated FTS documentation
This commit is contained in:
402
html/ftsc/fts-5001.html
Normal file
402
html/ftsc/fts-5001.html
Normal file
@@ -0,0 +1,402 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>The Distribution Nodelist.</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||
<BODY
|
||||
BGCOLOR="#FFFFFF"
|
||||
TEXT="#000000"
|
||||
LINK="#0000FF"
|
||||
VLINK="#000080"
|
||||
ALINK="#FF0000"
|
||||
>
|
||||
<TT>
|
||||
**********************************************************************<BR>
|
||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE<BR>
|
||||
**********************************************************************<BR>
|
||||
<BR>
|
||||
Publication: FTS-5001<BR>
|
||||
Revision: 1<BR>
|
||||
Title: NODELIST FLAGS AND USERFLAGS<BR>
|
||||
Author(s): Colin Turner, Andreas Klein, Michael McCabe,<BR>
|
||||
David Hallford, Odinn Sorensen<BR>
|
||||
<BR>
|
||||
Revision Date: 27 June 1999<BR>
|
||||
Expiry Date: 27 June 2001 <BR>
|
||||
----------------------------------------------------------------------<BR>
|
||||
Contents:<BR>
|
||||
1. Authorized Flags<BR>
|
||||
2. Userflags<BR>
|
||||
----------------------------------------------------------------------<BR>
|
||||
<BR>
|
||||
Status of this document<BR>
|
||||
-----------------------<BR>
|
||||
<BR>
|
||||
This document is a Fidonet Standard (FTS).<BR>
|
||||
<BR>
|
||||
This document specifies a Fidonet standard for the Fidonet<BR>
|
||||
community.<BR>
|
||||
<BR>
|
||||
This document is released to the public domain, and may be used,<BR>
|
||||
copied or modified for any purpose whatever.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
Abstract<BR>
|
||||
--------<BR>
|
||||
<BR>
|
||||
Current practice for Fidonet Technology Networks (FTN) is to<BR>
|
||||
maintain a nodelist used to store the details of the nodes in<BR>
|
||||
the network, and the network structure. Flags are used in this<BR>
|
||||
nodelist to aid automatic and manual control of various tasks.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
1. Authorized flags<BR>
|
||||
-------------------<BR>
|
||||
<BR>
|
||||
Flags authorized for use in the Fidonet nodelist:<BR>
|
||||
<BR>
|
||||
A: OPERATING CONDITION FLAGS:<BR>
|
||||
<BR>
|
||||
Flag Meaning<BR>
|
||||
<BR>
|
||||
CM Node accepts mail 24 hours a day<BR>
|
||||
MO Node does not accept human callers<BR>
|
||||
LO Node accepts calls Only from Listed<BR>
|
||||
FidoNet addresses<BR>
|
||||
<BR>
|
||||
B. MODEM FLAGS:<BR>
|
||||
The following flags define modem protocols supported:<BR>
|
||||
<BR>
|
||||
Flag Meaning<BR>
|
||||
<BR>
|
||||
V21 CCITT V.21 300 bps full duplex<BR>
|
||||
V22 CCITT V.22 1200 bps full duplex<BR>
|
||||
V29 CCITT V.29 9600 bps half duplex<BR>
|
||||
V32 CCITT V.32 9600 bps full duplex<BR>
|
||||
V32b ITU-T V.32 bis 14400 bps full duplex<BR>
|
||||
V32T V.32 Terbo<BR>
|
||||
V33 CCITT V.33<BR>
|
||||
V34 CCITT V.34<BR>
|
||||
HST USR Courier HST<BR>
|
||||
H14 USR Courier HST 14.4<BR>
|
||||
H16 USR Courier HST 16.8<BR>
|
||||
H96 Hayes V9600<BR>
|
||||
MAX Microcom AX/96xx series<BR>
|
||||
PEP Packet Ensemble Protocol<BR>
|
||||
CSP Compucom Speedmodem<BR>
|
||||
ZYX Zyxel series<BR>
|
||||
VFC V.Fast Class<BR>
|
||||
Z19 Zyxel 19,200 modem protocol<BR>
|
||||
V90C ITU-T V.90 modem Client <BR>
|
||||
V90S ITU-T V.90 Server. <BR>
|
||||
X2C US Robotics x2 client. <BR>
|
||||
X2S US Robotics x2 server. <BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
The following flags define type of error correction available. A<BR>
|
||||
separate error correction flag should not be used when the error<BR>
|
||||
correction type can be determined by the modem flag. For instance<BR>
|
||||
a modem flag of HST implies MNP.<BR>
|
||||
<BR>
|
||||
Flag Meaning<BR>
|
||||
<BR>
|
||||
MNP Microcom Networking Protocol error correction<BR>
|
||||
of type MNP1 to MNP4<BR>
|
||||
V42 LAP-M error correction w/fallback to MNP<BR>
|
||||
<BR>
|
||||
C: COMPRESSION FLAGS:<BR>
|
||||
<BR>
|
||||
The following flags define the type(s) of compression of mail<BR>
|
||||
packets supported.<BR>
|
||||
<BR>
|
||||
Flag Meaning<BR>
|
||||
<BR>
|
||||
MN No compression supported<BR>
|
||||
<BR>
|
||||
The following flags define the type(s) of data compression<BR>
|
||||
available.<BR>
|
||||
<BR>
|
||||
V42b ITU-T V42bis<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
D: FILE/UPDATE REQUEST FLAGS:<BR>
|
||||
<BR>
|
||||
The following flags indicate the types of file/update requests<BR>
|
||||
supported.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
|--------------------------------------------------|<BR>
|
||||
| | Bark | WaZOO |<BR>
|
||||
| |---------------------|---------------------|<BR>
|
||||
| | File | Update | File | Update |<BR>
|
||||
| Flag | Requests | Requests | Requests | Requests |<BR>
|
||||
|------|----------|----------|----------|----------|<BR>
|
||||
| XA | Yes | Yes | Yes | Yes |<BR>
|
||||
| XB | Yes | Yes | Yes | No |<BR>
|
||||
| XC | Yes | No | Yes | Yes |<BR>
|
||||
| XP | Yes | Yes | No | No |<BR>
|
||||
| XR | Yes | No | Yes | No |<BR>
|
||||
| XW | No | No | Yes | No |<BR>
|
||||
| XX | No | No | Yes | Yes |<BR>
|
||||
|--------------------------------------------------|<BR>
|
||||
<BR>
|
||||
E: GATEWAY FLAG:<BR>
|
||||
<BR>
|
||||
The following flag defines gateways to other domains (networks).<BR>
|
||||
<BR>
|
||||
Flag Meaning<BR>
|
||||
<BR>
|
||||
Gx..x Gateway to domain 'x..x', where 'x..x` is a string<BR>
|
||||
of alphanumeric characters. Valid values for<BR>
|
||||
'x..x' are assigned by the FidoNet International<BR>
|
||||
Coordinator. Current valid values of 'x..x' may<BR>
|
||||
be found in the notes at the end of the FidoNet<BR>
|
||||
nodelist.<BR>
|
||||
<BR>
|
||||
F: MAIL PERIOD FLAGS:<BR>
|
||||
The following flags define the dedicated mail periods supported.<BR>
|
||||
They have the form "#nn" or !nn where nn is the UTC hour the mail<BR>
|
||||
period begins, # indicates Bell 212A compatibility, and !<BR>
|
||||
indicates incompatibility with Bell 212A.<BR>
|
||||
<BR>
|
||||
Flag Meaning<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
#01 Zone 5 mail hour (01:00 - 02:00 UTC)<BR>
|
||||
#02 Zone 2 mail hour (02:30 - 03:30 UTC)<BR>
|
||||
#08 Zone 4 mail hour (08:00 - 09:00 UTC)<BR>
|
||||
#09 Zone 1 mail hour (09:00 - 10:00 UTC)<BR>
|
||||
#18 Zone 3 mail hour (18:00 - 19:00 UTC)<BR>
|
||||
#20 Zone 6 mail hour (20:00 - 21:00 UTC)<BR>
|
||||
<BR>
|
||||
NOTE: When applicable, the mail period flags may<BR>
|
||||
be strung together with no intervening commas, eg. <BR>
|
||||
"#02#09". Only mail hours other than that<BR>
|
||||
standard within a node's zone should be given.<BR>
|
||||
Since observance of mail hour within one's zone is<BR>
|
||||
mandatory, it should not be indicated.<BR>
|
||||
<BR>
|
||||
G: ISDN CAPABILTY FLAGS:<BR>
|
||||
<BR>
|
||||
Nodelist Specification of minimal support required for this flag;<BR>
|
||||
flag any additional support to be arranged via agreement <BR>
|
||||
between users<BR>
|
||||
<BR>
|
||||
V110L ITU-T V.110 19k2 async ('low').<BR>
|
||||
V110H ITU-T V.110 38k4 async ('high').<BR>
|
||||
V120L ITU-T V.120 56k async, layer 2 framesize 259, window 7,<BR>
|
||||
modulo 8.<BR>
|
||||
V120H ITU-T V.120 64k async, layer 2 framesize 259, window 7,<BR>
|
||||
modulo 8.<BR>
|
||||
X75 ITU-T X.75 SLP (single link procedure) with 64kbit/s B<BR>
|
||||
channel; layer 2 max.framesize 2048, window 2, non-ext.<BR>
|
||||
mode (modulo 8); layer 3 transparent (no packet layer).<BR>
|
||||
ISDN Other configurations. Use only if none of the above<BR>
|
||||
fits.<BR>
|
||||
<BR>
|
||||
NOTE: No flag implies another. Each capability MUST be specifically<BR>
|
||||
listed.<BR>
|
||||
If no modem connects are supported, the nodelist speed field should<BR>
|
||||
be 300.<BR>
|
||||
<BR>
|
||||
Conversion from old to new ISDN capability flags:<BR>
|
||||
ISDNA -> V110L<BR>
|
||||
ISDNB -> V110H<BR>
|
||||
ISDNC -> X75<BR>
|
||||
<BR>
|
||||
H: INTERNET CAPABILITY FLAGS: <BR>
|
||||
<BR>
|
||||
FLAG MEANING<BR>
|
||||
<BR>
|
||||
IBN - denotes a system that does BINKP <BR>
|
||||
IFC - denotes a system that is capable of RAW or IFCICO <BR>
|
||||
ITN - denote a system that does TELNET <BR>
|
||||
IVM - denotes a system that is capable of VMODEM <BR>
|
||||
IFT - denotes a system that allows FTP <BR>
|
||||
ITX - denotes a system that uses TransX encoding for email<BR>
|
||||
tunneling<BR>
|
||||
IUC - denotes a system that uses UUEncode for email tunneling <BR>
|
||||
IMI - denotes a system which uses MIME encoding for email<BR>
|
||||
tunneling<BR>
|
||||
ISE - denotes a system which supports SEAT receipts for anonymous<BR>
|
||||
mail<BR>
|
||||
IP - denotes a system that can receive TCP/IP connects using a<BR>
|
||||
protocol that is not covered by any other flag. <BR>
|
||||
IEM - is a deprecated flag, and new implementations must not<BR>
|
||||
write it in nodelist entries. This was used as a single<BR>
|
||||
placeholder for the InterNet address of the system if it<BR>
|
||||
supported several transport methods. Instead of placing<BR>
|
||||
the system address in the deprecated form specified below<BR>
|
||||
in each flag, the address would be placed once only in this<BR>
|
||||
flag. Implementations may need to parse this information<BR>
|
||||
from nodelists created with older programs.<BR>
|
||||
<BR>
|
||||
Conversion from old Internet capabilty flags to the new flags:<BR>
|
||||
<BR>
|
||||
BND -> IBN<BR>
|
||||
TEL -> ITN<BR>
|
||||
TELNET -> ITN<BR>
|
||||
VMD -> IVM<BR>
|
||||
TCP -> IP<BR>
|
||||
<BR>
|
||||
The Internet Address should be placed in the BBS name field.<BR>
|
||||
<BR>
|
||||
Previous usage has placed the InterNet address as part of the<BR>
|
||||
I-flag (for example ITX:r10_tx@thevision.net); in this format the<BR>
|
||||
flag, colon, and address combined cannot exceed 32 characters.<BR>
|
||||
However, this practice is deprecated, and new implementations must<BR>
|
||||
not place address data in the flag section of the nodelist entry,<BR>
|
||||
implementations may however be required to read this data from the<BR>
|
||||
flag section.<BR>
|
||||
<BR>
|
||||
Telnet default port is 23. If the port is not 23 then the port<BR>
|
||||
number must be placed after the ITN flag (eg ITN:60177) if the<BR>
|
||||
Telnet address is part of the ITN flag (eg ITN:farsi.dynip.com) then<BR>
|
||||
the port number should be last (eg ITN:farsi.dynip.com:60177) always<BR>
|
||||
remember that the flag cannot exceed 32 characters total.<BR>
|
||||
<BR>
|
||||
The default ports for other protocols are shown below, and changes<BR>
|
||||
from the default port must be flagged in a similar way.<BR>
|
||||
<BR>
|
||||
Protocol Flag Default Port<BR>
|
||||
<BR>
|
||||
FTP IFT 21<BR>
|
||||
BINKP IBN 24554<BR>
|
||||
RAW/IFCICO IFC 60179<BR>
|
||||
VMODEM IVM 3141<BR>
|
||||
<BR>
|
||||
Actual IP addresses can also be placed in the phone number field<BR>
|
||||
using the country code of 000.<BR>
|
||||
<BR>
|
||||
I: SYSTEM ONLINE USERFLAGS<BR>
|
||||
<BR>
|
||||
The flag Tyz is used by non-CM nodes online not only during ZMH,<BR>
|
||||
y is a letter indicating the start and z a letter indicating the<BR>
|
||||
end of the online period as defined below (times in UTC):<BR>
|
||||
<BR>
|
||||
A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,<BR>
|
||||
D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,<BR>
|
||||
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,<BR>
|
||||
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,<BR>
|
||||
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,<BR>
|
||||
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,<BR>
|
||||
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,<BR>
|
||||
V 21:00, v 21:30, W 22:00, w 22:30, X 23:00, x 23:30.<BR>
|
||||
<BR>
|
||||
For example TuB shows an online period from 20:30 until 1:00 UTC.<BR>
|
||||
<BR>
|
||||
Daylight saving time<BR>
|
||||
<BR>
|
||||
If a node changes online times with respect to UTC when daylight<BR>
|
||||
saving time becomes effective (which would be the case with most<BR>
|
||||
part time nodes), then this is to be taken into account when<BR>
|
||||
assigning this flag. An online times flag assigned to a node should<BR>
|
||||
not be altered for the specific purpose of adjusting due to<BR>
|
||||
daylight saving time, since large difference files (NODEDIFF's)<BR>
|
||||
would result if every node was allowed to do this, e.g. my node<BR>
|
||||
used to be online from 2300 to 0800 in local time, which in winter<BR>
|
||||
is UTC, but in the summer it becomes BST (British Summer Time).<BR>
|
||||
This is one hour ahead of UTC, and the corresponding availability<BR>
|
||||
times of my node during the summer period were 2200 to 0700 UTC.<BR>
|
||||
Therefore my online times flag would have indicated availability<BR>
|
||||
between the hours of 2300 and 0700 UTC, the daily time period<BR>
|
||||
encompassing both times, so the flag would be TXH.<BR>
|
||||
<BR>
|
||||
2. Userflags<BR>
|
||||
------------<BR>
|
||||
<BR>
|
||||
Registry of Userflags<BR>
|
||||
<BR>
|
||||
A. FORMAT OF USER FLAGS<BR>
|
||||
<BR>
|
||||
U,x..x<BR>
|
||||
A user-specified string, which may contain any<BR>
|
||||
alphanumeric character except blanks. This string may<BR>
|
||||
contain one to thirty-two characters of information<BR>
|
||||
that may be used to add user-defined data to a specific<BR>
|
||||
nodelist entry. The character "U" must not be<BR>
|
||||
repeated, eg, ",U,XXX,YYY,ZZZ" not ",U,XXX,U,YYY,UZZZ".<BR>
|
||||
The 32 character limitation is per userflag, not for<BR>
|
||||
the total of all userflags.<BR>
|
||||
<BR>
|
||||
New implementations must place a comma after the<BR>
|
||||
initial "U" before the user flags. Some<BR>
|
||||
implementations will not place a separating comma<BR>
|
||||
betweent the "U" and the first user flag, but this<BR>
|
||||
practice is deprecated. Implementations should be<BR>
|
||||
prepared to read flags in this format, and must strip<BR>
|
||||
the "U" from the flag before analysis in this case.<BR>
|
||||
<BR>
|
||||
Entries following the "U" flag must be of a technical<BR>
|
||||
or administrative nature. While experimentation of new<BR>
|
||||
software functions using this flag is encouraged,<BR>
|
||||
advertisement is strictly prohibited.<BR>
|
||||
<BR>
|
||||
For applications other than those shown, or if you<BR>
|
||||
have questions concerning the use of this field, please<BR>
|
||||
contact your Regional or Zone Coordinator.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
B: MAIL ORIENTED USER FLAGS:<BR>
|
||||
<BR>
|
||||
ZEC Zone EchoMail Coordinator. Not more than one entry<BR>
|
||||
in the zone segment may carry this flag and that entry<BR>
|
||||
must be the current Zone EchoMail Coordinator.<BR>
|
||||
<BR>
|
||||
REC Regional EchoMail Coordinator. Not more than one<BR>
|
||||
entry in any region may carry this flag and that entry<BR>
|
||||
must be the current Regional EchoMail Coordinator.<BR>
|
||||
<BR>
|
||||
NEC Network EchoMail coordinator. Not more than one entry<BR>
|
||||
in any net may carry this flag and that entry must be<BR>
|
||||
the current Network EchoMail Coordinator of that Net.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
SDS Software Distribution System<BR>
|
||||
<BR>
|
||||
SMH Secure Mail Hub<BR>
|
||||
<BR>
|
||||
NC Network Coordinator. This flag is ONLY to be used by<BR>
|
||||
the Network Coordinator of a net which has split the<BR>
|
||||
duties of NC and Host and the NC does NOT occupy the<BR>
|
||||
Net/0 position in the nodelist.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
A. Contact Data<BR>
|
||||
---------------<BR>
|
||||
<BR>
|
||||
David Hallford <BR>
|
||||
Fidonet: 1:208/103<BR>
|
||||
<BR>
|
||||
Andreas Klein<BR>
|
||||
Fidonet: 2:2480/47<BR>
|
||||
E-mail: akx@gmx.net<BR>
|
||||
<BR>
|
||||
Michael McCabe<BR>
|
||||
Fidonet: 1:297/11<BR>
|
||||
<BR>
|
||||
Odinn Sorensen<BR>
|
||||
Fidonet: N/A<BR>
|
||||
E-mail: odinn@goldware.dk<BR>
|
||||
WWW: http://www.goldware.dk<BR>
|
||||
<BR>
|
||||
Colin Turner<BR>
|
||||
Fidonet: 2:443/13<BR>
|
||||
E-mail: ct@piglets.com<BR>
|
||||
WWW: http://www.piglets.com<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
B. History<BR>
|
||||
----------<BR>
|
||||
<BR>
|
||||
Rev.1, 19990627: Initial Release. Principal Author David Hallford<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
</TT>
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
Reference in New Issue
Block a user