Subj : FidoNews 31:04 [04/08]: Ftsc Information To : All From : FidoNews Robot Date : Mon Jan 27 2014 03:42:01 used in exceptional circumstances, since it risks conflict with conventional dialling, and it is almost always better to list a fully qualified domain name in a field that allows it. Field 7: DCE speed (required, but obsolete) Type: string; Length: 1+ In the past, this field was used to show the maximum modem speed supported by the node, but has since been obsoleted in favour of the more accurate modem flags. Commonly accepted values in this field are: 300, 1200, 2400, 4800, 9600, 14400, 16800, 19200, 28800 and 33600. These values are normally enforced by segment processing software; deviations risk the entire entry being declared in error and dropped from the nodelist or segment. Systems without a listed PSTN line must use 300, including ISDN and IP only nodes. All others may use whichever value is most appropriate. Because this field is now of little value except for human readers, most PSTN capable systems currently list at most 9600. Nodelist maintainers should confirm with their Coordinator(s) before listing higher rates. Field 8+: Flags (optional) Type: string; Length: varied; Characters: varied. Any remaining fields from position eight (8) onward are flag fields. Note there may or may not be a trailing comma after Field 7 if there are no flags listed. See FTS-5001 for details on the flag fields, including length restrictions. 6. Nodediffs ------------ The nodelist, even in archive form, is a substantial document (or file). To reduce bandwidth usage/waste and transmission times, a smaller file called a "nodediff" is generated using the previous week's nodelist. The nodediff is actually an editing script which contains only new or changed lines between the two nodelists, plus a number of editing commands. The nodediff file is named and archived in the same way as the full Distribution Nodelist, except with a base filename of NODEDIFF. 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 is no terminating EOF (^Z) character on a nodediff. There are three editing commands and all have the same format: is a 1-letter command; A, C, or D. is an integer from 1 to 32767 (inclusive), 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. 7. Segments ----------- Segments are partial nodelists, usually containing only one complete branch of nodes, starting at the relevant zone, region, host or hub node. The Distribution Nodelist is also referred to as a composite nodelist, as it is assembled from multiple zone-lists. The format and structure is the same as the Distribution Nodelist, including the header, with a base filename of local invention, usually derived from the contents of the segment (e.g. N712LIST.nnn or N712SEG.nnn for a segment containing all the nodes in Net 712). To generate the Distribution Nodelist, segments propagate up through the network's administrative hierarchy, each tier compiling segments from the tier immediately below, then passing on the resulting segment to the next tier upstream. For example, a Network Coordinator will collect Hub Segments from all the hubs in the same local network, compile it into a Network Segment, and forward it on to the Regional Coordinator. And so on. Segments can also be sent back downstream - this is most commonly done with Zone Nodelists. Nodes that do not need to attempt direct contact with nodes in other zones can use the Zone Nodelist instead of the full composite nodelist, saving on storage space and transmission time. A. References ------------- [FTS-0005] "The distribution nodelist", Ben Baker, Rick Moore. February 1989. Obsoleted by this document. [FTA-1006] "Keywords to indicate requirement levels" FTSC, 2000-01-17. [Policy] "FidoNet Policy Document" v4.07 - June 9, 1989. B. History ---------- Rev.1, 1999-06-27: Initial Release. Principal Author David Hallford Rev.2, 2000-04-24: Re-draft by Gino Lucrezi, with input from others especially Andreas Klein. Major changes: Notes on parsing line 1. Baud rate. Different use of fields for IP nodes. Notes to developers and maintainers. Notes on pointlists. Notes on line and field limits. Revised definition of "Hold" nodes. Clarification on hub node numbers. Clarification on point phone numbers. Clarification on the former "speed" field. Rev.2, 2004-08-17: Re-re-draft by FTSC. Added Introduction and Segments sections. More allowances for IP listings. Reorganised/reindexed Content section. Added length limits to fields where they could be determined. Clarification on usage of Keywords. Clarification on special node numbers. ZCs authorise that ZIP is now the default Archival/compression tool for distributed files. Rev.3, 2012-11-12: There is no version 3. The above version 2004-08-17 should have been labelled version 3, but due to a clerical error it was also labelled version 2. So there are two version 2's. Rather than attempting to correct the error, which would probably not have succeeded as it is next to impossible to recall a file that was hatched many years ago, it was decided to leave things as they are, skip version 3 and carry on with version 4. Rev.4, 2012-12-17: Allow -Unpublished- with Down (par 5.3, field 6) Various small rewordings, clairifications and corrections of spelling errors. Rev.5, 2014-01-23 Allow -Unpublished- with any or no keyword. "must" replaced by "should" on 157 char limit. Added reference to FTA-1006. Corrected a few spelling errors. Reformatted for compliance with FTA-1002.003 ********************************************************************** ----------------------------------------------------------------- --- Azure/NewsPrep 3.0 * Origin: Home of the Fidonews (2:2/2.0) .