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