      F I D O N E W S         Volume 17, Number 18             01 May 2000 
     +----------------------------+---------------------------------------+
     |  The newsletter of the     |   ISSN 1198-4589 Published by:        |
     |    FidoNet community       |   "FidoNews"                          |
     |          _                 |   1-717-732-6820     1:270/720        |
     |         /  \               |                                       |
     |        /|oo \              |                                       |
     |       (_|  /_)             |                                       |
     |        _`@/_ \    _        |                                       |
     |       |     | \   \\       |   Editor: Douglas Myers, 1:270/720    |
     |       | (*) |  \   ))      |           DougM@paonline.com          |
     |       |__U__| /  \//       |                                       |
     |        _//|| _\   /        |                                       |
     |       (_/(_|(____/         |                                       |
     |             (jm)           |   Newspapers should have no friends.  |
     |                            |                    -- JOSEPH PULITZER |
     +----------------------------+---------------------------------------+
     


                        Table of Contents
     1. HEADLINES  ................................................  1
     2. EDITORIAL  ................................................  2
        Where Are We Going?  ......................................  2
     3. ARTICLES  .................................................  3
        FTS-5000 Draft  ...........................................  3
        FTS-5001 Draft  ........................................... 12
     4. COLUMNS  .................................................. 25
        Ol'WDB: A Friend Told Me  ................................. 25
        This Weeks Web Page  ...................................... 27
     5. NET HUMOR  ................................................ 29
        Signs You're Getting Old  ................................. 29
     6. COMIX IN ASCII  ........................................... 31
        Remember These Famous Cows?  .............................. 31
     7. NOTICES  .................................................. 32
        Fidonews Editor Still Hangs in There :)  .................. 32
     8. INTERNET INFO  ............................................ 33
        Fidonet-related sites  .................................... 33
     9. FIDONEWS INFO  ............................................ 37
        Masthead  ................................................. 37
     FIDONEWS 17-18               Page 1                    1 May 2000


     =================================================================
                                 HEADLINES
     =================================================================


     This week's edition is larger than normal, mostly because of my
     decision to publish the FTSC material in it's entirety rather than
     stretching it across issues.  My apologies for the bulk, but I feel
     it's important to keep abreast of the way FTSC defines Fidonet.

     Of course, our old regulars are in here too :)


     -----------------------------------------------------------------

     FIDONEWS 17-18               Page 2                    1 May 2000


     =================================================================
                                 EDITORIAL
     =================================================================


                             Where Are We Going?
                                  Doug Myers

     Perhaps this week's editorial is in the same vein as last week's,
     but with a touch of yellow journalism.  I'm about to utter
     blasphemies which, perhaps, will bring the Fidonet Elders from their
     chambers tearing their robes from their chest.

     The BBS as we know it is a dying animal - it's not coming back in
     the old form we grew to know and love.  Why not?  Simply because
     we'll attract no users again - they'll log onto their ISP and play
     on the Internet even if they know about BBSes.  Why not?  The
     graphics are better than we ever dreamed about at the height of
     BBSing, the variety of activity is greater than we individual sysops
     could ever supply, and some areas such as e-business - which can
     transform lifestyle - were never even possible with BBSes.

     This means that Fidonet can't survive as it is presently structured
     - a network of sysops.  If we sysops can't attract users, then we'll
     have nothing to do and will eventually drift off... and our network
     will eventually whither.

     Oh, I'm not totally negative here - just trying to address
     realities.  What it all means is that we've got to redefine
     ourselves to continue on.  What we had was great - the sense of
     community in particular was never, in my humble opinion, never
     exceeded even by today's Internet.  We've got to find a new role for
     ourselves where we can function in the new paradigms.

     I don't have answers here, I can merely point out some directions.
     I'm hoping some of the readers can take these directions and make
     something of them (or possibly point out my errors).

     First of all, we've got to operate on the Internet in a new way.
     Our current efforts are good, in that they enable us to move mail
     and files which would probably be impossible if we tried to operate
     strictly through the conventional telephone system.  What we don't
     do much of right now is to attract new users in the way they are
     able to operate - with a plain old preconfigured WEB browser.
     Somehow we've got to create WEB sites with the taste and feel of the
     old BBSes, drawing at least a small group of users back time after
     time just for the sense of community.

     Can we do it?  I don't know.  How about you folks telling me?


     -----------------------------------------------------------------

     FIDONEWS 17-18               Page 3                    1 May 2000


     =================================================================
                                 ARTICLES
     =================================================================


                                FTS-5000 Draft

     This is the latest draft available to FIDONEWS of the Fidonet
     Technical Standards Committee document defining The Distribution
     Nodelist.  This copy was derived from a message by Colin Turner in
     the echo SYSOP.FTSC inviting public comment by May 15, 2000; and
     subsequently reported to FIDONEWS by Lesley-Dee Dylan (1:250/515).
     Though the period for public comment is over, and though this
     document is not in force yet, it and it's accompanying FTS-5001 are
     presented in their draft form as information of concern to all
     Fidonet Sysops.  Minor formatting changes were required to make this
     document fit the FIDONEWS format, but due care was exercised to make
     no editorial changes to the content.

     * note - proposed changes are marked by asterisks
     [ comments of Fino Lucrezi are included in square brackets ]


     *********************************************************************
     FTSC                            FIDONET TECHNICAL STANDARDS COMMITTEE
     *********************************************************************

     Publication:    FTS-5000 - REVIEW COPY - *NOT IN FORCE*
     Draft:          *Proposed* Revision 2
     Title:          THE DISTRIBUTION NODELIST
     Author(s):      Colin Turner, Andreas Klein, Michael McCabe,
                     David Hallford, Odinn Sorensen, Gino Lucrezi

     Draft Date:     22 April 2000
     ---------------------------------------------------------------------
     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
     * or copied for any purpose whatever.
     * Any modification should be clearly identified as such and called
     * with a different name

     FIDONEWS 17-18               Page 4                    1 May 2000


     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 separated
       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).


     * Unlike most FTSC documents, this one is not only aimed at
     * developers, but also at maintainers of Fidonet (and other Fidonet
     * Technology Networks) nodelist segments. While nodelist segment
     * maintainers should try to be quite strict in their adherence to
     * this document, it is recommended that software developers be
     * prepared to accept deviations from this standard, especially with
     * regard to field and line size.



      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
     *       L = .lzh

       Since .zip is usable on most computer platforms, it is recommended
       that this format be used for distribution of the Distribution
     FIDONEWS 17-18               Page 5                    1 May 2000


       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 white-space (spaces, tabs, etc.) at all.
       The file is terminated with an end-of-file character, ASCII <EOF>
       (1AH).
     * Except for the above, no control characters (ASCII 0-31) should be
     * used in the nodelist.

     * Each line shouldn't exceed 157 characters. However, it is
     * recommended that software developers be quite liberal, and accept
     * unlimited-lenght strings.

       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

     * Please note that the above line has been split in the sole interest
     * of readability. It should appear on just one line.

     * This line contains the general interest flag, the week day, full
     * date, the 3-digit day-of-year number (also called "Julian date")
     * of publication, and ends with a 5-digit decimal check value. The
     * Julian date and check value are padded with leading zeros, if
     * necessary.
     FIDONEWS 17-18               Page 6                    1 May 2000


     * The check value is 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 first line will certainly be different from the above in the
     * case of nodelist segments for individual zones, regions, networks
     * or hubs; it will also be different for other Fidonet Technology
     * Networks.

     * Except for the day number and the CRC, developers shouldn't make
     * any assumption on the format of this line. The suggested parsing
     * algorithm is to find the last colon in the line, and then scan
     * backwards to get the day of issue.

       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
     FIDONEWS 17-18               Page 7                    1 May 2000


               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. They are also
     *         considered part of a network whose number is the same as
     *         the region number.

          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.

          Pvt --
               Defines a private node with unlisted number. Private nodes
               are only allowed as members of local networks.

          Hold --
              Defines a node which is operational but can't be reached
              with a dial-up connection. Mail can be sent to it in care
              of its host or coordinator, who will hold it for that node.

          Down --
               Defines a node which is not operational. Mail may NOT be
               sent to it.

     [ I removed the two-week limit on being down before removal; I
     believe it to be a policy issue, not an FTSC one]

          <empty> --
               Defines a normal node entry.

     *    Administrative entries (those with a Zone, Region, Host or Hub
     *    keyword) MUST be redundant entries for one of the nodes listed
     *    below them.

     *    No other content is possible for this field in the master
     *    Fidonet nodelist; however, private listings can conceivably
     *    include other kind of entries, by marking them appropriately in
     *    this field. It is recommended that software parsing nodelists
     *    ignore any line which has an unknown keyword in this field.

     *    One such example is the "Point" keyword. It can be used in
     *    so-called "pointlists" to include entries describing points of
     *    the Fidonet node immediately preceding. This keyword should
     *    never be used in the Fidonet nodelist, but it is recommended
     *    that nodelist parsers recognize it.


       Field 2 - Zone/Region/Net/Node number
     FIDONEWS 17-18               Page 8                    1 May 2000


          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 unique within
     *    their net. The hub number will be treated like an extra node in
     *    its local network. 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.

     *    If the entry is marked by a "Point" keyword in the first field,
     *    this field contains the point number. The address of the "boss"
     *    node is that of the last regular node entry preceding the point.


       Field 3 - Node name

          This field may contain any alphanumeric character other than
     *    commas and spaces. This is the name by which the node is known.
     *    For IP nodes this field may alternately contain a numeric IP
     *    address or E-Mail address for email tunneling programs.

       Field 4 - Location

          This field may contain any alphanumeric character 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 two or more numeric subfields separated by
     *    dashes (-). The first field is the country code. The rest of the
     *    phone number should be formatted according to local customs.

          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),
     FIDONEWS 17-18               Page 9                    1 May 2000


     *    area 800 (area code), exchange 555, and number 1212.

     *    Alternatively, in the case of a private node, this field may
     *    contain the notation -Unpublished-. In this case, the keyword
          "Pvt" must appear on the line.

     *    If a nodelist uses "Point" keywords, such entries can also have
     *    "-Unpublished-" in this field (and will do so almost always).

     *    This field may also contain the IP address of an IP node
     *    utilizing the country code of 000. This should only be done in
     *    exceptional circumstances, since it is almost always better to
     *    list a fully qualified domain name instead of a numeric IP
     *    address, which could become obsolete in a matter of hours.


       Field 7: Obsolete

     *    In the past, this field was used to show the maximum modem speed
     *    supported by the node.

     *    However, given the number of competing (and incompatible)
     *    protocols available having the same speed, this function was
     *    later taken over by modem flags. Today, this field carries no
     *    relevant information, and is ignored by most software, with
     *    only one exception. If the node has no analog modem available
     *    on this line (it is either ISDN-only or IP-only) then it must
     *    use a value of 300 in this field. If there is an analog modem
     *    on this line, the value of 9600 is strongly recommended for
     *    maximum compatibility.

     *    Values other than 300, 1200, 2400 and 9600 (historically
     *    accepted by any program) have to be approved by the ZCC before
     *    being used.

     *    However, it is recommended that developers accept any 16 bit
     *    unsigned integer value.


       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.

     *    Each subfield should be long at most 32 characters. It is
     *    however recommended that software developers recognize and
     *    process even fields which are longer than this limit.

          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.
     FIDONEWS 17-18               Page 10                   1 May 2000


          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
     -----------

     * 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:

               <command><number>

          <command> is a 1-letter command; A, C, or D. <number> 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.

     FIDONEWS 17-18               Page 11                   1 May 2000


          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
     *       L = .lzh

       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.

     FIDONEWS 17-18               Page 12                   1 May 2000


       [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
        Rev.2  20000424: 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


     -----------------------------------------------------------------


                                FTS-5001 Draft

     This artical accompanies the previous one on FTS-5000.  The same
     FIDONEWS 17-18               Page 13                   1 May 2000


     preliminary notes apply.

     *********************************************************************
     FTSC                            FIDONET TECHNICAL STANDARDS COMMITTEE
     *********************************************************************

     Publication:    FTS-5001 - REVIEW COPY - *NOT IN FORCE*
     Draft:          *Proposed* Revision 2
     Title:          NODELIST FLAGS AND USERFLAGS
     Author(s):      Colin Turner, Michael McCabe, David Hallford, Odinn
                     Sorensen, Gino Lucrezi

     Draft Date:     22 April 2000
     ---------------------------------------------------------------------
     Contents:
                     1. Authorized Flags
                     2. Userflags
     ---------------------------------------------------------------------

     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
     * or copied for any purpose whatever.
     * Any modification should be clearly identified as such and named
     * differently.


     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. Flags are used in this
       nodelist to aid automatic and manual control of various tasks.


     1. Authorized flags
     -------------------

      Flags authorized for use in the Fidonet nodelist:

       A: OPERATING CONDITION FLAGS:

               Flag      Meaning

               CM        Node accepts mail 24 hours a day
               MO        Node does not accept human callers
               LO        Node accepts calls Only from Listed
                         FidoNet addresses
     *         MN        No packet compression supported
     FIDONEWS 17-18               Page 14                   1 May 2000


     * B. MODEM CONNECTION PROTOCOL FLAGS:
          The following flags define modem connection protocols supported.
     *    Please also read section I on flag redundancies.

     [ I standardized entries format, and added speeds wherever I could ]

     *    ITU-T (formerly CCITT) Protocols:

               Flag      Meaning

     *         V21       ITU-T V.21             300 bps  full duplex
     *         V22       ITU-T V.22           1.200 bps  full duplex
     *         V29       ITU-T V.29           9.600 bps  half duplex
     *         V32       ITU-T V.32           9.600 bps  full duplex
     *         V32b      ITU-T V.32bis       14.400 bps  full duplex
     *         V33       ITU-T V.33
     *         V34       ITU-T V.34          28.800 bps  full duplex
     *                   (this flag also covers so-called V.34+,
     *                   capable of 33.600 bps)
     *         V90C      ITU-T V.90 Client   56.000 bps  asymmetric
     *         V90S      ITU-T V.90 Server   56.000 bps  asymmetric


     *     Industry standard protocols:

     *         Flag      Meaning

     *         V32T      V.32 Terbo          28.800 bps
     *         VFC       V.Fast Class        28.800 bps


     *      Proprietary Protocols:

     *         Flag      Meaning

     *         HST       USR Courier HST          9.600 bps  asymmetric
     *         H14       USR Courier HST         14.400 bps  asymmetric
     *         H16       USR Courier HST         16.800 bps  asymmetric
     *         X2C       US Robotics x2 client   56.000 bps  asymmetric
     *         X2S       US Robotics x2 server   56.000 bps  asymmetric
     *         ZYX       Zyxel                   16.800 bps
     *         Z19       Zyxel                   19,200 bps
     *         H96       Hayes V9600              9.600 bps
               MAX       Microcom AX/96xx series
               PEP       Packet Ensemble Protocol
     *         CSP       Compucom Speedmodem


     * C: SESSION LEVEL ERROR-CORRECTION AND COMPRESSION FLAGS:

     *    The following flags define type of error correction and/or data
     *    compression available. A separate error correction flag should
     *    not be used when the error correction type can be determined by
     *    the modem flag. See section I for details.

               Flag      Meaning
     FIDONEWS 17-18               Page 15                   1 May 2000


               MNP       Microcom Networking Protocol error correction
                         of type MNP1 to MNP4
     *         V42       ITU-T V.42: LAP-M error correction with fallback
     *                   to MNP 1-4
     *         V42b      ITU-T V.42bis: LAP-M error correction and
     *                   compression with fallback to MNP 1-5



       D: FILE/UPDATE REQUEST FLAGS:

          The following flags indicate the types of file/update requests
          supported.

       +--------------------------------------------------+
       |      |         Bark        |        WaZOO        |
       |      |---------------------|---------------------|
       |      |   File   |  Update  |   File   |  Update  |
       | Flag | Requests | Requests | Requests | Requests |
       |------|----------|----------|----------|----------|
       | XA   |    Yes   |    Yes   |    Yes   |    Yes   |
       | XB   |    Yes   |    Yes   |    Yes   |    No    |
       | XC   |    Yes   |    No    |    Yes   |    Yes   |
       | XP   |    Yes   |    Yes   |    No    |    No    |
       | XR   |    Yes   |    No    |    Yes   |    No    |
       | XW   |    No    |    No    |    Yes   |    No    |
       | XX   |    No    |    No    |    Yes   |    Yes   |
     * | none |    No    |    No    |    No    |    No    |
       +--------------------------------------------------+

     * The following software is qualified to
     * use the appropriate file request flag
     * according to information provided by
     * developers:
     *
     * +-----------------------------------+
     * | Flag      Software Package        |
     * |-----------------------------------|
     * |  XA  Frontdoor   1.99b and lower  |
     * |      Frontdoor   2.01  and higher |
     * |      Dutchie     2.90c            |
     * |      Binkleyterm 2.1   and higher |
     * |      D'Bridge    1.2   and lower  |
     * |      Melmail                      |
     * |      TIMS                         |
     * |-----------------------------------|
     * |  XB  Binkleyterm 2.0              |
     * |      Dutchie     2.90b            |
     * |-----------------------------------|
     * |  XC  Opus        1.1              |
     * |-----------------------------------|
     * |  XP  Seadog                       |
     * |-----------------------------------|
     * |  XR  Opus        1.03             |
     * |      Platinum Xpress              |
     * |-----------------------------------|
     FIDONEWS 17-18               Page 16                   1 May 2000


     * |  XW  Fido        12N   and higher |
     * |      Tabby                        |
     * |      TrapDoor  No update processor|
     * |-----------------------------------|
     * |  XX  Argus       2.00  and higher |
     * |      D'Bridge    1.30  and higher |
     * |      Frontdoor   1.99c/2.00       |
     * |      InterMail   2.01             |
     * |      McMail      1.00             |
     * |      T-Mail                       |
     * |      TrapDoor - Update Processor  |
     * |-----------------------------------|
     * |  None       QMM                   |
     * +-----------------------------------+


       E: GATEWAY FLAG:

          The following flag defines gateways to other domains (networks).

               Flag      Meaning

               Gx..x     Gateway to domain 'x..x', where 'x..x` is a string
                         of alphanumeric characters. Valid values for
                         'x..x' are assigned by the FidoNet International
     *                   Coordinator or the Zone Coordinators Council. They
     *                   will also adequately distribute a list of valid
     *                   values.


       F: MAIL PERIOD FLAGS:
          The following flags define the dedicated mail periods supported.
          They have the form "#nn" or !nn where nn is the UTC hour the mail
          period begins, # indicates Bell 212A compatibility, and !
          indicates incompatibility with Bell 212A.

                Flag      Meaning

                #01       Zone 5 mail hour (01:00 - 02:00 UTC)
                #02       Zone 2 mail hour (02:30 - 03:30 UTC)
                #08       Zone 4 mail hour (08:00 - 09:00 UTC)
                #09       Zone 1 mail hour (09:00 - 10:00 UTC)
     *          #17       Zone 3 mail hour (17:00 - 18:00 UTC)
                #20       Zone 6 mail hour (20:00 - 21:00 UTC)

          The above listing of the ZMH for each individual zone is only
          given for your convenience. It was correct at the time of this
          writing, but could be changed at any time by following the
          procedures established in Fidonet policy. The FTSC has no role
          in determining the Mail Hour of any Zone. You'll find an
          up-to-date list in the comments at the end of the Fidonet
          Nodelist.

          NOTE:  When applicable, the mail period flags may be strung
          together with no intervening commas, eg. "#02#09". Only mail
          hours other than that standard within a node's zone should be
     FIDONEWS 17-18               Page 17                   1 May 2000


          given. Since observance of mail hour within one's zone is
          mandatory, it should not be indicated.

     *    If one node wishes to advertise a much larger mail period, use
     *    of the T?? flag is recommended, as described in part 2, section
     *    C.


       G: ISDN CAPABILTY FLAGS:

        Nodelist  Specification of minimal support required for this flag;
        flag      any additional support to be arranged via agreement
                  between users

        V110L     ITU-T V.110 19k2 async ('low').
        V110H     ITU-T V.110 38k4 async ('high').
        V120L     ITU-T V.120 56k async, layer 2 framesize 259, window 7,
                  modulo 8.
        V120H     ITU-T V.120 64k async, layer 2 framesize 259, window 7,
                  modulo 8.
        X75       ITU-T X.75 SLP (single link procedure) with 64kbit/s B
                  channel; layer 2 max.framesize 2048, window 2, non-ext.
                  mode (modulo 8); layer 3 transparent (no packet layer).
        ISDN      Other configurations. Use only if none of the above
                  fits.

        NOTE: No flag implies another. Each capability MUST be specifically
            listed.
     *  If no analog modem connects are supported, the nodelist speed field
        should be 300.

        Conversion from old to new ISDN capability flags:
          ISDNA -> V110L
          ISDNB -> V110H
          ISDNC -> X75


       H: INTERNET CAPABILITY FLAGS:

     [this is an almost complete rewrite: all lines are to be considered
     prefixed by *]

         Several different protocols are available to exchange Fidonet
         Mail over the Internet, and they are denoted by the following
         flags:

                               Direct Connectivity

         Flag   Protocol

         IBN    BINKP (FSP-1011)
         IFC    RAW protocol as used by ifcico or compatible programs
         ITN    FTS-0001 over TELNET connection
         IVM    FTS-0001 over VMODEM connection
         IP     can receive TCP/IP connects using some protocol not
                covered by above flags; see later for another use of this
     FIDONEWS 17-18               Page 18                   1 May 2000


                flag

                              Indirect Connectivity

         Flag   Protocol

         IFT    Packet exchange via FTP
         ITX    TransX encoding for email tunneling with receipts enabled
         IUC    uuencoding of mail bundles
         IMI    MIME encoding of mail bundles
         ISE    SEAT protocol for Email tunneling with receipts enabled;
                should always be accompanied by IUC and/or IMI
         IEM    other mail tunneling methods not covered by above flags;
                see later for another use of this flag

          Direct connectivity means that both parties to the mail
          exchange must be connected to the internet at the same time,
          and communicate in real time. Such a connection is analogous to
          a crash-mail connection between two fidonet nodes. Indirect
          connectivity protocols require the use of one or more systems
          storing information to pass it to a fidonet system. This kind
          of connection is analogous to routed mail.

          To use any direct connectivity flag, a node must at least be
          able to process inbound calls with that protocol during ZMH.
          Nodes also listing flags denoting additional online times (CM,
          Tyz, !nn and #nn) must also support that protocol during these
          additional times.

          To use any indirect connectivity flag, a node must connect to
          its Internet provider at least once a day.

          [Tobias would like to add a requirement for CM nodes to poll
          their ISP every hour]

          To use the flag for any Email method providing for return
          receipts (currently ITX and ISE) a node *must* have them
          enabled and send such receipts within 24 hours of receiving a
          file.

          It should be noted that only some of these Internet based
          methods (currently IBN, IFC, ITN, IVM, ITX and ISE) can give
          the sender a proof of receipt of a file by the addressee, like
          FTS-0001 does. Other methods have no guarantee of reliability,
          so they shouldn't be used to transmit critical data.

          Also, nodelist segment maintainers should take into account the
          presence of at least one of these reliable protocols when
          deciding on application for Fidonet membership by nodes without
          a dial-up connection.

          While to set up a FTS-0001 connection you only need to know the
          phone number to call, for an internet connection you'll need
          some more information.

          When using a direct connectivity protocol (flags IBN, IFC, ITN,
     FIDONEWS 17-18               Page 19                   1 May 2000


          IVM) or FTP (flag IFT) a node needs to identify the Internet
          host to connect to. This requires a FQDN (Fully Qualified
          Domain Name) and a port number.

          This can be specified using the following format:

          <flag>[:<fqdn>][:<port#>]

          If the port number is not specified, the following defaults are
          assumed:

               Protocol      Flag    Default Port

               BINKP         IBN     24554
               RAW/IFCICO    IFC     60179
               TELNET        ITN     23
               VMODEM        IVM     3141
               FTP           IFT     21

          If a node supports more than one protocol on the same internet
          host (thus using the same FQDN), the FQDN should only be listed
          once. In this case, the IP flag should be added to the nodelist
          entry (even if it wouldn't be needed otherwise), with the
          following syntax: IP:<fqdn>

          Please note the 32 characters limit on any flag.

          As an alternative, the FQDN can be placed in the "Node Name"
          field of the nodelist entry.

          In general it is better to list a FQDN in the nodelist, and
          leave to a DNS (Domain Name Server) the task of "resolving" it,
          i.e. translating it to a numeric IP address. However, in some
          particular situations it could be preferable to list directly
          the IP address. This should only be done with full knowledge of
          the possible problems involved. In such cases, the IP address
          shouldn't be placed in the flags field, but in the "Node Name"
          field. Another possibility (though deprecated in some
          countries) is to put it in the "Phone Number" field, prefixed
          by a country code of 000 (reserved by ITU-T, and unlikely to be
          assigned to any country in the near future), with dashes ("-")
          replacing dots ("."). An IP address should never be placed in
          the flags section, where it could be misinterpred as a port
          number.

          Email-based transport methods (ITX, IUC, IMI, ISE, IEM) need
          knowledge of an Email address, in the form <username>@<fqdn>.
          So, each of these flags has the syntax:
          <flag>[:<username>@<fqdn>]
          If the same Email addess is used for more than one protocol,
          then it should only be listed once. In this case, the IEM flag
          should be used (even if it wouldn't be needed otherwise), and
          the Email addess should only be stated after this flag.

          Some programs can parse Email addresses in the "Node Name"
          field. This, however, conflicts with the use of it for holding
     FIDONEWS 17-18               Page 20                   1 May 2000


          an IP address.

          The following flags were used in the past. Please note their
          "modern" equivalent, and use it in their place:

                 Old       New

                 BND    -> IBN
                 TEL    -> ITN
                 TELNET -> ITN
                 VMD    -> IVM
                 TCP    -> IP


     * I: FLAG REDUNDANCIES

     [All the section is new, and should be considered prefixed by * ]

        Only the smallest possible set of flags should be used in each
        entry.

        Since different people might have different perception of modem
        flag redundancies, the FTSC decided to provide a standard table.

        The relation "implies" means either that the first protocol
        requires all the others as a fallback or that to all practical
        purposes all modems which have been manufactured until today (and
        conceivably even future ones) implemented the other protocols
        anyway.

        For example, the protocol V.32bis implies V.32 because it's
        required as a fallback; on the other hand, V.32Terbo implies
        V.32bis because practically all modems with V.32Terbo also had
        V.32bis to connect to existing modems, even though it wasn't
        required in the protocol specifications.

        V32   implies  V22
        V32B  implies  V22 V32
        V34   implies  V22 V32 V32B
        V90C  implies  V22 V32 V32B V34
        V90S  implies  V22 V32 V32B V34

        V42   implies  MNP
        V42B  implies  V42 MNP

        V32T  implies  V22 V32 V32B
        VFC   implies  V22 V32 V32B

        HST   implies  MNP
        H14   implies  HST MNP
        H16   implies  HST H14 MNP V42 V42B

        X2C   implies  V22 V32 V32B V34
        X2S   implies  V22 V32 V32B V34

        ZYX   implies  V22 V32 V32B V42 V42B MNP
     FIDONEWS 17-18               Page 21                   1 May 2000


        Z19   implies  V22 V32 V32B V42 V42B MNP ZYX

        Please note also that:
        . V21 may or may not be supported by modems using higher ITU-T
          protocols, so it is never implied; however, this flag is not
          really useful, either, so it should only be used if there is a
          strong reason to expressely denote such a compatibility;
        . the V90C and V90S flags are mutually exclusive;
        . the X2C and X2CS flasg are are mutually exclusive;
        . no modem has at the same time the US Robotics proprietary
          protocols and the ZyXEL ones; so, use of any flag in the group
          HST, H14, H16, X2S and X2C is incompatible with any of the ZYX
          and Z19 flags, and vice versa.
        . all X? flags are mutually exclusive;
        . the #??, !??, T?? and CM flags are incompatible with each
          other.

     2. Userflags
     ------------

       Registry of Userflags

          It is impossible to document all user flags in use. The FTSC
          makes no attempt at it. This document lists those flags which
          got at least some kind of official sanction or were deemed of
          technical interest by FTSC.


       A. FORMAT OF USER FLAGS

          U,x..x
                    A user-specified string, which may contain any
                    alphanumeric character except blanks. This string may
                    contain one to thirty-two characters of information
                    that may be used to add user-defined data to a
                    specific nodelist entry. The character "U" must not
                    be repeated, eg, ",U,XXX,YYY,ZZZ" not
                    ",U,XXX,U,YYY,UZZZ". The 32 character limitation is
                    per userflag, not for the total of all userflags.

                    New implementations must place a comma after the
                    initial "U" before the user flags. Some
                    implementations will not place a separating comma
                    betweent the "U" and the first user flag, but this
                    practice is deprecated. Implementations should be
                    prepared to read flags in this format, and must strip
                    the "U" from the flag before analysis in this case.

                    Entries following the "U" flag must be of a technical
                    or administrative nature. While experimentation of
                    new software functions using this flag is encouraged,
                    advertisement is strictly prohibited.

                    For applications other than those shown, or if you
                    have questions concerning the use of this field,
                    please contact your Regional or Zone Coordinator.
     FIDONEWS 17-18               Page 22                   1 May 2000


     *              Developers should note that the distinction between
     *              "normal" flags and user flags is a non-technical,
     *              purely political one. It often happened that a user
     *              flag was "promoted" to regular status, and the
     *              reverse could conceivably happen. It is recommended
     *              that, while parsing nodelist entries, no distinction
     *              at all be done between the two categories of flags.


       B: MAIL ORIENTED USER FLAGS:

          ZEC       Zone EchoMail Coordinator. Not more than one entry in
                    the zone  segment may carry this flag and that entry
                    must be the current Zone EchoMail Coordinator.

          REC       Regional EchoMail Coordinator. Not more than one
                    entry in any region may carry this flag and that
                    entry must be the current Regional EchoMail
                    Coordinator.

          NEC       Network EchoMail coordinator. Not more than one entry
                    in any net may carry this flag and that entry must be
                    the current Network EchoMail Coordinator of that Net.

          NC        Network Coordinator. This flag is ONLY to be used by
                    the Network Coordinator of a net which has split the
                    duties of NC and Host and the NC does NOT occupy the
                    Net/0 position in the nodelist.


          SDS       Software Distribution System

     *    SMH       Secure Mail Hub - or one of the following variations,
     *              indication the specific level of the hub:

     *               NSMH - Net SecureMail Host - only one per net
     *               RSMH - Region SecureMail Host - only one per region
     *               ZSMH - Zone SecureMail Host - only one in Zone 1
     *               ISMH - International SecureMail Host - only one in
                            Fidonet


     *    RPK       Regional Pointlist Keeper.
     *              This user-flag identifies the person who compiles the
     *              region-pointlist (only 1 entry per region allowed)

     *    NPK       Net Pointlist Keeper.
     *              This user-flag identifies the person who compiles the
     *              net-pointlist (only 1 entry per net allowed)


     *    K12       This flag identifies systems offering the full range of
     *              educational K12-conferences.

     *    ENC       This node accepts inbound encrypted mail and will route
     *              it like other mail
     FIDONEWS 17-18               Page 23                   1 May 2000


     *    CDP       This node will accept points auto-created by the
     *              CD-point software.


     * C: SYSTEM ONLINE USERFLAGS

     [This section was relocated between user flags]

        The flag Tyz is used by non-CM nodes online not only during ZMH,
        y is a letter indicating the start and z a letter indicating the
        end of the online period as defined below (times in UTC):

             A  0:00,  a  0:30,   B  1:00,  b  1:30,   C  2:00,  c  2:30,
             D  3:00,  d  3:30,   E  4:00,  e  4:30,   F  5:00,  f  5:30,
             G  6:00,  g  6:30,   H  7:00,  h  7:30,   I  8:00,  i  8:30,
             J  9:00,  j  9:30,   K 10:00,  k 10:30,   L 11:00,  l 11:30,
             M 12:00,  m 12:30,   N 13:00,  n 13:30,   O 14:00,  o 14:30,
             P 15:00,  p 15:30,   Q 16:00,  q 16:30,   R 17:00,  r 17:30,
             S 18:00,  s 18:30,   T 19:00,  t 19:30,   U 20:00,  u 20:30,
             V 21:00,  v 21:30,   W 22:00,  w 22:30,   X 23:00,  x 23:30.

        For example TuB shows an online period from 20:30 until 1:00 UTC.

        Daylight saving time

        If a node changes online times with respect to UTC when daylight
        saving time becomes effective (which would be the case with most
        part time nodes), then this is to be taken into account when
        assigning this flag. An online times flag assigned to a node
        should not be altered for the specific purpose of adjusting due
        to daylight saving time, since large difference files
        (NODEDIFF's) would result if every node was allowed to do this,
        e.g. my node used to be online from 2300 to 0800 in local time,
        which in winter is UTC, but in the summer it becomes BST (British
        Summer Time). This is one hour ahead of UTC, and the
        corresponding availability times of my node during the summer
        period were 2200 to 0700 UTC. Therefore my online times flag
        would have indicated availability between the hours of 2300 and
        0700 UTC, the daily time period encompassing both times, so the
        flag would be TXH.


     A. Contact Data
     ---------------

       David Hallford
       Fidonet: 1:208/103

       Michael McCabe
       Fidonet: 1:297/11

       Odinn Sorensen
       Fidonet: N/A
       E-mail:  odinn@goldware.dk
       WWW:     http://www.goldware.dk

     FIDONEWS 17-18               Page 24                   1 May 2000


       Colin Turner
       Fidonet: 2:443/13
       E-mail:  ct@piglets.com
       WWW:     http://www.piglets.com

       Gino Lucrezi
       Fidonet: 2:335/610
       E-Mail:  gino.lucrezi@ftsc.org

     B. History
     ----------

        Rev.1, 19990627: Initial Release. Principal Author David Hallford

        Rev.2, 20000422: new draft by Gino Lucrezi; major changes:
                         - reorganization of flags classification
                         - rewrite for clarification of internet connection
                           flags
                         - note on difference between "regular" and "user"
                           flags
                         - description of flag redundancies
                         new draft by Gino Lucrezi with input from others
                         - removed Andreas Klein from authors
                         - ENC flag
                         - distinction of direct and indirect IP
                           connectivity
                         - requirement for return recepits with ITX and ISE
                         - additional requirement for IP-nodes with CM flag
                         - clarification on some flag redundancies
                         new draft by Gino Lucrezi with input from others
                         - corrected Z3MH and added note on changing of
                           ZMHs


     -----------------------------------------------------------------

     FIDONEWS 17-18               Page 25                   1 May 2000


     =================================================================
                                  COLUMNS
     =================================================================


                               Ol'WDB's Column
                             A Friend Told Me...
                             wdbonner@pacbell.net

     When I was quite young, my father had one of the first telephones in
     our neighborhood.  I remember well, the polished, old case fastened
     to the wall and shiny receiver on the side of the box.

     I was too little to reach the telephone, but used to listen with
     fascination when my mother used to talk to it.  Then I discovered
     that somewhere inside the wonderful device lived an amazing person -
     her name was "Information Please" and there was nothing she did not
     know.

     "Information Please" could supply anybody's number and the correct
     time.  My first personal experience with this genie-in-the-bottle
     came one day while my mother was visiting a neighbor.  Amusing
     myself at the tool bench in the basement. I whacked my finger with a
     hammer.  The pain was terrible, but there didn't seem to be any
     reason in crying because there was no one home to give sympathy.  I
     walked around the house sucking my throbbing finger, finally
     arriving at the stairway. The telephone!  Quickly, I ran for the
     footstool in the parlor and dragged it to the landing.  Climbing up,
     I unhooked the receiver in the parlor and held it to my ear.

     "Information Please," I said into the mouthpiece just above my head.
     A click or two and a small clear voice spoke into my ear.

     "Information"

     "I hurt my finger." I wailed into the phone.  The tears came readily
     enough now that I had an audience.

     "Isn't your mother home?" came the question.

     Nobody's home but me," I blubbered.

     "Are you bleeding?" the voice asked.

     "No," I replied.  "I hit my finger with the hammer and it HURTS!

     "Can you open your icebox?" she asked.  I said I could. "Then take
     an ice cube and hold it to your finger," said the voice.

     After that, I called "Information Please" for everything.  I asked
     her for help with my geography and she told me where Philadelphia
     was.  She helped me with my math.  She told me my pet chipmunk, that
     I had caught in the park just the day before, would eat fruit and
     nuts.

     Then, there was the time Petey, our pet canary died. I called
     FIDONEWS 17-18               Page 26                   1 May 2000


     "Information Please" and told her the sad story. She listened, then
     said the usual things grown ups say to soothe a child.

     But I was un-consoled.  I asked her, "Why is it that birds should
     sing so beautifully and bring joy to all families, only to end up as
     a heap of feathers on the bottom of a cage?"

     She must have sensed my deep concern, for she said quietly, "Paul,
     always remember that there are other worlds to sing in."

     Somehow I felt better.

     Another day I was on the telephone.  "Information Please."
     "Information," said the now familiar voice.

     "How do you spell fix?" I asked.

     All this took place in a small town in the Pacific northwest.  When
     I was nine years old, we moved across the country to Boston. I
     missed my friend very much.  "Information Please" belonged in that
     old wooden box back home and I somehow never thought of trying the
     tall, shiny new phone that sat on the table in the hall. As I grew
     into my teens, the memories of those childhood conversations never
     really left me.  Often, in moments of doubt and perplexity I would
     recall the serene sense of security I had then.  I appreciated now
     how patient, understanding and kind she was to have spent her time
     on a little boy.

     A few years later, on my way west to college, my plane put down in
     Seattle.  I had about half-an-hour or so between planes. I spent 15
     minutes or so on the phone with my sister, who lived there now.
     Then, without thinking what I was doing, I dialed my hometown
     operator and said, "Information, please."

     Miraculously, I heard the small, clear voice I knew so well.

     "Information."

     I hadn't planned this, but I heard myself saying, "Could you please
     tell me how to spell fix?"

     There was a long pause.  Then came the soft spoken answer, "I guess
     your finger must have healed by now."

     I laughed, "So it's really still you," I said.  "I wonder if you
     have any idea how much you meant to me during that time."

     "I wonder," she said, "if you know how much your calls meant to me.
     I never had any children and I used to look forward to your calls."

     I told her how often I had thought of her over the years and I asked
     if I could call her again when I came back to visit my sister.

     "Please do," she said.  "Just ask for Sally."

     Three months later I was back in Seattle.  A different voice
     FIDONEWS 17-18               Page 27                   1 May 2000


     answered, "Information."

     I asked for Sally.  "Are you a friend?" she asked.

     "Yes, I'm Paul, a very old friend," I answered.

     "I'm sorry to have to tell you this," she said.

     "Sally had been working part time the last few years because she was
     sick.  She died five weeks ago."

     Before I could hang up she said, "Wait a minute.  Did you say your
     name was Paul?"

     "Yes."

     "Well, Sally left a message for you.  She wrote it down in case you
     called.  Let me read it to you." The note said, "Tell him I still
     say there are other worlds to sing in.  He'll know what I mean."

     I thanked her and hung up. I know what Sally meant.

                                  **********

     Never underestimate the impression you may make on others, two years
     to nineteen...even beyond that age.... I hope I have touched your
     life today, even though these were the words of a friend, to a
     friend who sent them to me.


     -----------------------------------------------------------------


                             This Weeks Web Page
                                by Frank Vest
                                1:124/6308(.1)

     This weeks page is the NET103 site.

     Where: http://www.webworldinc.com/club103/

     Unusual thing is that this page doesn't have a header announcing
     that it is the Net103 page. It does have a nice graphic that shows
     the world with an animated connection to the main Net feed and
     distribution to the Hubs in the Net.

     Under this is are several links to pages and sites. If you want to
     see what Joe Jared's page looks like, there's a link to it. :) Most
     of the links are to pages telling about the various BBS' in the Net,
     but there is a Telnet link to Joe's BBS. Where he got the name for
     his BBS must be a good story. :-))

     Under the list of links are three links. They give information and
     credits. There's also the E-Mail to the Webmaster.

     All in all, this is a simple site. Not a lot of stuff on it, but it
     FIDONEWS 17-18               Page 28                   1 May 2000


     does have information and links. The Telnet is nice and was actually
     not real slow.

     If you live in the Net103 area, drop by. If you don't live in the
     area, drop in anyway and say hi. Telnet in and mess around or check
     out the links.

     Till next week,

      Frank
      flv@texoma.net


     -----------------------------------------------------------------

     FIDONEWS 17-18               Page 29                   1 May 2000


     =================================================================
                                 NET HUMOR
     =================================================================


                           Signs You're Getting Old
                            Thanks to Old Roy Reed

     1. You're asleep, but others worry that you're dead.

     2. Your back goes out more than you do.

     3. You quit trying to hold your stomach in, no matter who walks into
     the room.

     4. You buy a compass for the dash of your car/truck.

     5. You are proud of your lawn mower

     6. Your best friend is dating someone half their age, and isn't
     breaking any laws.

     7. Your arms are almost too short to read the newspaper.

     8. You sing along with the elevator music.

     9. You would rather go to work than stay home sick.

     10. You enjoy hearing about other people's operations.

     11. You no longer think of speed limits as a challenge.

     12. People call at 9:00 p.m. and ask, "Did I wake you?"

     13. You answer a question with, "Because I said so."

     14. You send money to PBS.

     15. The end of your tie doesn't come anywhere near the top of your
     pants.

     16. You take a metal detector to the beach.

     17. You know what the word "equity" means.

     18. You can't remember the last time you laid on the floor to watch
     television.

     19. Your ears are hairier than your head.

     20. You talk about "good grass" and you're referring to someone's
     lawn.

     21. You get into a heated argument about pension plans.

     22. You got cable for The Weather Channel.
     FIDONEWS 17-18               Page 30                   1 May 2000


     23. You can go bowling without drinking.

     24. You have a party and the neighbors don't even realize it.

     25. People send you this list.


     -----------------------------------------------------------------

     FIDONEWS 17-18               Page 31                   1 May 2000


     =================================================================
                              COMIX IN ASCII
     =================================================================


                         Remember These Famous Cows?

                                                               (    )
                   PRISON#  #  #  #  #                         ||||||
                   #  #  #  #  #(_#) #                          (OO)
                   #  #  #  #  #(o#) #             /------------\___/
                   #  #/-#--#--#-\#  #            / |           |||
                   #  # |#  #  #||#  #           /  ||          |||
                   # *# |#--#--#||#  #          *   ||----------|||
                   #  # ^#  #  #^^#  #              ^^           ^^
                                      The Bakker Cows


     -----------------------------------------------------------------

     FIDONEWS 17-18               Page 32                   1 May 2000


     =================================================================
                                  NOTICES
     =================================================================


                   Fidonews Editor Still Hangs in There :)
                                  Doug Myers

     Contrary to my announcement last week, I did not undergo my
     angioplasty last Monday as scheduled.  Doctors put off the procedure
     because I had an infected cyst on my back, electing instead to
     surgically remove it and put me on antibiotics.  However, they
     reacheduled me for last Friday, so I'm out of the hospital as of
     Saturday.

     The angioplasty went better than expected, as the doctors were only
     expecting to clear the blockage to one of the four blocked blood
     vessels in my heart; instead they were able to clear three of four.
     I'll be returning to work (with some restrictions) Monday as this
     edition is released, so there'll be no economic hardship... and
     hopefully improved health for years to come.

     My hat's off to modern medical science.  Fifteen years ago, my only
     alternative would have been open heart surgery followed by three
     months of disability while recuperating.  Angioplasty, by
     comparison, is a minor procedure.



     -----------------------------------------------------------------

     FIDONEWS 17-18               Page 33                   1 May 2000


     =================================================================
                               INTERNET INFO
     =================================================================


     ! = New entries this week
     ? = not responding
     ?? = unknown content, doesn't look like fidonet

                       . -- -- -- -- --- -- -- -- -- .
                       |    FIDONET-RELATED SITES    |
                       ` -- -- -- -- --- -- -- -- -- '
                          Last update:  April 17, 2000

     FidoNet
     Homepage:     http://www.fidonet.org
     FidoNews:     http://www.fidonews.org   [HTML]
                   ftp://ftp.nwstar.com/fidonet/fidonews/
                   ftp://ftp.sstar.com/fidonet/fnews/
     Echolist:     http://www.baltimoremd.com/echolist/
     Echomail links: http://www.osirusoft.com/fidonet/fidoip.html
     SDS Files:    http://fidobbs.dk/download (Web Access to SDS)
     FTSC page:    http://www.ftsc.org/
     General:      http://www.writebynight.com/fidonet.html

     List server:
         http://www.onelist.com/subscribe.cgi/fidonet-discussion

     Zone 1:       http://www.z1.fidonet.org
       Region 10:  http://www.psnw.com/~net205/region10.html
                   http://www.tnl-online.com/andy/rgn10.htm
         Net 103:  http://www.webworldinc.com/club103/
         Net 203:  http://www.geocities.com/Area51/8687/net203index.html
       Region 11:  http://oeonline.com/~garyg/region11/
        Net 2410:  http://oeonline.com/~garyg/net2410/
       Region 12:  http://sparkys.dyndns.org
       Region 13:  http://www.net264.org/r13.htm
         Net 264:  http://www.net264.org/
         Net 275:  http://www.homershut.net/~mahoover/net275/
       Region 14:  http://www.ouijabrd.com/region14
         Net 282:  http://www.rxn.com/~net282/
       Region 15:  <vacant>
       Region 16:  <vacant>
       Region 17:  http://www.nwstar.com/~region17/
       Region 18:  http://techshop.pdn.net/fido/

       Region 19:  <Vacant>
         Net 124:  http://www.startext.net/np/net124
                   http://texoma.net/~flv
         Net 130:  http://www.startext.net/homes/net130
         Net 393:  http://www.chatter.com/~wb/

     Zone 2:       http://www.z2.fidonet.org
                   ftp://ftp.sstar.com/fidonet/zone2 (Z2 nodelists etc.)
       Region 20:  http://www.fidonet.pp.se (in Swedish)
       Region 23:  http://www.fido.dk (in Danish)
     FIDONEWS 17-18               Page 34                   1 May 2000


       Region 24:  http://www.swb.de/personal/flop/gatebau.html (German)
         Fido-IP:  http://home.nrh.de/fido/ (English/German)
       Region 25:  http://www.literary.freeserve.co.uk/net2502/
       Region 26:  http://www.nemesis.ie
          REC 26:  http://www.nrgsys.com/orb
       Region 27:  http://telematique.org/ft/r27.htm
       Region 29:  http://www.rtfm.be/fidonet/  (French)
                   http://Welcome.to/skynetbbs/
       Region 30:  http://www.fidonet.ch  (German)
     ? Region 33:  http://www.fidoitalia.net  (Italian)
       Region 34:  http://www.pobox.com/cnb/r34.htm  (Spanish)
           REC34:  http://www.geocities.com/SiliconValley/4552/
       Region 36:  http://www.geocities.com/SiliconValley/7207/
       Region 38:  http://public.st.carnet.hr/~blagi/bbs/adriam.html
       Region 41:  http://www.fidonet.gr (Greek/English)
       Region 42:  http://www.fido.cz
     !    Net422:  http://www.fido.sk (Slovak/English)
       Region 50:  http://www.fido7.com/  (Russian)
        Net 5010:  http://fido.tu-chel.ac.ru/  (Russian)
        Net 5015:  http://www.fido.nnov.ru/  (Russian)
        Net 5028:  http://5028.yaroslavl.ru/
        Net 5030:  http://kenga.ru/fido/  (Russian & English)
        Net 5049:  http://www.n5049.z2.fidonet.org  (English/Russian)
     ??  Net 5085:  http://www.fidonet.uz/ (Russian)

     Zone 3:       http://www.z3.fidonet.org

     Zone 4:
       Region 80:  http://fidobrasil.8m.com  (Portuguese)
       Region 90:
         Net 904:  http://members.tripod.com/~net904 (Spanish)

     Zone 5:       http://www.eastcape.co.za/fidonet/

     Zone 6:       http://www.z6.fidonet.org
       Region 65:  http://www.cfido.com/fidonet/cfidochina.html
                   (Chinese)


                          Fidonet Via Internet Hubs

     See also: http://www.osirusoft.com/fidoip.html

     a @ preceding an individual's name implies a virtual email
     address. The email is translated as follows
     firstlast@osirusoft.com will automatically route to the
     appropriate individual's email.  Anyone in this list will
     also receive routed notice of this feature.  In my case, it
     would still be joejared@osirusoft.com, but you get the idea.

     Also, as information is provided to me, I will be adding a
     latency field to each node, which is defined as the maximum
     time between when the message is received, and when it is
     sent on to other nodes, or available to be sent onward,
     defined in minutes. A latency of ! implies that there is an
     immediate response, and an attempt to deliver immediately
     FIDONEWS 17-18               Page 35                   1 May 2000


     after processing, or a "MinuteMail System", as it were.

                v-email flag firstnamelastname@osirusoft.com
                | email address or
     Node#      | Operator          | Facilities (*) | Speed,| Basic Rate
                |                   |                |latency|
     -----------+-------------------+----------------+-------+------------
     Zone 1     |                   |                |       |
       10/3     @ Brenda Donovan    | FTP,UUE,BinkP  | 384K,30| n/c
       10/345   @ Todd Cochrane     | FTP,BinkP,VMOT | T1,!  | n/c
       12/12    @ Ken Wilson        | FTP            | T1    | $24mo.
       13/25    @ Jim Balcom        | FTP            | 56k   | $20mo.
      103/5     @ Mark Luetger      | BinkP          | 384k,!| n/c
      103/153   @ Michael Box       | BinkP          | aDSL,!| n/c
      103/301   @ Joe Jared         | BinkP,FTP      | 384k,!| n/c
      103/401   @ Warren Bonner     | BinkP          | aDSL,!| n/c
      105/8     | Russ Johnson      | FTP,BinkP,VMoT | 384k  | n/c
      105/72    @ Larry James       | FTP, BinkP     | aDSL  | $50/yr
      106/1     @ Matt Bedynek      | BinkP, FTP     | 128k  | n/c
      106/6018  | Lawrence Garvin   | FTP, VMoT      | aDSL,60| n/c
      107/453   @ Jeffrey Estevez| FTP,BinkP,VMoT,UUE| 56k,60| $10 mo.
      140/1     @ Bob Seaborn       | FTP,BinkP      | T3,30 | $5/$16
      167/133   | Stephen Monteith  | BinkP          | 128k+ | n/c
      211/417   @ Korombos          | BinkP,UUE,FTP  | T1    | n/c
      218/109   @ Matt Munson       | BinkP,UUE      | 33.6k | n/c
      244/2     | Kari Suomela   | FTP,VMoT,BinkP,UUE| T1,!  | $25.00/mo
      246/160   @ Mason Vye         | FTP, UUE       | 56K   | n/c
      271/140   @ Tom Barstow       | UUE,FTP        | T1    | n/c
      280/169   | Brian Greenstreet | FTP            | 33.6  | $2mo.
      342/3     @ Richard Dodsworth | BinkP,FTP      | 128K+ | n/c
      395/670   | Arthur Stark      | BinkD,FTP      | 128k  | n/c
      396/1     @ John Souvestre    | FTP,VMoT       | T1,10 | $5/mo
      396/45    | Marc Lewis        | UUE            | 33.6  | $26/yr
     2604/104   @ Jim Mclaughlin    | FTP,VMoT,UUE   | 33.6  | $1mo
     2613/404   @ David Moufarrege  | BinkP,FTP,VMoT | 128k+,!| n/c
     2624/306   @ David Calafrancesco  | VMoT        | 33.6  | n/c
     3613/2     @ jyates@bsdi.ldl.net | UUE            | 28.8  | n/c
     3632/84    | Robert Todd    |FTP,VMoT,UUE,BinkP | 57.6k | n/c
     3639/93    @ Ross Cassell      | FTP, BinkP     |128K+,!| n/c
     3651/9     @ Jerry Gause       | FTP,VMoT       | 33.6  | $3/$6
     --------------------------------------------------------------
     Zone 2     |
       20/11    | Henrik Lindhe     | BinkP          | ???   | n/c
       31/1     | Gabriel Plutzar   | BinkP          | T1+   | n/c
      203/600   | Mikael Karlsson   | UUE            | 64k   | n/c
      221/360   @ Tommi Koivula     | BinkP,UUE      | ???   | n/c
      236/205   @ Michael Kaaber    | BinkP          | ???   | n/c
      246/2098  | Volker Imre       | BinkP          | ???   | n/c
      284/800   @ Jeroen VanDeLeur  | FTP,UUE        | 64k   | n/c
      292/620   | Eddy Missoul      | VMoT, UUE      | 64k   |N/C
      292/624   | Steven Leeman     | UUE          | 64k   | N/C
      292/2003  | Eric Vaneberck    | BinkP          | 768k  | n/c
      301/1     | Peter Witschi     | BinkP          | 768k  | n/c
      332/807   | Roberto Mascolo   | BinkP          | ???   | n/c
      335/535   @ Mario Mure        | BinkP,VMot,UUE | 64k   | n/c
      335/610   | Gino Lucrezi      | UUE            | 33.6  | n/c
     FIDONEWS 17-18               Page 36                   1 May 2000


      344/201   | Julio Garcia      | BinkP          | ???   | n/c
      346/3     @ Carlos Navarro    | UUE            | ???   | n/c
      382/100   | Sinisa Burina     | BinkP          | ???   | n/c
      406/555   | Ofir Michaeli &   | BinkP          | ???   | n/c
      406/555   | Marius Kaizerman  | BinkP          | ???   | n/c
      423/81    | Milos Bajer       | BinkP          | ???   | n/c
      464/4077  | Serguei Trouchelle| UUE            | 19.2  | n/c
      465/204   | Va Milushnikov    | BinkP          | 33.6k | n/c
      469/84    | Max Masyutin      | VMoT           | 256k  | n/c
      480/112   | Adam Sarapata| FTP, VMoT, UUE,BinkP| 128k  | n/c
     2411/413   @ Dennis Dittrich   | UUE,BinkP      | 64k   | n/c
     2446/301   | Lothar Behet | BinkP,VMoT,UUE,FTP  | 64K   | n/c
     2474/275   | Christian Emig    | UUE            | 64k   | unkn
     5030/115   | Andrey Podkolzin  | BinkP          | ???   | n/c
     5100/8     | Egons Bush        | BinkP          | ???   | n/c
     5020/1159  | Gennady Kudryashoff | UUE          | 33.6  | n/c
     --------------------------------------------------------------
     Zone 3
      633/260   @ Malcolm Miles     | FTP,BinkP      | 64K   | n/c
      640/954   | Rick Van Ruth     | FTP,VMot,UUE,BinkP| 56K| n/c
      774/605   @ Barry Blackford|BinkP,VMoT:10023,ifcico,FTP |33.6| n/c

     --------------------------------------------------------------
     Zone 4
      905/100   | Fabian Gervan     | VMoT,UUE,BinkP | 128k  | n/c
      902/18    | Javier Tejedor    | UUE            | 33,6  | n/c

     --
     * FTP   = Internet File Transfer Protocol
     * VMoT  = Virtual Mailer over Telnet (various)
     * UUE   = uuencode<->email type transfers
     * BinkP = front end mailer for TCPIP networks

     ----------------------------------------------
     Fidonet oriented news servers

     news.osirusoft.com
     news.tardis.net

     Fidonet oriented chat rooms.

     room #fidonet  5PM (PDT 11AM GMT) Sundays
     irc.osirusoft.com  (Peers wanted)

     ----------------------------------------------

     Please send updates, corrections and suggestions to
     Joe Jared, 1:103/301, joejared@osirusoft.com.  All email addresses
     here for purpose of corresponding with fidonet members about
     obtaining a feed.  Improper use of the virtual email addresses, and
     most especially, email addressed to blockme@relays.osirusoft.com
     will be considered a request to be blocked by my open relay spam
     stopper at http://relays.osirusoft.com


     -----------------------------------------------------------------
     FIDONEWS 17-18               Page 37                   1 May 2000


     =================================================================
                               FIDONEWS INFO
     =================================================================

                                   Masthead

     + -- -- -- -- -- -- -- --  FIDONEWS STAFF - -- -- -- -- -- -- -- +
     |                                                                |
     | Editor:     Douglas Myers, 1:270/720, DougM@paonline.com       |
     | Webmaster:  Jim Barchuk, jb@fidonews.org                       |
     | Columnist:  Joe Jared, 1:103/0, jarhead@osirusoft.com          |
     |             (Fido Via Internet Hubs column)                    |
     | Columnist:  Warren D. Bonner, 1:103/401, wdbonner@pacbell.net  |
     |             (Warren uses the pen name "Ol'WDB")                |
     | Humor:      Roy Reed, rcreedv@juno.com                         |
     | Features:   Frank Vest, 1:124/6308.1                           |
     |                                                                |
     + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

     + -- -- -- -- -- -- -- -  EDITORS EMERITI - -- -- -- -- -- -- -- +
     |                                                                |
     |       Tom Jennings, Thom Henderson, Dale Lovell, Vince         |
     |       Perriello, Tim Pozar, Sylvia Maxwell, Donald Tees,       |
     |       Christopher Baker, Zorch Frezberg, Henk Wolsink          |
     |                                                                |
     + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

     "Fido", "FidoNet" and the dog-with-diskette are U.S. registered
     trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA
     94141, and are used with permission.

     Fidonews is published weekly by and for the members of Fidonet.
     Fidonews is Copyright (C) 2000 by Douglas Myers, though authors
     retain rights to their contributed articles.  Opinion expressed by
     the authors is strictly their own.  Noncommercial duplication and
     distribution within Fidonet is encouraged.  Authors are encouraged
     to send their articles in ASCII text to Douglas Myers at one of his
     addresses above.

     The weekly edition of Fidonews is distributed through the file area
     FIDONEWS, and is published as echomail in the echo FIDONEWS.  These
     sources are normally available through your Network Coordinator.
     The current and past issues are also available from the following
     sources:

     + -- -- -- -- -- -- -  FIDONEWS AVAILABILITY - -- -- -- -- -- -- +
     |                                                                |
     |         Freq FIDONEWS @ 1:270/720, 1:140/1, or 1:396/1         |
     |         ftp://ftp.sstar.com/fidonet/fnews/                     |
     |         ftp://ftp.nwstar.com/fidonet/fidonews/                 |
     |         http://www.fidonews.org                                |
     |         email subscription: majordomo@fidonews.org             |
     |                       (subject: help   body: list)             |
     |         ftp mail: ftpmail@fidonews.org (subject: help)         |
     |                                                                |
     + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +
     FIDONEWS 17-18               Page 38                   1 May 2000


     -----------------------------------------------------------------

