home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / MISC / STNL0306.ZIQ / FTSC.TXT < prev    next >
Text File  |  1999-07-08  |  32KB  |  819 lines
  1. **********************************************************************
  2. FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
  3. **********************************************************************
  4.  
  5. Publication:    FTS-5000
  6. Revision:       1
  7. Title:          THE DISTRIBUTION NODELIST
  8. Author(s):      Colin Turner, Andreas Klein, Michael McCabe,
  9.                 David Hallford, Odinn Sorensen
  10.  
  11. Revision Date:  27 June 1999
  12. Expiry Date:    17 June 2001
  13. ----------------------------------------------------------------------
  14. Contents:
  15.                 1. Supercessions
  16.                 2. Purpose
  17.                 3. Publication and Distribution
  18.                 4. Contents
  19.                 5. Nodediff
  20. ----------------------------------------------------------------------
  21.  
  22. Status of this document
  23. -----------------------
  24.  
  25.   This document is a Fidonet Standard (FTS).
  26.  
  27.   This document specifies a Fidonet standard for the Fidonet
  28.   community.
  29.  
  30.   This document is released to the public domain, and may be used,
  31.   copied or modified for any purpose whatever.
  32.  
  33.  
  34. Abstract
  35. --------
  36.  
  37.   Current practice for Fidonet Technology Networks (FTN) is to
  38.   maintain a nodelist used to store the details of the nodes in
  39.   the network, and the network structure.
  40.  
  41.  
  42. 1. Supercessions
  43. ----------------
  44.  
  45.   FTS-0005 superceded and replaced the documents known under the names
  46.   of FSC-0002, and FTS-0002.
  47.  
  48.   This document supercedes and replaces FTS-0005, FSC-0009, FSC-0040,
  49.   FSC-0075, FSC-0091, and FSP-1012.
  50.  
  51. 2. Purpose
  52. ----------
  53.  
  54.   Along with the companion technical standard (FTS-5001) this document
  55.   defines the format and content of the nodelist for the FidoNet
  56.   International Hobby Network. The FTS-5001 is seperated into two
  57.   parts - the first part is a listing of authorized flags and the
  58.   second part is a registry of userflags. The registry is used to
  59.   prevent a userflag from being used for more than one meaning. The
  60.   registry is maintained by the Fidonet Technical Standards Committee
  61.   Working Group D (the Nodelist).
  62.  
  63. 3. Publication and Distribution
  64. -------------------------------
  65.  
  66.   The nodelist is published as an ASCII text file named NODELIST.nnn,
  67.   where nnn is the day-of-year of the publication date.
  68.   For actual distribution,  NODELIST.nnn is packed into an archive
  69.   file named NODELIST.Pnn,  where nn are the last two digits of day-of
  70.   -year and P is the compression format used as listed below.
  71.         A = .arc
  72.         Z = .zip
  73.         J = .arj
  74.         R = .rar
  75.   Since .zip is useable on most computer platforms, it is recommended
  76.   that this format be used for distribution of the Distribution
  77.   Nodelist.
  78.  
  79.  
  80. 4. Contents
  81. -----------
  82.  
  83.   As stated above,  NODELIST.nnn is an ASCII text file.  It contains
  84.   two kinds of lines,  comment lines and data lines.  Each line is
  85.   terminated with an ASCII carriage return and line feed character
  86.   sequence, and contains no trailing white-space (spaces, tabs, etc.).
  87.   The file is terminated with an end-of-file character, ASCII <EOF>
  88.   (1AH).
  89.  
  90.   Comments lines contain a semicolon (;) in the first character
  91.   position followed by zero or more alphabetic characters called
  92.   "interest flags". A program which processes the nodelist may use
  93.   comment interest flags to determine the disposition of a comment
  94.   line.  The remainder of a comment line (with one exception, treated
  95.   below) is free-form ASCII text.
  96.  
  97.   There are five interest flags defined as follows:
  98.  
  99.      ;S This comment is of particular interest to Sysops.
  100.  
  101.      ;U This comment is of particular interest to BBS users.
  102.  
  103.      ;F This comment should appear in any formatted "Fido List".
  104.  
  105.      ;A This comment is of general interest (shorthand for ;SUF).
  106.  
  107.      ;E This comment is an error message inserted by a nodelist
  108.         generating program.
  109.  
  110.      ;  This comment may be ignored by a nodelist processor.
  111.  
  112.   The first line of a nodelist is a special comment line containing
  113.   identification data for the particular edition of the nodelist. The
  114.   following is an example of the first line of a nodelist:
  115.  
  116.   ;A FidoNet Nodelist for Friday, July 3, 1987 --
  117.        Day number 184 : 15943
  118.  
  119.   This line contains the general interest flag,  the day,  date,  and
  120.   day-of-year number of publication,  and ends with a 5-digit decimal
  121.   number with leading zeros, if necessary.  This number is the decimal
  122.   representation of a check value derived as follows:
  123.  
  124.      Beginning with the first character of the second line,  a 16-bit
  125.      cyclic redundancy check (CRC) is calculated for the entire file,
  126.      including carriage return and line feed characters,  but not
  127.      including the terminating EOF character.  The check polynomial
  128.      used is the same one used for many file transfer protocols:
  129.  
  130.           2**16 + 2**12 + 2**5 + 2**0
  131.  
  132.   The CRC may be used to verify that the file has not been edited. The
  133.   importance of this will become evident in the discussion of NODEDIFF
  134.   below.  CRC calculation techniques are well documented in the
  135.   literature,  and will not be treated further here.
  136.  
  137.   The content of the remaining comments in the nodelist are intended
  138.   to be informative. Beyond the use of interest flags for distribution
  139.   , a processing program need not have any interest in them.
  140.  
  141.   A nodelist data line contains eight variable length "fields"
  142.   separated by commas (,).  No space characters are allowed in a data
  143.   line, and  underscore characters are used in lieu of spaces.  The
  144.   term "alphanumeric character" is defined as the portion of the ASCII
  145.   character set from 20 hex through 7E hex, inclusive.  The following
  146.   discussion defines the contents of each field in a data line.
  147.  
  148.  
  149.   Field 1: Keyword
  150.  
  151.   The keyword field may be empty, or may contain exactly one keyword
  152.   approved by the Zone Coordinator Council. Current approved keywords
  153.   are:
  154.  
  155.      Zone  --
  156.           Begins the definition of a geographic zone and define its
  157.           coordinator.  All the data lines following a line with the
  158.           "Zone" keyword down to, but not including, the next
  159.           occurrence of a "Zone" keyword, are regions, nets, and
  160.           nodes within the defined zone.
  161.  
  162.      Region --
  163.           Begins the definition of a geographic region and defines its
  164.           coordinator.  All the data lines following a line with the
  165.           "Region" keyword down to, but not including, the next
  166.           occurrence of a "Zone", "Region", or "Host" keyword, are
  167.           independent nodes within the defined region.
  168.  
  169.      Host --
  170.           Begins the definition of a local network and defines its
  171.           host. All the data lines following a line with the Host
  172.           keyword down to, but not including,  the next occurrence of
  173.           a "Zone", "Region", or "Host" keyword, are local nodes,
  174.           members of the defined local network.
  175.  
  176.      Hub --
  177.           Begins the definition of a routing subunit within a
  178.           multilevel local network.  The hub is the routing focal
  179.           point for nodes listed below it until the next occurrence
  180.           of a "Zone", "Region", "Host", or "Hub" keyword.  The hub
  181.           entry MUST be a redundant entry,  with a unique number,
  182.           for one of the nodes listed below it.  This is necessary
  183.           because some nodelist processors eliminate these entries
  184.           in all but the local network.
  185.  
  186.      Pvt --
  187.           Defines a private node with unlisted number.  Private nodes
  188.           are only allowed as members of local networks.
  189.  
  190.      Hold --
  191.          Defines a node which is temporarily down,or  is a region/zone
  192.          independent node which is reachable via IP only. Mail may be
  193.          sent to it and is held by its host or coordinator.
  194.  
  195.      Down --
  196.           Defines a node which is not operational.  Mail may NOT be
  197.           sent to it.  This keyword may not be used for longer than
  198.           two weeks on any single node,  at which point the "down"
  199.           node is to be removed from the nodelist.
  200.  
  201.  
  202.      <empty> --
  203.           Defines a normal node entry.
  204.  
  205.  
  206.  
  207.   Field 2 - Zone/Region/Net/Node number
  208.  
  209.      This field contains only numeric digits and is a number in the
  210.      range of 1 to 32767.  If the line had the "Zone",  "Region",  or
  211.      "Host" keyword,  the number is the zone, net, or region number,
  212.      and the node has an implied node number of 0, therfore the use of
  213.      a 0 in this field is strictly forbidden.  Otherwise,  the
  214.      number is the node number. The zone number, region or net number,
  215.      and the node number, taken together, constitute a node's FidoNet
  216.      address.
  217.  
  218.      Zone numbers must be unique.  Region or net numbers must be
  219.      unique within their zone.  Hub numbers must be within their net.
  220.      Node numbers must be unique within their region (for regional
  221.      independents) or net (for members of a local network).  Duplicate
  222.      node numbers under different hubs within the same net are not
  223.      allowed.
  224.  
  225.   Field 3 - Node name
  226.  
  227.      This field may contain any alphanumeric characters other than
  228.      commas and spaces.  Underscores are used to represent spaces.
  229.      This is the name by which the node is known.
  230.      For IP nodes this field may alternately contain an ip address or
  231.      E-Mail address for email tunneling programs.
  232.  
  233.   Field 4 - Location
  234.  
  235.      This field may contain any alphanumeric characters other than
  236.      commas and spaces.  Underscores are used to represent spaces.
  237.      This field contains the location of the node.  It is usually
  238.      expressed as the primary local location (town,  suburb,  city,
  239.      etc.) plus the identifier of the regional geopolitical admin-
  240.      istrative district (state,  province,  department,  county,
  241.      etc.).  Wherever possible,  standard postal abbreviations for
  242.      the major regional district should be used (IL, BC, NSW, etc.).
  243.  
  244.   Field 5 - Sysop name
  245.  
  246.      This field may contain any alphanumeric characters other than
  247.      commas and spaces.  Underscores are used to represent spaces.
  248.      This is the name of the system operator.
  249.  
  250.   Field 6 - Phone number
  251.  
  252.      This field contains at least three and usually four numeric
  253.      subfields separated by dashes (-).  The fields are country code,
  254.      city or area code, exchange code, and number.  The various parts
  255.      of the phone number are frequently used to derive cost and
  256.      routing information, as well as what number is to be dialed.
  257.      A typical example of the data in a phone number field is 1-800-
  258.      555-1212, corresponding to country 1 (USA),  area 800 (inbound
  259.      WATS), exchange 555, and number 1212.
  260.  
  261.      Alternatively, this field may contain the notation -Unpublished-
  262.      in the case of a private node.  In this case, the keyword "Pvt"
  263.      must appear on the line.
  264.  
  265.     This field may also contain the IP address for an IP node
  266.     utilizing the country code of 000.
  267.  
  268.   Field 7 - Baud rate
  269.  
  270.      This field contains the maximum baud rate supported by the node.
  271.      (eg: 9600, 14400, 38400, etc)
  272.  
  273.   Field 8 - Flags
  274.  
  275.      This optional field contains data about the specific operation of
  276.      the node, such as file requests, modem protocol supported, etc.
  277.      Any text following the seventh comma on a data line is taken
  278.      collectively to be the flags field.  The required format is zero
  279.      or more subfields, separated by commas.  Each subfield consists
  280.      of a flag, possibly followed by a value. The authorized flags
  281.      for use in the distribution nodelist are distributed as in
  282.      FTS-5001 to facilitate additions and deletions of the authorized
  283.      flags without requiring an amendment to this FTS.
  284.  
  285.      FTSC recognizes that the FidoNet Zone Coordinator Council with
  286.      the International Coordinator as the ZCC Chairman is the
  287.      ultimate authority over what appears in the FidoNet nodelist.
  288.      Also, FTSC is by definition a deliberative body,  and adding or
  289.      changing a flag may take a considerable amount of time.
  290.      Therefore, the  FidoNet International Coordinator or Zone
  291.      Coordinators may temporarily  make changes or additions to the
  292.      flags as defined in FTS-5001.  The FidoNet International
  293.      Coordinator/Zone Coordinators will then consult with FTSC over
  294.      the changes needed to FTS-5001 to reflect these temporary
  295.      changes.
  296.  
  297.  
  298.  
  299.      The following are examples of nodelist data lines:
  300.  
  301.   Host,102,SOCALNET,Los_Angeles_CA,Richard_Mart,1-213-874-9484,2400,XP
  302.  
  303.   ,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,
  304.  
  305.   ,102,fido.tree.com,Los_Angeles_CA,Bill_Smart,1-213-555-1212,9600,
  306.   CM,IP,ITN
  307.  
  308.  
  309. 5. Nodediff
  310. -----------
  311.  
  312.   With more than twenty thousand nodes as of this date,  the nodelist,
  313.   even in archive form,  is a substantial document (or file).  Since
  314.   distribution is via electronic file transfer,  this file is NOT
  315.   routinely distributed.  Instead, when a new nodelist is prepared, it
  316.   is compared with the previous week's nodelist, and a file containing
  317.   only the differences is created and distributed.
  318.  
  319.   The distribution file,  called NODEDIFF.nnn,  where nnn is the
  320.   day-of-year of publication, is actually an editing script which will
  321.   transform the previous week's nodelist into the current nodelist.  A
  322.   definition of its format follows:
  323.  
  324.   The first line of NODEDIFF.nnn is an exact copy of the first line of
  325.   LAST WEEK'S nodelist. This is used as a first-level confidence check
  326.   to insure that the right file is being edited.  The second and sub-
  327.   sequent lines are editing commands and editing data.
  328.  
  329.   There are three editing commands and all have the same format:
  330.  
  331.           <command><number>
  332.  
  333.      <command> is a 1-letter command;  A,  C,  or D.  <number> is a
  334.      decimal number greater than zero,  and defines the number of
  335.      lines to be operated on by the command.  Each command appears on
  336.      a line by itself.  The commands have the following meanings:
  337.  
  338.      Ann - Add the following nn lines to the output file.
  339.  
  340.      Cnn - Copy nn unchanged lines from the input to the output file.
  341.  
  342.      Dnn - Delete  nn lines from the input file.
  343.  
  344.   The following illustrate how the first few lines of NODEDIFF.213
  345.   might look:
  346.  
  347.      ;A Friday, July 25, 1986 -- Day number 206 : 27712
  348.      D2
  349.      A2
  350.      ;A Friday, August 1, 1986 -- Day number 213 : 05060
  351.      ;A
  352.      C5
  353.  
  354.   This fragment illustrates all three editing commands. The first line
  355.   is the first line from NODELIST.206.  The next line says "delete the
  356.   first two lines" from NODELIST.206.  These are the identification
  357.   line and the line following it.  The next command says "add the next
  358.   two lines" to NODELIST.213.  The two data lines are followed by a
  359.   command which says "copy five unchanged lines" from NODELIST.206 to
  360.   NODELIST .213.  Notice that the first line added will ALWAYS contain
  361.   the new nodelist's CRC.
  362.  
  363.   Since only the differences will be distributed,  it is important to
  364.   insure the accuracy of the newly created nodelist.  This is the
  365.   function of the CRC mentioned above.  It is sufficient for a program
  366.   designed to perform the above edits to pick the CRC value from the
  367.   first line added to the output file, then compute the CRC of the
  368.   rest of the output file.  If the two CRCs do not agree,  one of the
  369.   input files has been corrupted.  If they do agree,  the probability
  370.   is very high (but not 100%) that the output file is accurate.
  371.  
  372.   For actual distribution, NODEDIFF.nnn is packed into an archive file
  373.   named NODEDIFF.Pnn,  where nn are the last two digits of day-of-year
  374.   and P is the compression format used as listed below.
  375.         A = .arc
  376.         Z = .zip
  377.         J = .arj
  378.         R = .rar
  379.   Since .zip is useable on most computer platforms, it is recommended
  380.   that this format be used for distribution of the Distribution
  381.   Nodediff.
  382.  
  383. A. References
  384. -------------
  385.  
  386.   [FTS-5] "The distribution nodelist", Ben Baker, Rick Moore.
  387.   February 1989. Obsoleted by this document.
  388.  
  389.   [FSC-9] "Nodelist flag Changes draft document", Ray Gwinn, David
  390.   Dodell. November 1987. Obsoleted by this document.
  391.  
  392.   [FSC-40] "Extended Modem Handling", Michael Shiels. February 1990.
  393.   Obsoleted by this document.
  394.  
  395.   [FSC-75] "ISDN capability flags in the nodelist", Jan Ceuleers.
  396.   October 1993. Obsoleted by this document.
  397.  
  398.   [FSC-91] "ISDN nodelist flags", Arjen Lentz.
  399.   October 1995. Obsoleted by this document.
  400.  
  401.   [FSP-1012] "Integration of IP Nodes in the nodelist", Lothar Behet
  402.   June 1999.
  403.  
  404. B. Contact Data
  405. ---------------
  406.  
  407.   David Hallford
  408.   Fidonet: 1:208/103
  409.  
  410.   Andreas Klein
  411.   Fidonet: 2:2480/47
  412.   E-mail:  akx@gmx.net
  413.  
  414.   Michael McCabe
  415.   Fidonet: 1:297/11
  416.  
  417.   Odinn Sorensen
  418.   Fidonet: N/A
  419.   E-mail:  odinn@goldware.dk
  420.   WWW:     http://www.goldware.dk
  421.  
  422.   Colin Turner
  423.   Fidonet: 2:443/13
  424.   E-mail:  ct@piglets.com
  425.   WWW:     http://www.piglets.com
  426.  
  427. C. History
  428. ----------
  429.  
  430.    Rev.1, 19990627: Initial Release. Principal Author David Hallford
  431.  
  432. --- BBBS/LiI v3.50 Flag-D
  433.  * Origin: Stronghold Enterprises/X - telnet://shx.tzo.net (111:111/0)
  434.  
  435. **********************************************************************
  436. FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
  437. **********************************************************************
  438.  
  439. Publication:    FTS-5001
  440. Revision:       1
  441. Title:          NODELIST FLAGS AND USERFLAGS
  442. Author(s):      Colin Turner, Andreas Klein, Michael McCabe,
  443.                 David Hallford, Odinn Sorensen
  444.  
  445. Revision Date:  27 June 1999
  446. Expiry Date:    27 June 2001
  447. ----------------------------------------------------------------------
  448. Contents:
  449.                 1. Authorized Flags
  450.                 2. Userflags
  451. ----------------------------------------------------------------------
  452.  
  453. Status of this document
  454. -----------------------
  455.  
  456.   This document is a Fidonet Standard (FTS).
  457.  
  458.   This document specifies a Fidonet standard for the Fidonet
  459.   community.
  460.  
  461.   This document is released to the public domain, and may be used,
  462.   copied or modified for any purpose whatever.
  463.  
  464.  
  465. Abstract
  466. --------
  467.  
  468.   Current practice for Fidonet Technology Networks (FTN) is to
  469.   maintain a nodelist used to store the details of the nodes in
  470.   the network, and the network structure. Flags are used in this
  471.   nodelist to aid automatic and manual control of various tasks.
  472.  
  473.  
  474. 1. Authorized flags
  475. -------------------
  476.  
  477.  Flags authorized for use in the Fidonet nodelist:
  478.  
  479.   A: OPERATING CONDITION FLAGS:
  480.  
  481.           Flag      Meaning
  482.  
  483.           CM        Node accepts mail 24 hours a day
  484.           MO        Node does not accept human callers
  485.           LO        Node accepts calls Only from Listed
  486.                     FidoNet addresses
  487.  
  488.   B. MODEM FLAGS:
  489.      The following flags define modem protocols supported:
  490.  
  491.           Flag      Meaning
  492.  
  493.           V21       CCITT V.21     300 bps   full duplex
  494.           V22       CCITT V.22     1200 bps  full duplex
  495.           V29       CCITT V.29     9600 bps  half duplex
  496.           V32       CCITT V.32     9600 bps  full duplex
  497.           V32b      ITU-T V.32 bis 14400 bps full duplex
  498.           V32T      V.32 Terbo
  499.           V33       CCITT V.33
  500.           V34       CCITT V.34
  501.           HST       USR Courier HST
  502.           H14       USR Courier HST 14.4
  503.           H16       USR Courier HST 16.8
  504.           H96       Hayes V9600
  505.           MAX       Microcom AX/96xx series
  506.           PEP       Packet Ensemble Protocol
  507.           CSP       Compucom Speedmodem
  508.           ZYX       Zyxel series
  509.           VFC       V.Fast Class
  510.           Z19       Zyxel 19,200 modem protocol
  511.           V90C      ITU-T V.90 modem Client
  512.           V90S      ITU-T V.90 Server.
  513.           X2C       US Robotics x2 client.
  514.           X2S       US Robotics x2 server.
  515.  
  516.  
  517.  
  518.      The following flags define type of error correction available. A
  519.      separate error correction flag should not be used when the error
  520.      correction type can be determined by the modem flag. For instance
  521.      a modem flag of HST implies MNP.
  522.  
  523.           Flag      Meaning
  524.  
  525.           MNP       Microcom Networking Protocol error correction
  526.                     of type MNP1 to MNP4
  527.           V42       LAP-M error correction w/fallback to MNP
  528.  
  529.   C: COMPRESSION FLAGS:
  530.  
  531.      The following flags define the type(s) of compression of mail
  532.      packets supported.
  533.  
  534.           Flag      Meaning
  535.  
  536.           MN        No compression supported
  537.  
  538.      The following flags define the type(s) of data compression
  539.      available.
  540.  
  541.           V42b      ITU-T V42bis
  542.  
  543.  
  544.   D: FILE/UPDATE REQUEST FLAGS:
  545.  
  546.      The following flags indicate the types of file/update requests
  547.      supported.
  548.  
  549.  
  550.   |--------------------------------------------------|
  551.   |      |         Bark        |        WaZOO        |
  552.   |      |---------------------|---------------------|
  553.   |      |   File   |  Update  |   File   |  Update  |
  554.   | Flag | Requests | Requests | Requests | Requests |
  555.   |------|----------|----------|----------|----------|
  556.   | XA   |    Yes   |    Yes   |    Yes   |    Yes   |
  557.   | XB   |    Yes   |    Yes   |    Yes   |    No    |
  558.   | XC   |    Yes   |    No    |    Yes   |    Yes   |
  559.   | XP   |    Yes   |    Yes   |    No    |    No    |
  560.   | XR   |    Yes   |    No    |    Yes   |    No    |
  561.   | XW   |    No    |    No    |    Yes   |    No    |
  562.   | XX   |    No    |    No    |    Yes   |    Yes   |
  563.   |--------------------------------------------------|
  564.  
  565.   E: GATEWAY FLAG:
  566.  
  567.      The following flag defines gateways to other domains (networks).
  568.  
  569.           Flag      Meaning
  570.  
  571.           Gx..x     Gateway to domain 'x..x', where 'x..x` is a string
  572.                     of alphanumeric characters. Valid values for
  573.                     'x..x' are assigned by the FidoNet International
  574.                     Coordinator.  Current valid values of 'x..x' may
  575.                     be found in the notes at the end of the FidoNet
  576.                     nodelist.
  577.  
  578.   F: MAIL PERIOD FLAGS:
  579.      The following flags define the dedicated mail periods supported.
  580.      They have the form "#nn" or !nn where nn is the UTC hour the mail
  581.      period begins,  # indicates Bell 212A compatibility,  and !
  582.      indicates incompatibility with Bell 212A.
  583.  
  584.           Flag      Meaning
  585.  
  586.  
  587.            #01       Zone 5 mail hour (01:00 - 02:00 UTC)
  588.            #02       Zone 2 mail hour (02:30 - 03:30 UTC)
  589.            #08       Zone 4 mail hour (08:00 - 09:00 UTC)
  590.            #09       Zone 1 mail hour (09:00 - 10:00 UTC)
  591.            #18       Zone 3 mail hour (18:00 - 19:00 UTC)
  592.            #20       Zone 6 mail hour (20:00 - 21:00 UTC)
  593.  
  594.                     NOTE:  When applicable,  the mail period flags may
  595.                     be strung together with no intervening commas, eg.
  596.                     "#02#09".  Only mail hours other than that
  597.                     standard within a node's zone should be given.
  598.                     Since observance of mail hour within one's zone is
  599.                     mandatory,  it should not be indicated.
  600.  
  601.   G: ISDN CAPABILTY FLAGS:
  602.  
  603.    Nodelist  Specification of minimal support required for this flag;
  604.    flag      any additional support to be arranged via agreement
  605.            between users
  606.  
  607.    V110L     ITU-T V.110 19k2 async ('low').
  608.    V110H     ITU-T V.110 38k4 async ('high').
  609.    V120L     ITU-T V.120 56k async, layer 2 framesize 259, window 7,
  610.              modulo 8.
  611.    V120H     ITU-T V.120 64k async, layer 2 framesize 259, window 7,
  612.              modulo 8.
  613.    X75       ITU-T X.75 SLP (single link procedure) with 64kbit/s B
  614.              channel; layer 2 max.framesize 2048, window 2, non-ext.
  615.              mode (modulo 8); layer 3 transparent (no packet layer).
  616.    ISDN      Other configurations. Use only if none of the above
  617.              fits.
  618.  
  619.    NOTE: No flag implies another. Each capability MUST be specifically
  620.        listed.
  621.    If no modem connects are supported, the nodelist speed field should
  622.    be 300.
  623.  
  624.    Conversion from old to new ISDN capability flags:
  625.      ISDNA -> V110L
  626.      ISDNB -> V110H
  627.      ISDNC -> X75
  628.  
  629.   H: INTERNET CAPABILITY FLAGS:
  630.  
  631.     FLAG   MEANING
  632.  
  633.     IBN - denotes a system that does BINKP
  634.     IFC - denotes a system that is capable of RAW or IFCICO
  635.     ITN - denote a system that does TELNET
  636.     IVM - denotes a system that is capable of VMODEM
  637.     IFT - denotes a system that allows FTP
  638.     ITX - denotes a system that uses TransX encoding for email
  639.           tunneling
  640.     IUC - denotes a system that uses UUEncode for email tunneling
  641.     IMI - denotes a system which uses MIME encoding for email
  642.           tunneling
  643.     ISE - denotes a system which supports SEAT receipts for anonymous
  644.           mail
  645.     IP  - denotes a system that can receive TCP/IP connects using a
  646.           protocol that is not covered by any other flag.
  647.     IEM - is a deprecated flag, and new implementations must not
  648.           write it in nodelist entries. This was used as a single
  649.           placeholder for the InterNet address of the system if it
  650.           supported several transport methods. Instead of placing
  651.           the system address in the deprecated form specified below
  652.           in each flag, the address would be placed once only in this
  653.           flag. Implementations may need to parse this information
  654.           from nodelists created with older programs.
  655.  
  656.   Conversion from old Internet capabilty flags to the new flags:
  657.  
  658.     BND -> IBN
  659.     TEL -> ITN
  660.     TELNET -> ITN
  661.     VMD -> IVM
  662.     TCP -> IP
  663.  
  664.   The Internet Address should be placed in the BBS name field.
  665.  
  666.   Previous usage has placed the InterNet address as part of the
  667.   I-flag (for example ITX:r10_tx@thevision.net); in this format the
  668.   flag, colon, and address combined cannot exceed 32 characters.
  669.   However, this practice is deprecated, and new implementations must
  670.   not place address data in the flag section of the nodelist entry,
  671.   implementations may however be required to read this data from the
  672.   flag section.
  673.  
  674.   Telnet default port is 23. If the port is not 23 then the port
  675.   number must be placed after the ITN flag (eg ITN:60177) if the
  676.   Telnet address is part of the ITN flag (eg ITN:farsi.dynip.com) then
  677.   the port number should be last (eg ITN:farsi.dynip.com:60177) always
  678.   remember that the flag cannot exceed 32 characters total.
  679.  
  680.   The default ports for other protocols are shown below, and changes
  681.   from the default port must be flagged in a similar way.
  682.  
  683.   Protocol      Flag    Default Port
  684.  
  685.   FTP           IFT     21
  686.   BINKP         IBN     24554
  687.   RAW/IFCICO    IFC     60179
  688.   VMODEM        IVM     3141
  689.  
  690.   Actual IP addresses can also be placed in the phone number field
  691.   using  the country code of 000.
  692.  
  693.   I: SYSTEM ONLINE USERFLAGS
  694.  
  695.    The flag Tyz is used by non-CM nodes online not only during ZMH,
  696.    y is a letter indicating the start and z a letter indicating the
  697.    end of the online period as defined below (times in UTC):
  698.  
  699.         A  0:00,  a  0:30,   B  1:00,  b  1:30,   C  2:00,  c  2:30,
  700.         D  3:00,  d  3:30,   E  4:00,  e  4:30,   F  5:00,  f  5:30,
  701.         G  6:00,  g  6:30,   H  7:00,  h  7:30,   I  8:00,  i  8:30,
  702.         J  9:00,  j  9:30,   K 10:00,  k 10:30,   L 11:00,  l 11:30,
  703.         M 12:00,  m 12:30,   N 13:00,  n 13:30,   O 14:00,  o 14:30,
  704.         P 15:00,  p 15:30,   Q 16:00,  q 16:30,   R 17:00,  r 17:30,
  705.         S 18:00,  s 18:30,   T 19:00,  t 19:30,   U 20:00,  u 20:30,
  706.         V 21:00,  v 21:30,   W 22:00,  w 22:30,   X 23:00,  x 23:30.
  707.  
  708.    For example TuB shows an online period from 20:30 until 1:00 UTC.
  709.  
  710.    Daylight saving time
  711.  
  712.    If a node changes online times with respect to UTC when daylight
  713.    saving time becomes effective (which would be the case with most
  714.    part time nodes), then this is to be taken into account when
  715.    assigning this flag. An online times flag assigned to a node should
  716.    not be altered for the specific purpose of adjusting due to
  717.    daylight saving time, since large difference files (NODEDIFF's)
  718.    would result if every node was allowed to do this, e.g. my node
  719.    used to be online from 2300 to 0800 in local time, which in winter
  720.    is UTC, but in the summer it becomes BST (British Summer Time).
  721.    This is one hour ahead of UTC, and the corresponding availability
  722.    times of my node during the summer period were 2200 to 0700 UTC.
  723.    Therefore my online times flag would have indicated availability
  724.    between the hours of 2300 and 0700 UTC, the daily time period
  725.    encompassing both times, so the flag would be TXH.
  726.  
  727. 2. Userflags
  728. ------------
  729.  
  730.   Registry of Userflags
  731.  
  732.   A. FORMAT OF USER FLAGS
  733.  
  734.      U,x..x
  735.                A user-specified string, which may contain any
  736.                alphanumeric character except blanks.  This string may
  737.                contain one to thirty-two characters of information
  738.                that may be used to add user-defined data to a specific
  739.                nodelist entry.  The character "U" must not be
  740.                repeated, eg, ",U,XXX,YYY,ZZZ" not ",U,XXX,U,YYY,UZZZ".
  741.                The 32 character limitation is per userflag, not for
  742.                the total of all userflags.
  743.  
  744.                New implementations must place a comma after the
  745.                initial "U" before the user flags. Some
  746.                implementations will not place a separating comma
  747.                betweent the "U" and the first user flag, but this
  748.                practice is deprecated. Implementations should be
  749.                prepared to read flags in this format, and must strip
  750.                the "U" from the flag before analysis in this case.
  751.  
  752.                Entries following the "U" flag must be of a technical
  753.                or administrative nature.  While experimentation of new
  754.                software functions using this flag is encouraged,
  755.                advertisement is strictly prohibited.
  756.  
  757.                For applications other than those shown, or if you
  758.                have questions concerning the use of this field, please
  759.                contact your Regional or Zone Coordinator.
  760.  
  761.  
  762.   B: MAIL ORIENTED USER FLAGS:
  763.  
  764.      ZEC       Zone EchoMail Coordinator. Not more than one entry
  765.                in the zone  segment may carry this flag and that entry
  766.                must be the current Zone EchoMail Coordinator.
  767.  
  768.      REC       Regional EchoMail Coordinator. Not more than one
  769.                entry in any region may carry this flag and that entry
  770.                must be the current Regional EchoMail Coordinator.
  771.  
  772.      NEC       Network EchoMail coordinator. Not more than one entry
  773.                in any net may carry this flag and that entry must be
  774.                the current Network EchoMail Coordinator of that Net.
  775.  
  776.  
  777.      SDS       Software Distribution System
  778.  
  779.      SMH       Secure Mail Hub
  780.  
  781.      NC        Network Coordinator. This flag is ONLY to be used by
  782.                the Network Coordinator of a net which has split the
  783.                duties of NC and Host and the NC does NOT occupy the
  784.                Net/0 position in the nodelist.
  785.  
  786.  
  787. A. Contact Data
  788. ---------------
  789.  
  790.   David Hallford
  791.   Fidonet: 1:208/103
  792.  
  793.   Andreas Klein
  794.   Fidonet: 2:2480/47
  795.   E-mail:  akx@gmx.net
  796.  
  797.   Michael McCabe
  798.   Fidonet: 1:297/11
  799.  
  800.   Odinn Sorensen
  801.   Fidonet: N/A
  802.   E-mail:  odinn@goldware.dk
  803.   WWW:     http://www.goldware.dk
  804.  
  805.   Colin Turner
  806.   Fidonet: 2:443/13
  807.   E-mail:  ct@piglets.com
  808.   WWW:     http://www.piglets.com
  809.  
  810.  
  811. B. History
  812. ----------
  813.  
  814.    Rev.1, 19990627: Initial Release. Principal Author David Hallford
  815.  
  816. --- BBBS/LiI v3.50 Flag-D
  817.  * Origin: Stronghold Enterprises/X - telnet://shx.tzo.net (111:111/0)
  818.  
  819.