home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / BBS / MKNL250.ZIP / FTS-0005.TXT < prev    next >
Text File  |  1989-02-05  |  18KB  |  503 lines

  1. FTS-0005
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                         The Distribution Nodelist
  8.  
  9.  
  10.                 Original by Ben Baker,  7:44/76@AlterNet
  11.                 Amended by Rick Moore,  1:115/333@FidoNet
  12.                             February 5,  1989
  13.  
  14.  
  15.  
  16. Copyright 1986,  1987,  1988,  1989 by the International FidoNet
  17. Association.  All rights reserved.  Duplication and/or distribution
  18. permitted for non-commercial purposes only.
  19.  
  20. This document supercedes and replaces the document known under the names
  21. of FSC002,  FSC-0002,  and FTS-0002.
  22.  
  23. This document defines the format and content of the nodelist for the
  24. Public FidoNet Network (PFN) as published each Friday.
  25.  
  26. The PFN is an international network of independently owned electronic
  27. mail systems,  most with interlocking electronic bulletin board systems. 
  28. The distribution nodelist,  or simply "nodelist",  is the glue which
  29. holds the network together.  It is the PFN's "phone book" and it defines
  30. the top-level network structure.
  31.  
  32. The nodelist is published as an ASCII text file named NODELIST.nnn, 
  33. where nnn is the day-of-year of the Friday publication date.  This file
  34. is packed into an standard archive file (using System Enhancement
  35. Associates' ARC file format) named NODELIST.Ann,  where nn are the last
  36. two digits of day-of-year.
  37.  
  38. A companion file,  COORD.nnn,  lists the coordinators of the various
  39. regions and local networks which constitute the PFN.  This file may be
  40. created from NODELIST.nnn by the program COORD.EXE,  distributed by many
  41. PFN bulletin boards.
  42.  
  43. As stated above,  NODELIST.nnn is an ASCII text file.  It contains two
  44. kinds of lines,  comment lines and data lines.  Each line is terminated
  45. with an ASCII carriage return and line feed character sequence,  and
  46. contains no trailing white-space (spaces, tabs, etc.).  The file is
  47. terminated with an end-of-file character (EOF = decimal character value
  48. 26).
  49.  
  50. Comments lines contain a semicolon (;) in the first character position
  51. followed by zero or more alphabetic characters called "interest flags". 
  52. A program which processes the nodelist may use comment interest flags to
  53. determine the disposition of a comment line.  The remainder of a comment
  54. line (with one exception,  treated below) is free-form ASCII text. 
  55. There are five interest flags defined as follows:
  56.  
  57.      ;S This comment is of particular interest to Sysops.
  58.  
  59.      ;U This comment is of particular interest to BBS users.
  60.  
  61.                                     1
  62. FTS-0005
  63.  
  64.  
  65.  
  66.  
  67.  
  68.      ;F This comment should appear in any formatted "Fido List".
  69.  
  70.      ;A This comment is of general interest (shorthand for ;SUF).
  71.  
  72.      ;E This comment is an error message inserted by the nodelist
  73.           generating program MakeNL.
  74.  
  75.      ; This comment may be ignored by a nodelist processor.
  76.  
  77. The first line of a nodelist is a special comment line containing
  78. identification data for the particular edition of the nodelist.  The
  79. following is an example of the first line of a nodelist:
  80.  
  81. ;A FidoNet Nodelist for Friday, July 3, 1987 --
  82.      Day number 184 : 15943
  83.  
  84. This line contains the general interest flag,  the day,  date,  and
  85. day-of-year number of publication,  and ends with a 5-digit decimal
  86. number with leading zeros,  if necessary.  This number is the decimal
  87. representation of a check value derived as follows:
  88.  
  89.      Beginning with the first character of the second line,  a 16-bit
  90.      cyclic redundancy check (CRC) is calculated for the entire file,
  91.      including carriage return and line feed characters,  but not
  92.      including the terminating EOF character.  The check polynomial used
  93.      is the same one used for many file transfer protocols:
  94.  
  95.           2**16 + 2**12 + 2**5 + 2**0
  96.  
  97. The CRC may be used to verify that the file has not been edited.  The
  98. importance of this will become evident in the discussion of NODEDIFF, 
  99. below.  CRC calculation techniques are well documented in the
  100. literature,  and will not be treated further here.
  101.  
  102. The content of the remaining comments in the nodelist are intended to be
  103. informative.  Beyond the use of interest flags for distribution,  a
  104. processing program need not have any interest in them.
  105.  
  106. A nodelist data line contains eight variable length "fields" separated
  107. by commas (,).  No space characters are allowed in a data line,  and
  108. underscore characters are used in lieu of spaces.  The term
  109. "alphanumeric character" is defined as the portion of the ASCII
  110. character set from 20 hex through 7E hex,  inclusive.  The following
  111. discussion defines the contents of each field in a data line.
  112.  
  113.  
  114. Field 1: Keyword
  115.  
  116. The keyword field may be empty,  or may contain one of the following:
  117.  
  118.      Zone  --
  119.           Begins the definition of a geographic zone and define its
  120.           coordinator.  All the data lines following a line with the
  121.           "Zone" keyword down to,  but not including,  the next
  122.  
  123.  
  124.                                     2
  125. FTS-0005
  126.  
  127.  
  128.  
  129.           occurrence of a "Zone" keyword,  are regions,  networks,  and
  130.           nodes within the defined zone.
  131.  
  132.      Region --
  133.           Begins the definition of a geographic region and defines its
  134.           coordinator.  All the data lines following a line with the
  135.           "Region" keyword down to,  but not including,  the next
  136.           occurrence of a "Zone",  "Region",  or "Host" keyword, are
  137.           independent nodes within the defined region.
  138.  
  139.      Host --
  140.           Begins the definition of a local network and defines its host. 
  141.           All the data lines following a line with the Host keyword down
  142.           to,  but not including,  the next occurrence of a "Zone", 
  143.           "Region",  or "Host" keyword,  are local nodes,  members of
  144.           the defined local network.
  145.  
  146.      Hub --
  147.           Begins the definition of a routing subunit within a multilevel
  148.           local network.  The hub is the routing focal point for nodes
  149.           listed below it until the next occurrence of a "Zone", 
  150.           "Region",  "Host",  or "Hub" keyword.  The hub entry MUST be a
  151.           redundant entry,  with a unique number,  for one of the nodes
  152.           listed below it.  This is necessary because some nodelist
  153.           processors eliminate these entries in all but the local
  154.           network.
  155.  
  156.      Pvt --
  157.           Defines a private node with unlisted number.  Private nodes
  158.           are only allowed as members of local networks.
  159.  
  160.      Hold --
  161.           Defines a node which is temporarily down.  Mail may be sent to
  162.           it and is held by its host or coordinator.
  163.  
  164.      Down --
  165.           Defines a node which is not operational.  Mail may NOT be sent 
  166.           to it.  This keyword may not be used for longer than two weeks
  167.           on any single node,  at which point the "down" node is to be
  168.           removed from the nodelist.
  169.  
  170.      <empty> --
  171.           Defines a normal node entry.
  172.  
  173. Field 2 - Zone/Region/Net/Node number
  174.  
  175.      This field contains only numeric digits and is a number in the
  176.      range of 0 to 32767.  If the line had the "Zone",  "Region",  or
  177.      "Host" keyword,  the number is the zone,  net,  or region number, 
  178.      and the node has an implied node number of 0.  Otherwise,  the
  179.      number is the node number.  The zone number,  region or net number, 
  180.      and the node number,  taken together,  constitute a node's FidoNet
  181.      address.
  182.  
  183.      Zone numbers must be unique.  Region or net numbers must be unique
  184.      within their zone.  Hub numbers must be within their net.  Node
  185.  
  186.  
  187.                                     3
  188. FTS-0005
  189.  
  190.  
  191.  
  192.  
  193.      numbers must be unique within their region (for regional
  194.      independents) or net (for members of a local network).  Duplicate
  195.      node numbers under different hubs within the same net are not
  196.      allowed.
  197.  
  198. Field 3 - Node name
  199.  
  200.      This field may contain any alphanumeric characters other than
  201.      commas and spaces.  Underscores are used to represent spaces.  This
  202.      is the name by which the node is known.
  203.  
  204. Field 4 - Location
  205.  
  206.      This field may contain any alphanumeric characters other than
  207.      commas and spaces.  Underscores are used to represent spaces.  This
  208.      field contains the location of the node.  It is usually expressed
  209.      as the primary local location (town,  suburb,  city,  etc.) plus
  210.      the identifier of the regional geopolitical administrative district
  211.      (state,  province,  department,  county,  etc.).  Wherever
  212.      possible,  standard postal abbreviations for the major regional
  213.      district should be used (IL,  BC,  NSW,  etc.).
  214.  
  215. Field 5 - Sysop name
  216.  
  217.      This field may contain any alphanumeric characters other than
  218.      commas and spaces.  Underscores are used to represent spaces.  This
  219.      is the name of the system operator.
  220.  
  221. Field 6 - Phone number
  222.  
  223.      This field contains at least three and usually four numeric
  224.      subfields separated by dashes (-).  The fields are country code, 
  225.      city or area code,  exchange code,  and number.  The various parts
  226.      of the phone number are frequently used to derive cost and routing
  227.      information,  as well as what number is to be dialed.  A typical
  228.      example of the data in a phone number field is 1-800-555-1212, 
  229.      corresponding to country 1 (USA),  area 800 (inbound WATS), 
  230.      exchange 555,  and number 1212.
  231.  
  232.      Alternatively,  this field may contain the notation "-Unpublished-"
  233.      in the case of a private node.  In this case,  the keyword "Pvt"
  234.      must appear on the line.
  235.  
  236. Field 7 - Baud rate
  237.  
  238.      This field contains one of the values:  300,  1200,  2400,  9600, 
  239.      19200,  or 38400,  and defines the maximum baud rate supported by
  240.      the node.
  241.  
  242. Field 8 - Flags
  243.  
  244.      This optional field contains data about the specific operation of
  245.      the node,  such as file requests,  modem protocol supported,  etc. 
  246.      Any text following the seventh comma on a data line is taken
  247.      collectively to be the flags field.  The required format is zero or
  248.  
  249.  
  250.                                     4
  251. FTS-0005
  252.  
  253.  
  254.  
  255.  
  256.      more subfields,  separated by commas.  Each subfield consists of a
  257.      flag,  possibly followed by a value.
  258.  
  259.  
  260.      The following flags define special operating conditions:
  261.  
  262.           Flag      Meaning
  263.  
  264.           CM        Node accepts mail 24 hours a day
  265.           MO        Node does not accept human callers
  266.  
  267.  
  268.      The following flags define modem protocols supported:
  269.  
  270.           Flag      Meaning
  271.  
  272.           V21       CCITT V21   300 bps full duplex
  273.           V22       CCITT V22   1200 bps full duplex
  274.           V29       CCITT V29   9600 bps half duplex
  275.           V32       CCITT V32   9600 bps full duplex
  276.           V33       CCITT V33
  277.           V34       CCITT V34
  278.           H96       Hayes V9600
  279.           HST       USR Courier HST
  280.           MAX       Microcom AX/96xx series
  281.           PEP       Packet Ensemble Protocol
  282.  
  283.                NOTE:  Many V22 modems also support Bell 212A.
  284.  
  285.           If no modem flag is given,  Bell 212A is assumed for 1200 bps
  286.           systems,  CCITT V22bis is assumed for 2400 bps systems.
  287.  
  288.  
  289.      The following flags define type of error correction available.  A
  290.      separate error correction flag should not be used when the error
  291.      correction type can be determined by the modem flag.  For instance, 
  292.      a modem flag of HST implies MNP.
  293.  
  294.           Flag      Meaning
  295.  
  296.           MNP       Microcom Networking Protocol error correction
  297.           V42       LAP-M error correction w/fallback to MNP
  298.  
  299.  
  300.      The following flags define the type(s) of compression of mail
  301.      packets supported.
  302.  
  303.           Flag      Meaning
  304.  
  305.           MN        No compression supported
  306.  
  307.                     NOTE:  The only compression method standard in
  308.                     FidoNet is archiving,  using the standard SEA ARC
  309.                     format,  with archive names defined by the
  310.                     specification for ARCMail 0.6.  The absence of the
  311.  
  312.  
  313.                                     5
  314. FTS-0005
  315.  
  316.  
  317.  
  318.  
  319.                     MN flag indicates that ARCMail 0.6 compression is
  320.                     supported by this node.
  321.  
  322.  
  323.      The following flags indicate the types of file/update requests
  324.      supported.
  325.  
  326.           Flag      Meaning
  327.  
  328.           XA        Bark and WaZOO file/update requests
  329.           XB        Bark file/update requests,  WaZOO file requests
  330.           XP        Bark file/update requests
  331.           XR        Bark and WaZOO file requests
  332.           XW        WaZOO file requests
  333.  
  334.  
  335.      The following flag defines gateways to other domains (networks).
  336.  
  337.           Flag      Meaning
  338.  
  339.           Gx..x     Gateway to domain 'x..x',  where 'x..x` is a string
  340.                     of alphanumeric characters.  Valid values for 'x..x'
  341.                     are assigned by the FidoNet International
  342.                     Coordinator.  Current valid values of 'x..x' may be
  343.                     found in the notes at the end of the FidoNet
  344.                     nodelist.
  345.  
  346.  
  347.      The following flags define the dedicated mail periods supported.
  348.      They have the form "#nn" or !nn where nn is the UTC hour the mail
  349.      period begins,  # indicates Bell 212A compatibility,  and !
  350.      indicates incompatibility with Bell 212A.
  351.  
  352.           Flag      Meaning
  353.  
  354.           #02       Zone 2 mail hour (02:30 - 03:30 UTC)
  355.           #09       Zone 1 mail hour (09:00 - 10:00 UTC)
  356.           #18       Zone 3 mail hour (18:00 - 19:00 UTC)
  357.  
  358.                     NOTE:  When applicable,  the mail period flags may
  359.                     be strung together with no intervening commas,  eg. 
  360.                     "#02#09".  Only mail hours other than that standard
  361.                     within a node's zone should be given.  Since
  362.                     observance of mail hour within one's zone is
  363.                     mandatory,  it should not be indicated.
  364.  
  365.  
  366.      The following flag defines user-specific values. If present,  this
  367.      flag MUST be the last flag present in a nodelist entry.
  368.  
  369.           Flag      Meaning
  370.  
  371.           Ux..x     A user-specified string,  which may contain any
  372.                     alphanumeric character except blanks.  This string
  373.                     may contain one to thirty-two characters of
  374.  
  375.  
  376.                                     6
  377. FTS-0005
  378.  
  379.  
  380.  
  381.  
  382.                     information that may be used to add user-defined
  383.                     data to a specific nodelist entry.
  384.  
  385.  
  386.  
  387.      FTSC recognizes that the FidoNet International Coordinator is the
  388.      ultimate authority over what appears in the FidoNet nodelist. Also, 
  389.      FTSC is by definition a deliberative body,  and adding or changing
  390.      a flag may take a considerable amount of time.  Therefore,  the
  391.      FidoNet International Coordinator may temporarily make changes or
  392.      additions to the flags as defined in this document.  The FidoNet
  393.      International Coordinator will then consult with FTSC over the
  394.      changes needed to this document to reflect these temporary changes.
  395.  
  396.  
  397.  
  398.      The following are examples of nodelist data lines:
  399.  
  400. Host,102,SOCALNET,Los_Angeles_CA,Richard_Martz,1-213-874-9484,2400,XP
  401. ,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,
  402.  
  403.  
  404.  
  405. With more than five thousand nodes as of this date,  the nodelist,  even
  406. in archive form,  is a substantial document (or file).  Since
  407. distribution is via electronic file transfer,  this file is NOT
  408. routinely distributed.  Instead,  when a new nodelist is prepared,  it
  409. is compared with the previous week's nodelist,  and a file containing
  410. only the differences is created and distributed.
  411.  
  412. The distribution file,  called NODEDIFF.nnn,  where nnn is the
  413. day-of-year of publication,  is actually an editing script which will
  414. transform the previous week's nodelist into the current nodelist.  A
  415. definition of its format follows:
  416.  
  417. The first line of NODEDIFF.nnn is an exact copy of the first line of
  418. LAST WEEK'S nodelist.  This is used as a first-level confidence check to
  419. insure that the right file is being edited.  The second and subsequent
  420. lines are editing commands and editing data.
  421.  
  422. There are three editing commands and all have the same format:
  423.  
  424.           <command><number>
  425.  
  426.      <command> is a 1-letter command;  A,  C,  or D.  <number> is a
  427.      decimal number greater than zero,  and defines the number of lines
  428.      to be operated on by the command.  Each command appears on a line
  429.      by itself.  The commands have the following meanings:
  430.  
  431.      Ann - Add the following nn lines to the output file.
  432.  
  433.      Cnn - Copy nn unchanged lines from the input to the output file.
  434.  
  435.      Dnn - Delete (or skip) nn lines from the input file.
  436.  
  437.  
  438.  
  439.                                     7
  440. FTS-0005
  441.  
  442.  
  443.  
  444.  
  445. The following illustrate how the first few lines of NODEDIFF.213 might
  446. look:
  447.  
  448.      ;A Friday, July 25, 1986 -- Day number 206 : 27712
  449.      D2
  450.      A2
  451.      ;A Friday, August 1, 1986 -- Day number 213 : 05060
  452.      ;A
  453.      C5
  454.  
  455. This fragment illustrates all three editing commands.  The first line is
  456. the first line from NODELIST.206.  The next line says "delete the first
  457. two lines" from NODELIST.206.  These are the identification line and the
  458. line following it.  The next command says "add the next two lines" to
  459. NODELIST.213.  The two data lines are followed by a command which says
  460. "copy five unchanged lines" from NODELIST.206 to NODELIST.213.  Notice
  461. that the first line added will ALWAYS contain the new nodelist's CRC.
  462.  
  463. Since only the differences will be distributed,  it is important to
  464. insure the accuracy of the newly created nodelist.  This is the function
  465. of the CRC mentioned above.  It is sufficient for a program designed to 
  466. perform the above edits to pick the CRC value from the first line added
  467. to the output file,  then compute the CRC of the rest of the output
  468. file.  If the two CRCs do not agree,  one of the input files has been
  469. corrupted.  If they do agree,  the probability is very high (but not
  470. 100%) that the output file is accurate.
  471.  
  472. For actual distribution,  NODEDIFF.nnn is packed into an archive file
  473. named NODEDIFF.Ann,  where nn are the last two digits of day-of-year.
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.                                     8
  503.