N[x]        Login name [x] (ie. anonymous)
|   S[x]        Login password [x]
    PVT         Private
|   PUB[:/dir]  Public

| The N[x] and S[x] flags would be used similarly to the St. Louis
"LO" flag,
where only a person using the nodelist could gain entrance to the site due
to the password in use.  For security purposes, it is preferrable that
people using FTP transfers use unique and individual passwords and login
names.  The PVT flag would be used in such instances.  The PUB flag would be
used if the site allowed anonymous logins for drop-off's of mail.  In the
case of a PUB flag, the software making the FTP connection that is using the
nodelist should send a login name of "anonymous" with the user's email
address as the password.  Examples:

  [...],CF,stnnet.ml.org,PUB:/pub/ftn-in

| This implies anonymous logins for mail in the "/pub/ftn-in"
directory on the
| FTP site.  Note that the directory inclusion is only required in the public
| systems, as they are open for all incoming mail.  Private systems do not
| because anyone putting mail on the server would have a username and password
| thus the FTP software in question (or script) should also know which
| directory to place the incoming files as well as obtain outgoing files.

| [...],CF,stnnet.ml.org,Nstn,Stechnet,PVT

This would tell the sending client to login with login "stn" and password
"technet".  The PVT flag is used to show it will not accept anonymous
logins.

Regardless, for any type of FTP connection, the PUB or PVT flag must be
used.


Phone Capability Flags
----------------------

These flags should only be used for analog phone connections:

  CM    Crash system (24hrs)
  LO    Accepts mail from nodelisted systems only
  MO    Mail-only (no BBS)
  FAX   FAX capabilities available
  V32   ITU-T V32 full duplex
  V32b  ITU-T V32b full duplex
  V32T  ITU-T V32t full duplex
  V34   ITU-T V34 full duplex
  V34+  ITU-T V34+ full duplex
  V42   CCITT V.42 (LAP-M with MNP fallback)
  V42b  CCITT V.42bis (it is assumed MNP is also V42b)
  MNP   Microcom Networking Protocol (MNP 2-5)
  HST   USRobotics Courier HST Series
  VFC   V.Fast Class Std
  ZYX   ZyXEL modems

Many of these flags may imply another, depending upon modem type.  For
example, V34 may imnply V32b and V42b, V34+ may imply V32b, V42b, and V34,
etc.

The following flags are specific to ISDN systems:

  V110L ITU-T V.110 19k2 async ('low').
  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).
  MLP   Channel-Bundling with "Multiple Link Protocol" possible.  (ZyXEL
        Elite ISDN: S100=0 and &J1).  Please note: The MLProtocol has
        not been completely standardized yet.  Please use this flag
        only if you have a ZyXEL-TA (Elite ISDN/Omni-TA).
  CCB   Channel-Bundling with "cFos Channel Bundling" possible.  (ZyXEL
        Elite ISDN: S100=1 and &J1)

None of the above flags imply another.  Each capability must be specifically
listed.

The following flags are specific to X2 modem systems:

  X2C   USRobotics X2 client.  A modem having this capability can connect
        to an X2S-capable modem and potentially achieve 56 kbit/s
        throughput in the direction X2S to X2C and normal V.34-type
        througput in the opposite direction.
  X2S   USRobotics X2 server.  A device having this capability is
        mandatorily connected to the telephone network using a digital
        interface (probably ISDN) and can connect either to another X2S-
        capable device or to an X2C-capable device. In the former case,
        a symmetrical 64kbit/s link can be established. The latter case
        is the reverse of what is described under the X2C flag.

| The following flags indicate the v.90 protocol:

| V90C  v.90 client.  A modem having this capability can connect to an
|       V90S- or X2S-capable modem and potentially achive 56 kbit/s
|       throughput in the direction V90S to V90C and normal v.34-type
|       throughput in the opposite direction.  Fallback exists to the
|       X2 protocol when a v.90 client is connected to a v.90 or X2
|       server.  This fallback does not exist with K56Flex.
| V90S  v.90 server.  A device having this capability is mandatorily
|       connected to the telephone network using a digital interface
|       (probably ISDN) and can connect either to another X2S/v.90-
|       capable device or to an X2C/v.90-capable device. In the former
|       case, a symmetrical 64kbit/s link can be established. The latter
|       case is the reverse of what is described under the V90C flag.

Unlike the St. Louis format, there is no capability flag or field for
baudrate for specific modems.  The majority of modems now negotiate speed
and there is no need for a base dialling speed.  It is felt that a baudrate
field is unnecessary for a nodelist now.


Telnet Capability Flags
-----------------------

These flags should only be used for telnet connections:

| BND   Binkp (BinkD protocol)
  CM    Crash system (24hrs)
  MO    Mail-only (no BBS)
| TCP   RAW TCP/IP and Ifcico
  TEL   Telnet
  VMD   Proprietary Vmodem

| The TCP flag, when used by a system not using Ifcico, is strictly RAW
| TCP/IP.  When two Ifcico connections occur, the Ifcico proprietary
| protocol is used.  Ifcico can connect to a regular TCP using system
| not using Ifcico, however, as it will fallback to RAW TCP/IP.

Any combination of flags may be used.  For example, a system using BBBS
| would be able to receive via Binkp, RAW TCP/IP, and Telnet.  The might have
the following in their node entry:

  [...],CT,stnnet.ml.org,BND,CM,TCP,TEL

The CM and MO flags are similar to those used with analog phone connections.
If a system is not CM, look to the Txx flag (below) for dialin times.  It is
assumed that Zone Mail Hour is non-existant so mailers and other programs
should not assume non-CM systems are available during FidoNet's ZMH.
Instead they should look for the Txx flag to determine online times.

The default ports for the above capability flags are:

  BND   port 24554
  IFC   port 60179
  TCP   no default port
  TEL   port 23
  VMD   port 3141

In certain instances, the default ports cannot be used.  To specify a port
other than default simply append a ":[port#]" to the end of the capability
flag, like:

  [...],CT,stnnet.ml.org,BND,CM,TCP:21,TEL


Global Capability Flags
-----------------------

These capability flags are global for all connection types (except where
noted):

  GATE:[x]  Gate to zone [x] (used for gating between networks).
  H:[x]     Handshaking specification [x] (see below for explanation of
            [x]).
  T[xx]     Time system is online.  More than one T[xx] flag may be
|           used per node entry (see below for explanation of [xx]).  The
|           time must be calculated to UTC0 (ie. a system in the UTC-7
|           timezone would add 7 hours to their online time(s)).  This
            flag is not needed for email connections.
  UL[x]     Systems uplink node address.  All systems should have this flag
            for all entries, except for the primary (first) node address, or
            the originating (head) system of the network.
| U[,xx,xx] User flags.  These may be used for anything the network wishes,
            whether it be to denote software types, etc.  This flag must be
            last in the node entry.
  X[x]      Mailer type flags.  These flags are used to indicate the type of
            mailer on the receiving end.  They should only be used for phone
            and telnet connections.


Time Capability Flag
--------------------

The following chart illustrates the use of the T[xx] capability flag:

  +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
  |Letter|Time|  |Letter|Time|  |Letter|Time|  |Letter|Time|  |Letter|Time|
  +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
  |   A  |0000|  |   F  |0500|  |   K  |1000|  |   P  |1500|  |   U  |2000|
  |   a  |0030|  |   f  |0530|  |   k  |1030|  |   p  |1530|  |   u  |2030|
  |   B  |0100|  |   G  |0600|  |   L  |1100|  |   Q  |1600|  |   V  |2100|
  |   b  |0130|  |   g  |0630|  |   l  |1130|  |   q  |1630|  |   v  |2130|
  |   C  |0200|  |   H  |0700|  |   M  |1200|  |   R  |1700|  |   W  |2200|
  |   c  |0230|  |   h  |0730|  |   m  |1230|  |   r  |1730|  |   w  |2230|
  |   D  |0300|  |   I  |0800|  |   N  |1300|  |   S  |1800|  |   X  |2300|
  |   d  |0330|  |   i  |0830|  |   n  |1330|  |   s  |1830|  |   x  |2330|
  |   E  |0400|  |   J  |0900|  |   O  |1400|  |   T  |1900|  |      |    |
  |   e  |0430|  |   j  |0930|  |   o  |1430|  |   t  |1930|  |      |    |
  +------+----+  +------+----+  +------+----+  +------+----+  +------+----+


Mailer Type Flags
-----------------

The following is a list of valid mailer type flags and mailers that may use
them ("-" denotes versions less than specified, "+"
denotes specified
version to current):

  XA    Bark and WaZOO file/update requests.  Used by FrontDoor v1.99b-,
        FrontDoor v2.01+, Dutchie v2.90c, BinkleyTerm v2.1+, D'Bridge v1.2-,
        Trap Door, TIMS, InterMail v2.2x+, Portal of Power v0.60+.
  XB    Bark file/update requests, WaZOO file requests.  Used by BinkleyTerm
        v2.0, Dutchie v2.90b.
  XC    Bark file requests, WaZOO file/update requests.  Used by Opus v1.1+.
  XP    Bark file/update requests.  Used by Seadog.
  XR    Bark and WaZOO file requests.  Used by Opus 1.03c.
  XW    WaZOO file requests.  Used by Fido 12N+, Tabby, VFido, Platinum
        Xpress.
  XX    WaZoo file/update requests.  Used by D'Bridge 1.30+, FrontDoor
        v1.99c/v2.00, InterMail v2.01, T-Mail, McMail.


Handshaking Type Flags
----------------------

  1     FTS-0001
  B     BinkP
  E     EMSI
  Y     YooHoo

The default handshaking flag used in all instances is "1", or FTS-0001
handshaking.  Specifying handshaking types, however, eliminates the basic
need for being FTS-0001 compliant.  Since being FTS-0001 compliant now,
more than anything else, saves people from spending long distance money
on a connection that can't be established, EMSI-only mailers can operate
without the need to be restricted from networks because they do not
support FTS-0001.  If the H:E flag is found, the dialling software, should
it not support EMSI (highly unlikely) would know not to dial that system,
but host/hub route the netmail, or alert the operator should they attempt
to flag a message as direct/crash/immediate.  Alternately, this can also
be used to speed up handshaking attempts if it is known at the other end
what handshaking method to initiate with (ie. initiate with EMSI if the
other end offers the H:E flag).  Multiple flags may be specified by
| compounding the flag (ie. H:EB for EMSI/BinkP handshaking support).  The
| H:[x] flag is not required for mailers that use FTS-0001 handshaking, but
| may be included, if other flags are supported (ie. H:1B).


| Example
| -------

| An example nodelist segment might look as follows (" ..." signifies a
| line wrap):

| 111:111/0{at}stn,STN International Host,Edmonton AB,Vincent Danen,CP,
|  ... 1-403-456-5699,CM,V32b,V42b,VFC,V34,XX,U,BB
| .,STN International Host Telnet,.,.,CT,sh2.detour.net,BND,TCP,TEL,XX,
|  ... ,H:1B,TNS,TCH
| .,STN International Host Email,.,.,CE,stn-irex{at}usa.net,IR,TX
| 2.0,STN Internet Gateway Host,Edmonton AB,UUCP,CP,1-403-456-5699,CM,V32b,
|  ... V42b,VFC,V34,XX,UL111:111/0,U,BB

--- WaterGate/2+ v0.94.PRE12