********************************************************************** FTSC FIDONET TECHNICAL STANDARDS COMMITTEE ********************************************************************** Publication: FTS-5000 Revision: 1 Title: THE DISTRIBUTION NODELIST Author(s): Colin Turner, Andreas Klein, Michael McCabe, David Hallford, Odinn Sorensen Revision Date: 27 June 1999 Expiry Date: 17 June 2001 ---------------------------------------------------------------------- Contents: 1. Supercessions 2. Purpose 3. Publication and Distribution 4. Contents 5. Nodediff ---------------------------------------------------------------------- Status of this document ----------------------- This document is a Fidonet Standard (FTS). This document specifies a Fidonet standard for the Fidonet community. This document is released to the public domain, and may be used, copied or modified for any purpose whatever. Abstract -------- Current practice for Fidonet Technology Networks (FTN) is to maintain a nodelist used to store the details of the nodes in the network, and the network structure. 1. Supercessions ---------------- FTS-0005 superceded and replaced the documents known under the names of FSC-0002, and FTS-0002. This document supercedes and replaces FTS-0005, FSC-0009, FSC-0040, FSC-0075, FSC-0091, and FSP-1012. 2. Purpose ---------- Along with the companion technical standard (FTS-5001) this document defines the format and content of the nodelist for the FidoNet International Hobby Network. The FTS-5001 is seperated into two parts - the first part is a listing of authorized flags and the second part is a registry of userflags. The registry is used to prevent a userflag from being used for more than one meaning. The registry is maintained by the Fidonet Technical Standards Committee Working Group D (the Nodelist). 3. Publication and Distribution ------------------------------- The nodelist is published as an ASCII text file named NODELIST.nnn, where nnn is the day-of-year of the publication date. For actual distribution, NODELIST.nnn is packed into an archive file named NODELIST.Pnn, where nn are the last two digits of day-of -year and P is the compression format used as listed below. A = .arc Z = .zip J = .arj R = .rar Since .zip is useable on most computer platforms, it is recommended that this format be used for distribution of the Distribution Nodelist. 4. Contents ----------- As stated above, NODELIST.nnn is an ASCII text file. It contains two kinds of lines, comment lines and data lines. Each line is terminated with an ASCII carriage return and line feed character sequence, and contains no trailing white-space (spaces, tabs, etc.). The file is terminated with an end-of-file character, ASCII (1AH). Comments lines contain a semicolon (;) in the first character position followed by zero or more alphabetic characters called "interest flags". A program which processes the nodelist may use comment interest flags to determine the disposition of a comment line. The remainder of a comment line (with one exception, treated below) is free-form ASCII text. There are five interest flags defined as follows: ;S This comment is of particular interest to Sysops. ;U This comment is of particular interest to BBS users. ;F This comment should appear in any formatted "Fido List". ;A This comment is of general interest (shorthand for ;SUF). ;E This comment is an error message inserted by a nodelist generating program. ; This comment may be ignored by a nodelist processor. The first line of a nodelist is a special comment line containing identification data for the particular edition of the nodelist. The following is an example of the first line of a nodelist: ;A FidoNet Nodelist for Friday, July 3, 1987 -- Day number 184 : 15943 This line contains the general interest flag, the day, date, and day-of-year number of publication, and ends with a 5-digit decimal number with leading zeros, if necessary. This number is the decimal representation of a check value derived as follows: Beginning with the first character of the second line, a 16-bit cyclic redundancy check (CRC) is calculated for the entire file, including carriage return and line feed characters, but not including the terminating EOF 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 may be used to verify that the file has not been edited. The importance of this will become evident in the discussion of NODEDIFF below. CRC calculation techniques are well documented in the literature, and will not be treated further here. The content of the remaining comments in the nodelist are intended to be informative. Beyond the use of interest flags for distribution , a processing program need not have any interest in them. A nodelist data line contains eight variable length "fields" separated by commas (,). No space characters are allowed in a data line, and underscore characters are used in lieu of spaces. The term "alphanumeric character" is defined as the portion of the ASCII character set from 20 hex through 7E hex, inclusive. The following discussion defines the contents of each field in a data line. Field 1: Keyword The keyword field may be empty, or may contain exactly one keyword approved by the Zone Coordinator Council. Current approved keywords are: Zone -- Begins the definition of a geographic zone and define its coordinator. All the data lines following a line with the "Zone" keyword down to, but not including, the next occurrence of a "Zone" keyword, are regions, nets, and nodes within the defined zone. Region -- Begins the definition of a geographic region and defines its coordinator. All the data lines following a line with the "Region" keyword down to, but not including, the next occurrence of a "Zone", "Region", or "Host" keyword, are independent nodes within the defined region. Host -- Begins the definition of a local network and defines its host. All the data lines following a line with the Host keyword down to, but not including, the next occurrence of a "Zone", "Region", or "Host" keyword, are local nodes, members of the defined local network. Hub -- Begins the definition of a routing subunit within a multilevel local network. The hub is the routing focal point for nodes listed below it until the next occurrence of a "Zone", "Region", "Host", or "Hub" keyword. The hub entry MUST be a redundant entry, with a unique number, for one of the nodes listed below it. This is necessary because some nodelist processors eliminate these entries in all but the local network. Pvt -- Defines a private node with unlisted number. Private nodes are only allowed as members of local networks. Hold -- Defines a node which is temporarily down,or is a region/zone independent node which is reachable via IP only. Mail may be sent to it and is held by its host or coordinator. Down -- Defines a node which is not operational. Mail may NOT be sent to it. This keyword may not be used for longer than two weeks on any single node, at which point the "down" node is to be removed from the nodelist. -- Defines a normal node entry. Field 2 - Zone/Region/Net/Node number This field contains only numeric digits and is a number in the range of 1 to 32767. If the line had the "Zone", "Region", or "Host" keyword, the number is the zone, net, or region number, and the node has an implied node number of 0, therfore the use of a 0 in this field is strictly forbidden. Otherwise, the number is the node number. The zone number, region or net number, and the node number, taken together, constitute a node's FidoNet address. Zone numbers must be unique. Region or net numbers must be unique within their zone. Hub numbers must be within their net. Node numbers must be unique within their region (for regional independents) or net (for members of a local network). Duplicate node numbers under different hubs within the same net are not allowed. Field 3 - Node name This field may contain any alphanumeric characters other than commas and spaces. Underscores are used to represent spaces. This is the name by which the node is known. For IP nodes this field may alternately contain an ip address or E-Mail address for email tunneling programs. Field 4 - Location This field may contain any alphanumeric characters other than commas and spaces. Underscores are used to represent spaces. This field contains the location of the node. It is usually expressed as the primary local location (town, suburb, city, etc.) plus the identifier of the regional geopolitical admin- istrative district (state, province, department, county, etc.). Wherever possible, standard postal abbreviations for the major regional district should be used (IL, BC, NSW, etc.). Field 5 - Sysop name This field may contain any alphanumeric characters other than commas and spaces. Underscores are used to represent spaces. This is the name of the system operator. Field 6 - Phone number This field contains at least three and usually four numeric subfields separated by dashes (-). The fields are country code, city or area code, exchange code, and number. The various parts of the phone number are frequently used to derive cost and routing information, as well as what number is to be dialed. A typical example of the data in a phone number field is 1-800- 555-1212, corresponding to country 1 (USA), area 800 (inbound WATS), exchange 555, and number 1212. Alternatively, this field may contain the notation -Unpublished- in the case of a private node. In this case, the keyword "Pvt" must appear on the line. This field may also contain the IP address for an IP node utilizing the country code of 000. Field 7 - Baud rate This field contains the maximum baud rate supported by the node. (eg: 9600, 14400, 38400, etc) Field 8 - Flags This optional field contains data about the specific operation of the node, such as file requests, modem protocol supported, etc. Any text following the seventh comma on a data line is taken collectively to be the flags field. The required format is zero or more subfields, separated by commas. Each subfield consists of a flag, possibly followed by a value. The authorized flags for use in the distribution nodelist are distributed as in FTS-5001 to facilitate additions and deletions of the authorized flags without requiring an amendment to this FTS. FTSC recognizes that the FidoNet Zone Coordinator Council with the International Coordinator as the ZCC Chairman is the ultimate authority over what appears in the FidoNet nodelist. Also, FTSC is by definition a deliberative body, and adding or changing a flag may take a considerable amount of time. Therefore, the FidoNet International Coordinator or Zone Coordinators may temporarily make changes or additions to the flags as defined in FTS-5001. The FidoNet International Coordinator/Zone Coordinators will then consult with FTSC over the changes needed to FTS-5001 to reflect these temporary changes. The following are examples of nodelist data lines: Host,102,SOCALNET,Los_Angeles_CA,Richard_Mart,1-213-874-9484,2400,XP ,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400, ,102,fido.tree.com,Los_Angeles_CA,Bill_Smart,1-213-555-1212,9600, CM,IP,ITN 5. Nodediff ----------- With more than twenty thousand nodes as of this date, the nodelist, even in archive form, is a substantial document (or file). Since distribution is via electronic file transfer, this file is NOT routinely distributed. Instead, when a new nodelist is prepared, it is compared with the previous week's nodelist, and a file containing only the differences is created and distributed. The distribution file, called NODEDIFF.nnn, where nnn is the day-of-year of publication, is actually an editing script which will transform the previous week's nodelist into the current nodelist. A definition of its format follows: The first line of NODEDIFF.nnn is an exact copy of the first line of LAST WEEK'S nodelist. This is used as a first-level confidence check to insure that the right file is being edited. The second and sub- sequent lines are editing commands and editing data. There are three editing commands and all have the same format: is a 1-letter command; A, C, or D. is a decimal number greater than zero, and defines the number of lines to be operated on by the command. Each command appears on a line by itself. The commands have the following meanings: Ann - Add the following nn lines to the output file. Cnn - Copy nn unchanged lines from the input to the output file. Dnn - Delete nn lines from the input file. The following illustrate how the first few lines of NODEDIFF.213 might look: ;A Friday, July 25, 1986 -- Day number 206 : 27712 D2 A2 ;A Friday, August 1, 1986 -- Day number 213 : 05060 ;A C5 This fragment illustrates all three editing commands. The first line is the first line from NODELIST.206. The next line says "delete the first two lines" from NODELIST.206. These are the identification line and the line following it. The next command says "add the next two lines" to NODELIST.213. The two data lines are followed by a command which says "copy five unchanged lines" from NODELIST.206 to NODELIST .213. Notice that the first line added will ALWAYS contain the new nodelist's CRC. Since only the differences will be distributed, it is important to insure the accuracy of the newly created nodelist. This is the function of the CRC mentioned above. It is sufficient for a program designed to perform the above edits to pick the CRC value from the first line added to the output file, then compute the CRC of the rest of the output file. If the two CRCs do not agree, one of the input files has been corrupted. If they do agree, the probability is very high (but not 100%) that the output file is accurate. For actual distribution, NODEDIFF.nnn is packed into an archive file named NODEDIFF.Pnn, where nn are the last two digits of day-of-year and P is the compression format used as listed below. A = .arc Z = .zip J = .arj R = .rar Since .zip is useable on most computer platforms, it is recommended that this format be used for distribution of the Distribution Nodediff. A. References ------------- [FTS-5] "The distribution nodelist", Ben Baker, Rick Moore. February 1989. Obsoleted by this document. [FSC-9] "Nodelist flag Changes draft document", Ray Gwinn, David Dodell. November 1987. Obsoleted by this document. [FSC-40] "Extended Modem Handling", Michael Shiels. February 1990. Obsoleted by this document. [FSC-75] "ISDN capability flags in the nodelist", Jan Ceuleers. October 1993. Obsoleted by this document. [FSC-91] "ISDN nodelist flags", Arjen Lentz. October 1995. Obsoleted by this document. [FSP-1012] "Integration of IP Nodes in the nodelist", Lothar Behet June 1999. B. Contact Data --------------- David Hallford Fidonet: 1:208/103 Andreas Klein Fidonet: 2:2480/47 E-mail: akx@gmx.net Michael McCabe Fidonet: 1:297/11 Odinn Sorensen Fidonet: N/A E-mail: odinn@goldware.dk WWW: http://www.goldware.dk Colin Turner Fidonet: 2:443/13 E-mail: ct@piglets.com WWW: http://www.piglets.com C. History ---------- Rev.1, 19990627: Initial Release. Principal Author David Hallford