404 lines
37 KiB
HTML
404 lines
37 KiB
HTML
<HTML>
|
|
<!-- $Id$ -->
|
|
<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">Go Back</A>
|
|
|
|
</BODY>
|
|
</HTML>
|