=================================================================
FTSC INFORMATION =================================================================
Publication: FTS-5001
Revision: 4
Title: Nodelist flags and userflags
Author(s): FTSC Members, Administrator and Honoured Guests
Issue Date: 10 March 2013
======================================================================
Status of this document
-----------------------
This document is a Fidonet Technical Standard (FTS) - it specifies
the current technical requirements and recommendations for FTN
software developers, coordinators and sysops of the Fidonet network
and other networks using FTN technology.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
Nodelist flags extend the basic nodelist format described in
FTS-5000, allowing a node to provide detailed information of its
operation and capabilities.
Contents
--------
1. Introduction
2. Supersessions
3. Purpose
4. Syntax
5. Normal flags
5.1 Operating Condition Flags
5.2 Modem Connection Protocol Flags
5.3 Session Level Error-correction and Compression Flags
5.4 File/Update Request Flags
5.5 Gateway Flag
5.6 Mail Period Flags
5.7 System Online Flags
5.8 ISDN Capability Flags
5.9 Internet Capabilities
5.10 Robot flags
5.11 Flag Redundancies
6. User Flags
6.1 Format Of User Flags
6.2 Mail Oriented User Flags
A. References
B. History
======================================================================
1. Introduction
---------------
The Fidonet Distribution Nodelist (FTS-5000) is a comma-delimited
database, i.e. each node's entry is made up of fields, each of which
has a specific purpose.
While this is a fine system for holding information that all nodes
must have (e.g. node number, sysop name, etc.) it is not well suited
for data that varies wildly from system to system. To accommodate
such data, the flag fields are defined as self-describing and
non-position dependent fields.
This document is a registry of all commonly used flags in Fidonet,
and companion to FTS-5000 in describing the Distribution Nodelist.
2. Supersessions
----------------
This document supersedes and replaces FTS-0005, FSC-0009, FSC-0040,
FSC-0062, FSC-0075 and FSC-0091.
3. Purpose
----------
As with FTS-5000, this document is intended for both developers and
nodelist maintainers to avoid duplication and conflicts. Normal
sysops would also do well to have at least cursory knowledge of the
nodelist's capabilities so they may provide their Coordinators with
all the pertinent detail of their systems.
This document should be considered a guide, and not the final word
on what are and aren't valid flags. There will obviously be an
unavoidable lag between the introduction of new flags and their
inclusion in this document, as well as experimental flags that will
come and go with no official documentation at all.
4. Syntax
---------
Most flags are simple tokens that each occupy a single field and by
their presence or absence in the nodelist, indicate the presence or
absence of a certain feature in the node.
A more recent style is to subdivide the flag field, usually with a
colon (3Ah) to allow for variable data under a common flag. These
are essentially named fields, consisting of the flag itself and its
payload as one or more subfields.
Unless otherwise stated, flags are not position or order dependent,
with the exception that User Flags must follow Normal Flags.
5. Normal flags
---------------
5.1. Operating Condition Flags
------------------------------
Flag Meaning
CM Node accepts mail 24 hours a day using all listed methods
ICM Node accepts mail 24 hours a day using all listed TCP/IP
methods, but not all of the other listed methods (such as
PSTN/ISDN) and therefore cannot be CM. See FRL-1017.
MO Node does not accept human callers
LO Node accepts calls Only from Listed FidoNet addresses
MN Compressed mail packets will not be processed automatically
5.2. Modem Connection Protocol Flags
------------------------------------
The following flags define modem connection protocols supported.
Please also read section 5.11 on flag redundancies.
ITU-T (formerly CCITT) Protocols:
Flag Meaning
V22 ITU-T V.22 1.200 bps full duplex
V29 ITU-T V.29 9.600 bps half duplex
V32 ITU-T V.32 9.600 bps full duplex
V32b ITU-T V.32bis 14.400 bps full duplex
V34 ITU-T V.34 33.600 bps full duplex *
V90C ITU-T V.90 Client 56.000 bps asymmetric
V90S ITU-T V.90 Server 56.000 bps asymmetric
Industry standard protocols:
Flag Meaning
V32T V.32 Terbo 21.600 bps full duplex *
VFC V.Fast Class 28.800 bps full duplex
Proprietary Protocols:
Flag Meaning
HST USR Courier HST 9.600 bps asymmetric
H14 USR Courier HST 14.400 bps asymmetric
H16 USR Courier HST 16.800 bps asymmetric
X2C US Robotics x2 client 56.000 bps asymmetric
X2S US Robotics x2 server 56.000 bps asymmetric
ZYX Zyxel 16.800 bps
Z19 Zyxel 19,200 bps
H96 Hayes V9600 9.600 bps
PEP Packet Ensemble Protocol
CSP Compucom Speedmodem
* NOTE: maximum possible speed; actual maximum will vary
depending on implementation.
5.3. Session Level Error-correction and Compression Flags ---------------------------------------------------------
The following flags define type of error correction and/or data
compression available. A separate error correction flag should not
be used when the error correction type can be determined by the
modem flag. See section I for details.
Flag Meaning
MNP Microcom Networking Protocol error correction
of type MNP1 to MNP4
V42 ITU-T V.42: LAP-M error correction with fallback
to MNP 1-4
V42b ITU-T V.42bis: LAP-M error correction and
compression with fallback to MNP 1-5
5.4. File/Update Request Flags
------------------------------
The following table shows the flags indicating various types of
file/update requests supported:
+--------------------------------------------------+
| | Bark | WaZOO |
| |---------------------|---------------------|
| | File | Update | File | Update |
| Flag | Requests | Requests | Requests | Requests |
|------|----------|----------|----------|----------|
| XA | Yes | Yes | Yes | Yes |
| XB | Yes | Yes | Yes | No |
| XC | Yes | No | Yes | Yes |
| XP | Yes | Yes | No | No |
| XR | Yes | No | Yes | No |
| XW | No | No | Yes | No |
| XX | No | No | Yes | Yes |
| none | No | No | No | No |
+--------------------------------------------------+
The following software is qualified to use the appropriate file
request flag according to information provided by developers:
+-----------------------------------+
| Flag Software Package |
|-----------------------------------|
| XA Frontdoor 1.99b and lower |
| Frontdoor 2.01 and higher |
| Dutchie 2.90c |
| Binkleyterm 2.1 and higher |
| D'Bridge 1.2 and lower |
| Melmail |
| TIMS |
| ifcico |
| mbcico 0.60.0 and higher|
| (via modem) |
|-----------------------------------|
| XB Binkleyterm 2.0 |
| Dutchie 2.90b |
|-----------------------------------|
| XC Opus 1.1 |
|-----------------------------------|
| XP Seadog |
|-----------------------------------|
| XR Opus 1.03 |
| Platinum Xpress |
|-----------------------------------|
| XW Fido 12N and higher |
| Tabby |
| TrapDoor No update processor|
| binkd w/SRIF FREQ processor |
|-----------------------------------|
| XX Argus 2.00 and higher |
| D'Bridge 1.30 and higher |
| Frontdoor 1.99c/2.00 |
| InterMail 2.01 |
| McMail 1.00 |
| T-Mail |
| TrapDoor - Update Processor |
| mbcico 0.60.0 and higher|
| (via IP) |
|-----------------------------------|
| None QMM |
+-----------------------------------+
5.5. Gateway Flag
-----------------
The following flag defines gateways to other domains (networks).
Flag Meaning
Gx..x Gateway to domain 'x..x', where 'x..x` is a string
of alphanumeric characters. Valid values for
'x..x' are assigned by the FidoNet International
Coordinator or the Zone Coordinators Council. They
will also adequately distribute a list of valid
values.
5.6. Mail Period Flags
----------------------
The Mail Period Flags indicate compliance with another zone's ZMH.
Since ZMH is mandatory within one's own zone, it is not indicated.
These flags have the form "#nn" or !nn where nn is the UTC hour the
mail period begins, # indicates Bell 212A compatibility, and !
indicates incompatibility with Bell 212A. For example:
Flag Meaning
#02 Zone 2 mail hour (02:30 - 03:30 UTC)
#08 Zone 4 mail hour (08:00 - 09:00 UTC)
#09 Zone 1 mail hour (09:00 - 10:00 UTC)
#17 Zone 3 mail hour (17:00 - 18:00 UTC)
The above listing of the ZMH for each individual zone is only given
for your convenience. It was correct at the time of this writing,
but could be changed at any time by following the procedures
established in Fidonet policy. The FTSC has no role in determining
the Mail Hour of any Zone. You'll find an up-to-date list in the
comments at the end of the Fidonet Nodelist.
NOTE: When applicable, the mail period flags may be strung together
with no intervening commas, e.g. "#02#09".
5.7. System Online Flags
------------------------
The flag Tyz is used by non-CM nodes online not only during ZMH, y
is a letter indicating the start and z a letter indicating the end
of the online period as defined below (times in UTC):
A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,
D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,
V 21:00, v 21:30, W 22:00, w 22:30, X 23:00, x 23:30.
For example TuB shows an online period from 20:30 until 1:00 UTC.
Daylight saving time
--------------------
If a node changes online times with respect to UTC when daylight
saving time becomes effective (which would be the case with most
part time nodes), then this is to be taken into account when
assigning this flag. An online times flag assigned to a node should
not be altered for the specific purpose of adjusting due to daylight
saving time, since large difference files (NODEDIFF's) would result
if every node was allowed to do this, e.g. a node used to be online
from 2300 to 0800 in local time, which in winter is UTC, but in the
summer it becomes BST (British Summer Time). This is one hour ahead
of UTC, and the corresponding availability times of a node during
the summer period were 2200 to 0700 UTC. Therefore its online times
flag would have indicated availability between the hours of 2300 and
0700 UTC, the daily time period encompassing both times, so the flag
would be TXH.
5.8. ISDN Capability Flags
--------------------------
Nodelist Specification of minimal support required for this flag;
flag any additional support to be arranged via agreement
between users
V110L ITU-T V.110 19k2 async ('low').
NOTE: some implementations are limited to 9600bps.
V110H ITU-T V.110 38k4 async ('high').
V120L ITU-T V.120 56k async, layer 2 framesize 259, window 7,
modulo 8.
V120H ITU-T V.120 64k async, layer 2 framesize 259, window 7,
modulo 8.
X75 ITU-T X.75 SLP (single link procedure) with 64kbit/s B
channel; layer 2 max. framesize 2048, window 2, non-ext.
mode (modulo 8); layer 3 transparent (no packet layer).
ISDN Other configurations. Use only if none of the above
fits.
NOTE: No flag implies another. Each capability MUST be specifically
listed.
5.9. Internet Capabilities
--------------------------
Basic Syntax
------------
Internet capability flags use the format:
<flag>[:<internet address>][:<port>]
Where <internet address> is:
* a fully qualified domain name (FQDN), or
* an IPv6 address encased in square brackets, or
* an IPv4 address in dotted-quad format, or
* an email address,
depending on the protocol, and <port> is the service port number.
<internet address> may be omitted if the address is available in
another field (see below). <port> should be omitted if it is the
default port for that particular service, and is not permitted for
email addresses.
The mailer software is expected to be able to determine whether
<internet address> is an IPv4 quad, an IPv6 encased address, a
host name or email address by itself.
Advanced usage
--------------
Several methods of listing Internet capability flags are widely
used and subject to change at any time. Internet capable software
should provide a suitable manual override mechanism to compensate
for the volatility of the nodelist format, and be able to deal with
prolonged connection failures (e.g. by automatically putting waiting
mail on hold, and notifying the local sysop).
Shorthand flags
---------------
For brevity, a node that lists multiple Internet capability flags
that require the same address may list the address only once, and
--- Azure/NewsPrep 3.0
* Origin: Home of the Fidonews (2:2/2.0)