* Crossposted in NET_DEV
* Crossposted in FTSC_PUBLIC

The new N2000 nodelist specification.  For more information, visit
http://stnnet.ml.org/stnwg.htm.  Comments are welcome, flames are not. 
This is not, nor will it become, an FSP.

=== Cut ===
N2000 - FTN Nodelist Format
A Proposed Standard For The BBS Community
A Sysop's TechNet WorkGroup Document
Copyright (c) 1998 Vincent Danen; all rights reserved.

Revision:       2000.002
First Draft:    March 19, 1998
Current Draft:  May 21, 1998
Contributors:   Vincent Danen           vdanen{at}stnnet.ml.org
                Brent Shellenberg       brents{at}shaw.wave.ca

The Purpose
-----------
The old St. Louis format nodelist is sadly outdated.  With the way technology
has advanced in the last few years, especially with internet integration, it
has become necessary to define an entirely new nodelist format that can
support all of these new advances without attempting to kludge together
solutions that exist within the confines of the St. Louis format and current
nodelist compilers.  N2000 is a format that closely resembles the St. Louis
format to make transition and integration easier for all developers and users,
but enhances the capabilities and uses of the nodelist in any given FTN
network.


N2000 Format
------------
Although the layout for the N2000 format is very similar to the existing St.
Louis format, some fields should be explained again and differences between
the previous format to the N2000 format should be noted.

The naming convention for the N2000 format nodelist is the same as the St.
Louis format.  It follows the DOS 8.3 standard filename format where the file
name is NODELIST.nnn where nnn is the julian day of the year (padded with
zeros (ie. julian day 3 would be 003, julian day 26 would be 026, etc.) that
the nodelist was published.  NODELIST may be any unique name significant to
the FTN network who's nodelist is being utilized (ie. STNLIST for Sysop's
TechNet). The nodelist may also be archived with the name specification being
NODELIST.xnn where nn is the last two numbers of a three digit julian day and
x is a character denoting the archiving format being used (ie. r for RAR, z
for ZIP, a for ARC, J for ARJ, l for LHA).

The nodelist itself is a plain ASCII format list.  Each line in the file must
terminate with a  pair, and the file must end with a
DOS end-of-file
 character (decimal 26 or Ctrl-Z).  There should be no extraneous
trailing white spaces at the end of any lines (ie. extra spaces, tabs, etc.).

The nodelist itself will contain three types of lines.  An identification
line (used once in the nodelist), comment lines, and data lines.  The
identification line identifies the nodelist as being an N2000 format nodelist
as opposed to the traditional St. Louis format since there are no
distinguishing characteristics based on file name.  The identification line
is a single line like thus:

        ::N2000 Format Nodelist

Case is not important on this line, and this line must be the first line in
the nodelist.  Subsequent lines may be comment or data lines.  Comment lines
begin with the ; character.  There are a few different comment lines that can
be used.

        ;A      this indicates a comment of general interest
        ;E      this indicates an error in the nodelist inserted by the
                nodelist generator
        ;       this indicates a general comment that should be ignored by
                the nodelist processor

The second line of an N2000 format nodelist is also an identification string,
similar to that of the St. Louis format.  The following is an example of the
second line of a nodelist:

        ;A Nodelist for Friday, February 27, 1998 -- Day number 058 : 15394

This line contains the general interest flag, the day of week, the date, the
julian day of year, a colon, and then a five digit decimal CRC number padded
with zeros if necessary.  The CRC value is the same as that used in St. Louis
format nodelists, and is derived as follows:

Beginning with the first character of the third line, a 16 bit cyclic
redundancy check (CRC) is calculated for the entire file, including  and
 characters, but not including the terminating  character.  The
check polynomial used is the same one used for many file transfer protocols:

        2**16 + 2**12 + 2**5 + 2**0

The CRC value in the nodelist is used to verify that the nodelist has not
been edited or damaged in any way from when it was originally generated.  CRC
calculation techniques are well documented in various technical references
and will not be further detailed here.

The other comment lines in the nodelist are simply informative to anyone
viewing the nodelist and may be ignored completely by nodelist processors.
Other than the following data lines in the nodelist, only the first two lines
of the nodelist need be of interest to a nodelist processing program.

The nodelist data lines contain the information pertinent to the systems
listed in the nodelist.  The lengths of these data lines are variable,
| depending upon the capabilities of the systems listed there.  ASCII text is
| all that is permitted on the data line, those characters from hex 20
| through to hex 7E inclusive.

The following outlines the data lines of the N2000 nodelist format.  The
first eight(?) fields are mandatory, the remaining fields should be included
depending upon the capabilities of individual systems.


The Node Entry
--------------

The node entry can be a single line, or a series of lines, that provide
information on the capabilities of the node in question.  The nodelist is
structured with a basic hierarchy in mind, and the node addressing flows
downward.


Node Addressing
---------------

The first node entry in the nodelist must be of the format:

[zone]:[net]/[node].[point]{at}[domain],...

This provides the nodelist compiler with the information it requires for
subsequent addresses.  This is the "root" address of the nodelist.  Many
assumptions are made from this first address.  For example:

  111:111/0.0{at}stn,[...]

This tells the nodelist compiler that zone 111 is to be used until another
zone is encountered, net 111 is to be used until another net is encountered,
the node for this entry is 0, and the point is 0.  It also defines the
domain name for the entire network (only one domain should be used for the
entire network), as "stn".  This provides for full 5D node addressing.  The
domain is assumed for the rest of the nodelist.

The second nodelist entry would have the following data line, provided it is
in the same net:

  5.0,[...]

The nodelist compiler must assume this address to be 111:111/5.0{at}stn, using
the information found previously.  If the next data line were to be for a
node in another net, yet the same zone, it might look like:

  1403/0.0,[...]

Again, the nodelist compiler must assume the zone and domain information
from previous node entries.  If, for example, a new zone segment was
beginning, the entry might look like:

  112:112/0.0,[...]

Now subsequent nodes will be assigned the zone 112, but the domain will
remain the same as "stn".


Nodelist Information
--------------------

The nodelist data line must follow this format:

  [address],[site name],[site location],[sysop name],
    [connect flag],[connection],[capability flags]

The text in the data line must follow the above format.  Many systems will
have more than solely a telephone number as a means of connection, so
continuous data lines must look like:

  .,.,.,.,[connect flag],[connection],[capability flags]

The same number of commas must be present even on continuation lines.
Instead of the node address field, a period must be present to tell the
compiler it is the same information as the previous entry.  If all fields
are filled with the period, then all information is assumed the same
(address, sysop name, location, etc.).  This can be used to also specify
different names for different connection methods, yet still be the same
system, for example:

  111:111/0{at}stn,Stronghold Enterprises/2,Edmonton AB,Vincent Danen,[...]
  .,Stronghold Enterprises/2 Email,.,.,[...]
  .,Stronghold Enterprises/2 Telnet,.,.,[...]

This gives the same system three means of connection, each with a unique
system name.  You may more than one connection type for your entry, however.
This also comes in handy to reduce the number of AKA's a multiline system
may have.  A system could have three phone lines listed, matched to the
same AKA, or two email connections with different capabilities, etc.

Unlike the St. Louis format, N2000 does not require spaces to be replaced
with an underscore "_".  Spaces may be freely used within the nodelist.


Site Name
---------

This is the name of the BBS or point system.


Site Location
-------------

The geographic location of the system (ie. Edmonton, AB).


Sysop Name
----------

This is the name of individual running the system, whether it be the point
operator or the primary sysop.


Connect Flag
------------

This flag tells the nodelist compiler what the following connection method
is.  The following flags may be used:

  CE    Email
  CF    FTP
  CP    Telephone line
  CT    Telnet, TCP/IP, Binkp


Connection
----------

The actual connection for the system.  This is dependent upon the connect
flag directly in front of it.  The type of connect flag must correspond with
the method (connect flag CE, connection would be an email address, etc.).
Examples:

  CE,stn-irex{at}usa.net,
  CF,stnnet.ml.org,
  CP,1-403-456-5699,
  CT,stnnet.ml.org,

For ftp sites and telnet sites, you may use either the IP address or the DNS
name for your site.  The email address should be the address your internet
transport client uses to send/receive mail, and the phone entry must be the
full international format of your system's analog phone number.


Capability Flags
----------------

Capability Flags are highly dependant upon the information prior.  Obviously
flags specifying modem capability are next to useless for an entry with an
email address.  This must be kept in mind while the nodelist is being
processed.


Email Capability Flags
----------------------

The following flags should be used for email connections only:

Encoding method:

  BHX   BinHex encoding/decoding (Macintosh systems)
  MIM   MIME/Base64 encoding/decoding
  UUE   UUEncoding/decoding
  XXE   XXEncoding/decoding

Document formating method:

  AFX   AllFix 5.00+ encoding/decoding
  IR    Internet Rex (implies AFX, MIM, UUE, and up to SEAT4)
  SEATx SEAT level x (1-4) encoding/decoding
  TX    TransX encoding/decoding

A combination of both sets of flags may be used, depending on the software
involved.  For example, a system merely using WaterGate could use the MIM,
UUE, and XXE flags.  Or a system using AllFix only for uuencoding (not the
proprietary formatting) could use UUE and AFX, or simply UUE.

Regardless of the system's sending/receiving capabilities (ie. UUCP,
POP3/SMTP, etc.) these are the only flags that can be used.  A system using,
for example, WaterGate and TransX might use the following:

  [...],CE,stn-irex{at}usa.net,UUE,MIM,TX

whereas a system only using Soup2PKT would use:

  [...],CE,stn-irex{at}usa.net,MIM,UUE

These capability flags are used for receiving types, not necessarily sending
types.  For example, a system using WaterGate's mailtunnel can only send via
UUEncoding, but can receive UUEncoding, MIME/Base64, and XXEncoding.
Although this system would use the flags "UUE,MIM,XXE" it does
not mean that
is can send these formats, only that it is capable of receiving them.


FTP Capability Flags
--------------------

The following flags should be used for FTP connections only:

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