     Volume 6, Number 14                                  3 April 1989
     +---------------------------------------------------------------+
     |                                                  _            |
     |                                                 /  \          |
     |                                                /|oo \         |
     |        - FidoNews -                           (_|  /_)        |
     |                                                _`@/_ \    _   |
     |        International                          |     | \   \\  |
     |     FidoNet Association                       | (*) |  \   )) |
     |         Newsletter               ______       |__U__| /  \//  |
     |                                 / FIDO \       _//|| _\   /   |
     |                                (________)     (_/(_|(____/    |
     |                                                     (jm)      |
     +---------------------------------------------------------------+
     Editor in Chief:                                  Vince Perriello
     Editors Emeritii:                                     Dale Lovell
                                                        Thom Henderson
     Chief Procrastinator Emeritus:                       Tom Jennings
     Contributing Editors:                                   Al Arango
     
     FidoNews  is  published  weekly  by  the  International   FidoNet
     Association  as  its  official newsletter.  You are encouraged to
     submit articles for publication in FidoNews.  Article  submission
     standards  are contained in the file ARTSPEC.DOC,  available from
     node 1:1/1.    1:1/1  is  a Continuous Mail system, available for
     network mail 24 hours a day.
     
     Copyright 1989 by  the  International  FidoNet  Association.  All
     rights  reserved.  Duplication  and/or distribution permitted for
     noncommercial purposes only.  For  use  in  other  circumstances,
     please contact IFNA at (314) 576-4067. IFNA may also be contacted
     at PO Box 41143, St. Louis, MO 63141.
     
     Fido  and FidoNet  are registered  trademarks of  Tom Jennings of
     Fido Software,  164 Shipley Avenue,  San Francisco, CA  94107 and
     are used with permission.
     
     We  don't necessarily agree with the contents  of  every  article
     published  here.  Most of these materials are  unsolicited.    No
     article will be rejected which is properly attributed and legally
     acceptable.    We   will  publish  every  responsible  submission
     received.


                        Table of Contents
     1. ARTICLES  .................................................  1
        Policy4 Draft Released for Comment  .......................  1
        ZOW, Yet Another Fantastically New File Packer! (Part 2  .. 35
     2. COLUMNS  .................................................. 37
        The Veterinarian's Corner: Winter Weather & Antifreeze  ... 37
     3. LETTERS TO THE EDITOR  .................................... 38
     4. LATEST VERSIONS  .......................................... 39
        Latest Software Versions  ................................. 39
     5. NOTICES  .................................................. 40
        The Interrupt Stack  ...................................... 40
     FidoNews 6-14                Page 1                    3 Apr 1989


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

                              FidoNet Policy4
                             Comments Solicited
              David Dodell, FidoNet International Coordinator
                             1:114/15  -- 1:1/0

     Included in this  article  is  a  proposed  policy  document  for
     FidoNet.  The  existing  policy has served well,  but FidoNet has
     grown and changed  a  great  deal  since  it  was  adopted.  This
     proposal has been prepared by the Regional Coordinators, and your
     comments are sincerely solicited.

     Discussion at the net level is encouraged,  and Network Coordina-
     tors will represent their net to the  Regional  Coordinator.  The
     RC's  realize that the net has significant input into the process
     of preparing policy,  and  your  comments  will  be  thoughtfully
     considered.

     The  deadline for comments is April 30.  A final proposal will be
     issued on May 8,  and a vote will be conducted of NC's and  RC's.
     The  voting  period  will  end  on  June  5,  and results will be
     announced in the nodediff which is released on June 9.

     You are encouraged to read the proposal in its entirity, but here
     are a few of the differences between this proposal and Policy3.

     Greater detail:  Throughout the document,  more detail  has  been
     provided  in  an  effort to clarify procedures.  The intent is to
     make expectations clear for new and existing sysops to reduce the
     potential for unintentional policy violations,  and  to  simplify
     the resolution of disputes when they do occur.  This is an admin-
     istrative  document  which  will  assist  both  coordinators  and
     sysops.

     Description of "new" developments:  Routing hubs,  point systems,
     and  zone coordinators are described.  None of these existed when
     Policy3 was written.

     Change procedure: A procedure is included to modify policy.  This
     procedure will be used to adopt or reject Policy4.

     Dispute resolution:  A statute of  limitations  and  a  limit  on
     response  time  by  a  coordinator  have  been added.  The appeal
     process has  been  clarified.  Specific  requirements  have  been
     added  for  a  dialog  between the complaining parties before the
     filing of a formal complaint.

     Mail:   Specific  procedures  are  included  for  private   mail,
     echomail, and mail routing.

     Index: An index has been added to help you find that section that
     you know is there, but can't seem to locate.

     FidoNews 6-14                Page 2                    3 Apr 1989


     The full text of the proposal follows:


                         FidoNet Policy Document        Version 4.03
                              *** DRAFT ***           March 24, 1989


     This policy document has been released for comment, and is not
     yet in force.  Please direct comments to your Network Coordi-
     nator.



     1  Overview


     1.0  Language

     The official language of FidoNet is English.  All documents
     must exist in English.  Translation into other languages is
     encouraged.


     1.1  Introduction

     FidoNet is an amateur electronic mail system.  As such, all of
     its participants and operators are unpaid volunteers.  From
     its early beginning as a few friends swapping messages back
     and forth (1984), it now (1989) includes over 5,000 systems on
     six continents.

     FidoNet is not a common carrier or a value-added service
     network and is a public network only in as much as the inde-
     pendent, constituent nodes may individually provide public
     access to the network on their system.

     FidoNet is large enough that it would quickly fall apart of
     its own weight unless some sort of structure and control were
     imposed on it.  Multinet operation provides the structure.
     Decentralized management provides the control.  This document
     describes the procedures which have been developed to manage
     the network.


     1.2  Organization

     FidoNet nodes are grouped on several levels.

     Separate documents may be issued at the zone, region, or net
     level to provide additional detail on local procedures.  Ordi-
     narily, these lower-level policies may not contradict this
     policy.  However, with the approval of the International
     Coordinator, local policy can be used to implement differences
     required due to local requirements.  The Zone Coordinator
     Council may reverse the decision of the International Coordi-
     nator.  These local policies may not place additional restric-
     FidoNews 6-14                Page 3                    3 Apr 1989


     tions on members of FidoNet beyond those included in this
     document, other than enforcement of local mail periods.


     1.2.1  Points

     A point is a FidoNet-compatible system that is not in the
     nodelist, but communicates with FidoNet through a node re-
     ferred to as a bossnode.  A point is generally regarded in the
     same manner as a user, for example, the bossnode is responsi-
     ble for mail from the point.  (See section 2.1.3.)  Points are
     addressed by using the bossnode's nodelist address; for exam-
     ple, a point system with a bossnode of 114/15 might be known
     as 114/15.12.  Mail destined for the point is sent to the
     bossnode, which then routes it to the point.

     In supporting points, the bossnode makes use of a private net
     number which should not be visible outside of the bossnode-
     point relationship except as the first entry in the ^aPATH
     line.  Unfortunately, should the point call another system
     directly (to do a file request, for example), the private
     network number will appear as the caller's address.  In this
     way, points are different from users, since they operate
     FidoNet-compatible mailers which are capable of contacting
     systems other than the bossnode.

     1.2.2  Nodes

     A node is a single FidoNet address, and is the smallest offi-
     cial unit of FidoNet.


     1.2.3  Networks

     A network is a collection of nodes in a local geographic area.
     Networks coordinate their mail activity to decrease cost.

     1.2.3  Regions

     A region is a well-defined geographic area containing nodes
     which may or may not be combined into networks.  A typical
     region will contain many nodes in networks, and a few indepen-
     dent nodes which are not a part of any network.

     1.2.5  Zones

     A zone is a large geographic area containing many regions,
     covering one or more countries and/or continents.


     1.2.6  FidoNet

     FidoNet indicates the entire amateur mail network as defined
     by the weekly nodelist (see section 1.3.4).


     FidoNews 6-14                Page 4                    3 Apr 1989


     1.3  Definitions

     1.3.1  FidoNews

     FidoNews is a weekly newsletter distributed throughout the
     network by the coordinator structure.  It is an important
     medium by which FidoNet sysops communicate with each other.
     FidoNews provides a sense of being a community of people with
     common interests.  Accordingly, sysops and users are encour-
     aged to contribute to FidoNews.  Contributions are submitted
     to node 1/1; a file describing the format to be used is avail-
     able on many systems.


     1.3.2  Geography

     Each level of FidoNet is geographically contained by the level
     immediately above it.  A given geographic location is covered
     by one zone and one region within that zone, and is either in
     one network or not in a network.  There are never two zones,
     two regions, or two networks which cover the same geographic
     area.

     If a node is in the area of a network, it should be listed in
     that network, not as an independent in the region.  (The
     primary exception to this is a node receiving inordinate
     amounts of host-routed mail; see section 4.2).  Network bound-
     aries are based on calling areas as defined by the local
     telephone company.  Even in the case of areas where node
     density is so great that more than one network is needed to
     serve one local calling area, a geographic guideline is used
     to decide which nodes belong to what network.  Network member-
     ship is based on geographic or other purely technical ratio-
     nale.  It is not based on personal or social factors.

     There are cases in which the local calling areas lead to
     situations where logic dictates that a node physically in one
     FidoNet Region should be assigned to another.  In those cases,
     with the agreement of the Regional Coordinators and Zone
     Coordinator involved, exemptions may be granted.  Such exemp-
     tions are described in section 5.6.

     1.3.3  Zone Mail Hour

     Zone Mail Hour (ZMH) is a defined time during which all nodes
     in a zone are required to be able to accept netmail.  Each
     Fidonet zone defines a ZMH and publishes the time of its ZMH
     to all other Fidonet zones.  See sections 2.1.8 and 10.2.

     Zone Mail Hour has previously been referred to as National
     Mail Hour and Network Mail hour.  The term Zone Mail Hour is
     more accurate.

     1.3.4  Nodelist

     The nodelist is a file updated weekly which contains the ad-
     FidoNews 6-14                Page 5                    3 Apr 1989


     dresses of all recognized FidoNet nodes.  This file is cur-
     rently made available by the Zone Coordinator not later than
     Zone Mail Hour each Saturday, and is available electronically
     for download or file request at no charge.  To be included in
     the nodelist, a system must meet the standards defined by this
     document.  No other requirements may be imposed.

     Partial nodelists (single-zone, for example) may be made
     available at different levels in FidoNet.  The full list as
     published by the International Coordinator is regarded as the
     official FidoNet nodelist, and is used in circumstances such
     as determination of eligibility for voting.  All parts that
     make up the full nodelist are available on each Zone Coordina-
     tor's and each Regional Coordinator's system.


     1.3.5  Excessively Annoying Behavior

     There are references throughout this policy to "excessively
     annoying behavior", especially in section 9 (Resolution of
     Disputes).  It is difficult to define this term, as it is
     based upon the judgement of the coordinator structure.  Gener-
     ally speaking, annoying behavior irritates, bothers, or causes
     harm to some other person.  It is not necessary to break a law
     to be annoying.  Refer to section 9 and the case studies
     (section 10.3) for more information.

     1.4  Administration of FidoNet


     FidoNet has a hierarchical structure for administration of the
     network, with the following levels:


     1.4.1  International Coordinator

     The International Coordinator is the "first among equals" Zone
     Coordinator.  He coordinates the joint production of the
     master nodelist by his fellow Zone Coordinators.

     The International Coordinator acts as the chair of the Zone
     Coordinator Council and as the overseer of elections -- ar-
     ranging the announcement of referenda, the collection and
     counting of the ballots, and announcing the results for those
     issues that affect FidoNet as a whole.


     1.4.2  Zone Coordinator Council

     In certain cases, the Zone Coordinators work as a council to
     provide advice to the International Coordinator.  The arrange-
     ment is similar to that between a president and advisors.  In
     particular, this council considers inter-zonal issues.  This
     includes, but is not limited to: working out the details of
     nodelist production, mediating inter-zonal disputes, and such
     issues not addressed at a lower level of FidoNet.
     FidoNews 6-14                Page 6                    3 Apr 1989


     1.4.3  Zone Coordinator

     The Zone Coordinator compiles the nodelists from all of the
     regions in the zone, and creates the master nodelist and
     difference file, which is then distributed over FidoNet in the
     zone.  A Zone Coordinator does not perform routing services
     for the zone.


     1.4.4  Regional Coordinator

     The Regional Coordinator maintains the list of independent
     nodes in the region and accepts nodelists from the Network
     Coordinators in the region.  He compiles these lists to create
     a regional nodelist, which he then sends to the Zone Coordina-
     tor.  A Regional Coordinator does not perform routing services
     for any nodes in the region.


     1.4.5  Network Coordinator

     The Network Coordinator is responsible for maintaining the
     list of nodes for the network, and for forwarding netmail sent
     to the network from other FidoNet nodes.  The Network Coordi-
     nator may make arrangements to handle outgoing netmail, but is
     not required to do so.  The Network Coordinator is not re-
     quired to provide a source for echomail.


     1.4.6  Network Routing Hub

     Network Routing Hubs exist only in some networks.  They share
     duties of the Network Coordinator, in order to ease the man-
     agement of a large network.  The exact duties and procedures
     are a matter for the Network Coordinator and his hubs to
     arrange, and will not be discussed here, except that a network
     coordinator cannot delegate responsibility to mediate dis-
     putes.


     1.4.7  System Operator

     The system operator (sysop) formulates a policy for running
     his board and dealing with users.  The sysop must mesh with
     the rest of the FidoNet system if he is to send and receive
     mail, and the local policy must be consistent with other
     levels of FidoNet.


     1.4.8  User

     The sysop is responsible for the actions of any user when they
     affect the rest of FidoNet.  (If a user is annoying, the sysop
     is annoying.)  Any traffic entering FidoNet via a given node,
     if not from the sysop, is considered to be from a user, and is
     the responsibility of the sysop.  This includes messages from
     FidoNews 6-14                Page 7                    3 Apr 1989


     point systems.


     1.4.9  Summary

     These levels act to distribute the administration and control
     of FidoNet to the lowest possible level, while still allowing
     for coordinated action over the entire mail system.  Adminis-
     tration is made possible by operating in a top-down manner.
     That is, a person at any given level is responsible to the
     level above, and responsible for the level below.

     For example, a Regional Coordinator is responsible to the Zone
     Coordinator for anything that happens in the region.  From the
     point of view of the Zone Coordinator, the Regional Coordina-
     tor is completely responsible for the smooth operation of the
     region.  Likewise, from the point of view of the Regional
     Coordinator, the Network Coordinator is completely responsible
     for the smooth operation of the network.

     If a person at any level above sysop is unable to properly
     perform their duties, the person at the next level may replace
     them.  For example, if a Regional Coordinator fails to per-
     form, the Zone Coordinator can replace him.

     The exceptions to this top down organization are the Zone and
     International Coordinators.  See sections 6.2 and 7.2.


     2  Sysop Procedures

     2.1  General

     2.1.1  The Basics

     The sysop of an individual node can generally do as he
     pleases, as long as he observes the mail events, is not exces-
     sively annoying to other nodes on FidoNet, and does not pro-
     mote or participate in the distribution of pirated copyrighted
     software or other illegal behavior via FidoNet.


     2.1.2  Familiarity with Policy

     In order to understand the meaning of "excessively annoying",
     it is incumbent upon all sysops to occasionally re-read Fido-
     Net policy.  New sysops must familiarize themselves with
     policy before requesting a node number.


     2.1.3  Responsible for All Traffic Entering FidoNet Via His
     Node

     A Sysop is responsible for all traffic entering FidoNet via
     his system.  This includes (but is not limited to) traffic
     entered by his users, points, and any other networks for which
     FidoNews 6-14                Page 8                    3 Apr 1989


     he might act as a gateway.  If a sysop allows "outside" mes-
     sages to enter FidoNet via his system, he has a responsibility
     to ensure his system is clearly identified by FidoNet node
     number as the point of origin of that message, and a responsi-
     bility to act as a gateway in the reverse direction.  Should
     such traffic result in a violation of Policy, the sysop must
     rectify the situation.


     2.1.4  Encryption and Review of Mail

     FidoNet is an amateur system.  Our technology is such that the
     privacy of messages cannot be guaranteed.  Any sysop has the
     right to review traffic flowing through his system, if for no
     other reason than to ensure that the system is not being used
     for illegal purposes.  Encryption obviously makes this review
     impossible.  Therefore, encrypted and/or commercial traffic
     that is routed without the express permission of all the links
     in the delivery system constitutes annoying behavior.


     2.1.5  No Alteration of Routed Mail

     A sysop may not modify, other than as required for routing or
     other technical purposes, any message, netmail or echomail,
     passing through the system from one FidoNet node to another.
     If a sysop is offended by the content of a message, he must
     follow the procedure described in section 2.1.7.


     2.1.6  Private Netmail

     The word "private" should be used with great care, especially
     with users of a BBS.  Some countries have laws which deal with
     "private mail", and it should be made clear that the word
     "private" does not imply that no person other than the recipi-
     ent can read messages.  Sysops who cannot provide this dis-
     tinction should consider not offering users the option of
     "private mail".

     If a user sends a "private message", the user has no control
     over the number of intermediate systems through which that
     message is routed.  A sysop who  sends a message to another
     sysop can control this aspect by sending the message direct to
     the recipient's system, thus guaranteeing that only the recip-
     ient or another individual to whom that sysop has given autho-
     rization can read the message.  Thus, a sysop may have differ-
     ent expectations than a casual user.

     2.1.6.1  No Disclosure of in-transit mail

     Disclosing or in any way using information contained in pri-
     vate netmail traffic not addressed to you or written by you is
     considered annoying behavior, regardless of how you come upon
     that traffic.  This does not apply to echomail which is by
     definition a broadcast medium, and where private mail is often
     FidoNews 6-14                Page 9                    3 Apr 1989


     used to keep a sysop-only area restricted.

     2.1.6.2  Private mail addressed to you

     The issue of private mail which is addressed to you is more
     difficult than the in-transit question treated in the previous
     section.  A common legal opinion holds that when you receive a
     message it becomes your property and you have a legal right to
     do with it what you wish.  Your legal right does not excuse
     you from annoying others.

     In general, sensitive material should not be sent using Fido-
     Net.  This ideal is often compromised, as FidoNet is our
     primary mode of communication.  In general, if the sender of a
     message specifically requests in the text of the message that
     the contents be kept confidential, release of the message into
     a public forum may be considered annoying.

     There are exceptions.  If someone is saying one thing in
     public and saying the opposite in private mail, the recipient
     of the private mail should not be subjected to harassment
     simply because the sender requests that the message not be
     released.  Judgement and common sense should be used in this
     area as in all other aspects of FidoNet behavior.

     2.1.7  Not Routing Mail

     A sysop is not required to route traffic if he has not agreed
     to do so.  He is not obligated to route traffic for all if he
     routes it for any, unless he holds a Network Coordinator or
     Hub Coordinator position.  Routing traffic through a node not
     obligated to perform routing without the permission of that
     node may be annoying behavior.  This includes unsolicited
     echomail.

     If a sysop does not forward a message when he had previously
     agreed to perform such routing, the message must be returned
     to the sysop of the node at which it entered FidoNet with an
     explanation of why it was not forwarded.  (It is not necessary
     to return messages which are addressed to a node which is not
     in the current nodelist.)  Intentionally stopping an in-tran-
     sit message without following this procedure constitutes
     annoying behavior.  In the case of a failure to forward traf-
     fic due to some technical problem, it does not become annoying
     unless it persists after being pointed out to the sysop.


     2.1.8  Exclusivity of Zone Mail Hour

     Zone Mail Hour is the heart of FidoNet, as this is when net-
     work mail is passed between systems.  Any system which wishes
     to be a part of FidoNet must be able to receive mail from any
     node in the nodelist during this time.  This time is exclu-
     sively reserved for netmail.  Many phone systems charge on a
     per-call basis, regardless of whether a connect, no connect,
     or busy signal is encountered.  For this reason, any activity
     FidoNews 6-14                Page 10                   3 Apr 1989


     other than normal network mail processing that ties up a
     system during ZMH is considered annoying behavior.  Echomail
     should not be transferred during ZMH.  User (BBS) access to a
     system is prohibited during ZMH.

     A system which is a member of a local network may also be re-
     quired to observe additional mail events, as defined by the
     Network Coordinator.  Access restrictions during local network
     periods are left to the discretion of the Network Coordinator.


     2.1.9  Private Nodes

     The rare exception to ZMH compliance is Private Nodes.  Per-
     sons requesting private nodes should be supported as points if
     possible.  A private listing is justified when the system must
     interface with many others, such as an echomail distributor.
     In these cases, the exact manner and timing of mail delivery
     is arranged between the private node and other systems.  Such
     an agreement between a private system and a hub is not binding
     on any replacement for that hub.  A private node must be a
     part of a network (they cannot be independents in the region.)
     Private nodes are encouraged to honor ZMH.


     2.1.10  Observing Mail Events

     Failure to observe the proper mail events is grounds for any
     node to be dropped from FidoNet without notice (since notice
     is generally given by netmail).


     2.1.11  Use of Current Nodelist

     Network mail systems generally operate unattended, and place
     calls at odd hours of the night.  If a system tries to call an
     incorrect or out-of-date number, it could cause some poor
     citizen's phone to ring in the wee hours of the morning, much
     to the annoyance of innocent bystanders and civil authorities.
     For this reason, a sysop who sends mail is obligated to obtain
     and use the most recent edition of the nodelist as is practi-
     cal.


     2.1.12  Excommunication

     A system which has been dropped from the network is said to be
     excommunicated (i.e. denied communication).  If you find that
     you have been excommunicated without warning, your coordinator
     was unable to contact you.  You should rectify the problem and
     contact your coordinator.

     Systems may also be dropped from the nodelist for cause.  See
     section 9, and sections 4.3 and 5.2.

     It is considered annoying behavior to assist a system which
     FidoNews 6-14                Page 11                   3 Apr 1989


     was excommunicated in circumventing that removal from the
     nodelist.  For example, if you decide to provide an echomail
     feed to your friend who has been excommunicated, it is likely
     that your listing will also be removed.


     2.1.13  Timing of Zone Mail Hour

     The exact timing of Zone Mail Hour for each zone is set by the
     Zone Coordinator.  See section 10.2.


     2.1.14  Non-observance of Daylight Savings Time

     FidoNet does not observe daylight savings time.  In areas
     which observe daylight savings time the FidoNet mail schedules
     must be adjusted in the same direction as the clock change.
     Alternatively, you can simply leave your system on standard
     time.


     2.2  How to obtain a node number


     You must first obtain a current nodelist so that you can send
     mail.  You do not need a node number to send mail, but you
     must have one in order for others to send mail to you.

     The first step in obtaining a current nodelist is to locate a
     FidoNet bulletin board.  Most bulletin board lists include at
     least a few FidoNet systems, and usually identify them as
     such.  Use a local source to obtain  documents because many
     networks have detailed information available which explains
     the coverage area of the network and any special requirements
     or procedures.

     Once you have a nodelist, you must determine which network or
     region covers your area.  Regions are numbered 1-99; network
     numbers are greater than 99.  Networks are more restricted in
     area than regions, but are preferred since they improve the
     flow of mail and provide more services to their members.  If
     you cannot find a network which covers your area, then pick
     the region which does.

     Once you have located the network or region in your area, send
     a message containing a request for a node number to node zero
     of that network or region.  The request must be sent by net-
     mail, use address -1/-1, and include the following:

          1) Your name.
          2) The name of your system.
          3) The city and state where your system is located.
          4) The phone number to be used when calling your system.
          5) Your hours of operation, netmail and BBS.
          6) The maximum baud rate you can support.

     FidoNews 6-14                Page 12                   3 Apr 1989


     You must indicate that you have read, and agree to abide by,
     this document and all the current and future policies of Fido-
     Net.

     Using a node number other than -1/-1 can cause problems for
     the coordinator involved.  Simply assigning yourself a
     net/node number can be annoying, and can be grounds to reject
     your request.

     Your coordinator may want additional information.  If so, he
     will contact you.

     Please allow at least two weeks for a node number request to
     be processed.  If you send your request to a Regional Coordi-
     nator, he may forward it to the appropriate Network Coordina-
     tor.


     2.3  If You are Going Down

     If your node will be down for an extended period (more than a
     day or two), inform your coordinator as soon as possible.  If
     you do not do this,  other systems will try to reach you while
     you are down, much to their annoyance.  Never put an answering
     machine or similar device on your phone line while you are
     down. If you do, calling systems will get the machine repeat-
     edly, racking up large phone bills, which is very annoying.

     If you will be leaving your system unattended for an extended
     period of time (such as while you are on vacation), you should
     notify your coordinator.  Systems have a tendency to "crash"
     now and then, so you will probably want your coordinator to
     know that it is a temporary condition if it happens while you
     are away.


     2.4  How to Form a Network

     If there are several nodes in your area, but no network, a new
     network can be formed.  This has advantages to both you and to
     the rest of FidoNet.  You receive better availability of
     nodelist difference files and FidoNews, and everyone else can
     take advantage of host-routing netmail to the new network.

     The first step is to contact the other sysops in your area.
     You must decide which nodes will comprise the network, and
     which of those nodes you would like to be the Network Coordi-
     nator.  Then consult your Regional Coordinator.  You must send
     the following information:

        1) The region number(s), or network number(s) if a net-
        work is splitting up, that are affected by the formation
        of your network.  The Regional Coordinator will inform
        the Zone Coordinator and the coordinators of any affected
        networks that a new network is in formation.

     FidoNews 6-14                Page 13                   3 Apr 1989


        2) A copy of the proposed network's nodelist segment.
        This file should be attached to the message of applica-
        tion for a network number, and should use the nodelist
        format described in the current version of the appro-
        priate FTSC publication.  Please elect a name that re-
        lates to your grouping, for example SoCalNet for nodes in
        the Southern California Area and MassNet West for the
        Western Massachusetts Area.  Remember if you call your-
        self DOGNET it doesn't identify your area.

     Granting a network number is not automatic.  Even if the
     request is granted, the network might not be structured exact-
     ly as you request.  Your Regional Coordinator will review your
     application and inform you of the decision.

     Do not send a network number request to the Zone Coordinator.
     All network number requests must be processed by the Regional
     Coordinator.



     3  General Procedures for All Coordinators

     3.1  Make Available Nodelists, Difference Files, and FidoNews

     Any Coordinator is responsible for obtaining and making avail-
     able, on a weekly basis, nodelist difference files and Fido-
     News.


     3.2  Processing Nodelist Changes and Passing Them Upstream

     Each coordinator is responsible for obtaining nodelist infor-
     mation from the level below, processing it, and passing the
     results to the level above.  The timing of this process is
     determined by the requirements imposed by the level above.


     3.3  Ensure the Latest Policy is Available

     A Coordinator is responsible to make the current version of
     this document available to the level below, and to encourage
     familiarity with it.

     In addition, a coordinator is required to forward any local
     policies he receives to the level above, and to review such
     policies.  Although not required, common courtesy dictates
     that when formulating a local policy, the participation of the
     level above should be solicited.


     3.4  Minimize the Number of Hats Worn

     Coordinators are encouraged to limit the number of FidoNet
     functions they perform.  In particular, a coordinator's system
     should be readily available to the levels immediately above
     FidoNews 6-14                Page 14                   3 Apr 1989


     and below, and a coordinator should not rule on the appeal of
     his own decision.

     Coordinators are discouraged from acting as echomail and soft-
     ware-distribution hubs.  If they do so, they should handle
     echomail (or other volume distribution) on a system other than
     the administrative system.

     Another reason to discourage multiple hats is the difficulty
     of replacing services if someone leaves the network.  For
     example, if a coordinator is the echomail hub and the soft-
     ware-distribution hub, those services will be  difficult to
     restore when he resigns.

     3.5  Be a Member of the Area Administered

     A coordinator must be a member of the area administered. That
     is, a Network Coordinator must be a member of that network by
     virtue of geography.  A Regional Coordinator must be either a
     member of a network in his region, or an independent of the
     region.


     3.6  Encourage New Sysops to Enter FidoNet

     A coordinator is encouraged to operate a public bulletin board
     system which is freely available for the purpose of distribut-
     ing Policy, FidoNews, and Nodelists to potential new sysops.
     Dissemination of this information to persons who are potential
     FidoNet sysops is important to the growth of FidoNet, and
     coordinators should encourage development of new systems.


     3.7  Tradition and Precedent

     A coordinator is not bound by the practices of his predecessor
     or peers beyond the scope of this document.

     In addition, a new coordinator has the right to review any
     decision made by his predecessors for compliance with Policy,
     and take whatever actions may be necessary to rectify any
     situations not in compliance.


     3.8  Technical Management

     The primary responsibility of any coordinator is technical
     management of network operations.  Decisions must be made on
     technical grounds.



     4  Network Coordinator Procedures

     4.1  Responsibilities

     FidoNews 6-14                Page 15                   3 Apr 1989


     A Network Coordinator has the following responsibilities:

        1) To receive incoming mail for nodes in his network, and
        arrange delivery to its recipients.

        2) To assign node numbers to nodes in his network.

        3) To maintain the nodelist for his network, and to send
        a copy of it to his Regional Coordinator whenever it
        changes.

        4) To make available to his nodes new nodelist difference
        files, new issues of FidoNews, and new revisions of
        Network Policy Documents as they are received, and to
        periodically check to insure that his nodes use up to
        date nodelists.


     4.2  Routing Inbound Mail

     It is your responsibility as Network Coordinator to coordinate
     the receipt and forwarding of host-routed inbound netmail for
     nodes in your network.  The best way to accomplish this is
     left to your discretion.

     If a node in your network is receiving large volumes of mail
     you can request that he cease and desist routing these vol-
     umes.  If he refuses to do so, then you can request your
     Regional Coordinator to assign the node a number as an inde-
     pendent and drop him from your network.

     Occasionally a node will make a "bombing run" (sending one
     message to a great many nodes).  If a node in another network
     is making bombing runs on your nodes and routing them through
     your inbound host, then you can complain to the network coor-
     dinator of the offending node.  (If the node is an indepen-
     dent, complain to the regional coordinator.)  Bombing runs are
     considered to be annoying.

     Another source of routing overload is echomail.  Echomail
     cannot be allowed to degrade the ability of FidoNet to handle
     normal message traffic.  If a node in your network is routing
     large volumes of echomail, you can ask him to either limit the
     amount of echomail or to stop routing his echomail.

     You are not required to forward encrypted, commercial, or
     illegal mail.  However, you must follow the procedures de-
     scribed in section 2.1.7 if you do not forward the mail.


     4.3  Assigning Node Numbers

     It is your responsibility to assign node numbers to new nodes
     in your network.  You may also change the numbers of existing
     nodes in your network, though you should check with your
     member nodes before doing so.  You may assign any numbers you
     FidoNews 6-14                Page 16                   3 Apr 1989


     wish, so long as each node has a unique number within your
     network.

     You must not assign a node number to any system until you have
     received a formal request from that system by FidoNet mail.
     This will ensure that the system is minimally operational.
     The strict maintenance of this policy has been one of the
     great strengths of FidoNet.

     It is also recommended, though not required, that you call a
     board which is applying for a node number before assigning it
     a node number.

     You may not assign a node number to a node in an area covered
     by an existing network.  Further, if you have nodes in an area
     covered by a network in formation, those nodes must be trans-
     ferred to the new network.

     You should use network mail to inform a new node of his node
     number, as this helps to insure that he is capable of receiv-
     ing network mail.

     If a node in your network is acting in a sufficiently annoying
     manner, then you can take whatever action you deem fit, ac-
     cording to the circumstances of the case.


     4.4  Maintaining the Nodelist


     You should to implement name changes, phone number changes,
     and so forth in your segment of the nodelist as soon as possi-
     ble after the information is received from the affected node.
     You should also on occasion send a message to every node in
     your network to ensure that they are operational.  If a node
     turns out to be "off the air" with no prior warning, you can
     either mark the node down or remove it from the nodelist.
     (Nodes are to marked DOWN for a maximum of two weeks, after
     which the line should be removed from the nodelist.)

     At your discretion, you may distribute a portion of this work-
     load to routing hubs.  In this case, you should receive the
     nodelists from the Hub Coordinators within your network.  You
     will need to maintain a set of nodelists for each hub within
     your network, since you cannot count on getting an update from
     each Hub Coordinator every week.  You should assemble a master
     nodelist for your network every week and send it to your
     Regional Coordinator by the day and time he designates.  It is
     suggested that you do this as late as is practical, so as to
     accommodate any late changes, balanced with the risk of miss-
     ing the connection with your Regional Coordinator and thus
     losing a week.

     4.5  Making Available Policies, Nodelists and FidoNews

     As a Network Coordinator you should obtain a new issue of
     FidoNews 6-14                Page 17                   3 Apr 1989


     FidoNews and a new nodelist difference file every week from
     your Regional Coordinator.  The nodelist difference file is
     currently made available each Saturday, and FidoNews is pub-
     lished each Monday.  You must make these files available to
     all nodes in the network, and you are encouraged to make them
     available to the general public for download.

     You should also obtain the most recent versions of the Policy
     documents that bind the members of your network, and make
     those available to the nodes in your network.  Policies are
     released at sporadic intervals, so you should also inform the
     nodes in your network when such events occur, and ensure the
     nodes are generally familiar with the changes.

     Policy, FidoNews, and the nodelist are the glue that holds us
     together.  Without them, we would cease to be a community, and
     become just another random collection of bulletin boards.



     5  Regional Coordinator Procedures

     5.1  Responsibilities

     A Regional Coordinator has the following responsibilities:

        1) To assign node numbers to independent nodes in the
        region.

        2) To encourage independent nodes in the region to join
        existing networks, or to form new networks.

        3) To assign network numbers to networks in the region
        and define their boundaries.

        4) To compile a nodelist of all of the networks and
        independents in the region, and to send a copy of it to
        the Zone Coordinator whenever it changes.

        5) To ensure the smooth operation of networks within the
        region.

        6) To make new nodelist difference files, Policies, and
        issues of FidoNews available to the Network Coordinators
        in the region as soon as is practical.


     5.2  Assigning Node Numbers

     It is your responsibility to assign node numbers to indepen-
     dent nodes in your region. You may also change the numbers of
     existing nodes in your region, though you should check with
     the respective nodes before doing so.  You may assign any
     numbers you wish, so long as each node has a unique number
     within your region.

     FidoNews 6-14                Page 18                   3 Apr 1989


     You should not assign a node number to any system until you
     have received a formal request from that system by FidoNet
     mail.  This will ensure that the system is minimally opera-
     tional.  The strict maintenance of this policy has been one of
     the great strengths of FidoNet.

     It is also recommended, though not required, that you call a
     board which is applying for a node number before assigning it
     a node number.

     You should use network mail to inform a new node of his node
     number, as this helps to insure that he is capable of receiv-
     ing network mail.

     If a node in your region is acting in a sufficiently annoying
     manner, then you can take whatever action you deem fit, ac-
     cording to the circumstances of the case.

     If you receive a node number request from outside your region,
     you must forward it to the most local coordinator for the
     requestor as you can determine.  If you receive a node number
     request from a new node that is in an area covered by an
     existing network, then you must forward the request to the
     Coordinator of that network instead of assigning a number
     yourself.

     If a network forms in an area for which you have independent
     nodes, those nodes will be transferred to the local network as
     soon as is practical.


     5.3  Encouraging the Formation and Growth of Networks

     One of your main duties as a Regional Coordinator is to pro-
     mote the growth of networks in your region.

     You should avoid having independent nodes in your region which
     are within the coverage area of a network.  There are, howev-
     er, certain cases where a node should not be a member of a
     network, such as a system with a large amount of inbound
     netmail; see section 4.2.

     If several independent nodes in your region are in a local
     area you should encourage them to form a network, and if
     necessary you may require them to form a network.  Refer to
     section 2.4.  Note that this is not intended to encourage the
     formation of trivial networks.  Obviously, one node does not
     make a network.  The exact number of nodes required for an
     effective network must be judged according to the circumstan-
     ces of the situation, and is left to your discretion.


     5.4  Assigning Network Numbers

     It is your responsibility to assign network numbers to new
     networks forming within your region.  You are assigned a pool
     FidoNews 6-14                Page 19                   3 Apr 1989


     of network numbers to use for this purpose by your Zone Coor-
     dinator.  As a part of this function, it is the responsibility
     of the Regional Coordinator to define the boundaries of the
     networks in the region.


     5.5  Maintaining the Nodelist

     As a Regional Coordinator, you have a dual role in maintaining
     the nodelist for your region.

     First, you must maintain the list of independent nodes in your
     region.  You should attempt to implement name changes, phone
     number changes, and so forth in this nodelist as soon as
     possible.  You should also on occasion send a message to every
     independent node in your region to ensure that they are opera-
     tional.  If a node turns out to be "off the air" with no prior
     warning, you can either mark the node down or remove it from
     the nodelist.  (Nodes are to marked DOWN for a maximum of two
     weeks, after which the line should be removed from the node-
     list.)

     Second, you must receive the nodelists from the Network Coor-
     dinators within your region.  You will need to maintain a set
     of nodelists for each network within your region, since you
     cannot count on getting an update from each Network Coordina-
     tor every week.  You should assemble a master nodelist for
     your region every week and send it to your Zone Coordinator by
     the day and time he designates.  It is suggested that you do
     this as late as practical, so as to accommodate late changes,
     balanced with the risk of missing the connection with your
     Zone Coordinator and thus losing a week.


     5.6  Geographic Exemptions

     There are cases where local calling geography does not follow
     FidoNet regions.  In exceptional cases, exemptions to normal
     geographic guidelines are agreed upon by the Regional Coordi-
     nators and Zone Coordinator involved.  Such an exemption is
     not a right, and is not permanent.  When a network is formed
     in the proper region that would provide local calling access
     to the exempted node, it is no longer exempt.  An exemption
     may be reviewed and revoked at any time by any of the coordi-
     nators involved.


     5.7  Overseeing Network Operations

     It is your responsibility as Regional Coordinator to ensure
     that the networks within your region are operating in an ac-
     ceptable manner.  This does not mean that you are required to
     operate those networks; that is the responsibility of the
     Network Coordinators.  It means that you are responsible for
     assuring that the Network Coordinators within your region are
     acting responsibly.
     FidoNews 6-14                Page 20                   3 Apr 1989


     If you find that a Network Coordinator within your region is
     not properly performing his duties (as outlined in Section 4),
     then you should take whatever action you deem necessary to
     correct the situation.

     If a network grows so large that it cannot reasonably accommo-
     date traffic flow during the Zone Mail Hour, the Regional
     Coordinator can direct the creation of one or more new net-
     works from that network.  These new networks, although they
     may be within a single local-calling area, must still conform
     to a geographical basis for determining membership.

     It is your obligation as Regional Coordinator to maintain
     direct and reasonably frequent contact with the networks in
     your region. The exact method of accomplishing this is left to
     your discretion.


     5.8  Making Available Nodelists, Policies, and FidoNews

     As a Regional Coordinator, it is your responsibility to obtain
     the latest nodelist difference file, network policies, and the
     latest issues of FidoNews as they are published, and to make
     them available to the Network Coordinators within your region.
     The nodelist is posted weekly on Saturday by the Zone Coordi-
     nator, and FidoNews is published weekly on Monday by node 1/1.
     Contact them for more details on how to obtain the latest
     copies each week.

     It is your responsibility to make these available to all Net-
     work  Coordinators in your region as soon as is practical
     after you receive them.  The method of distribution is left to
     your discretion.  You are not required to distribute them to
     any independent nodes in your region, though you may if you
     wish.  You are encouraged to make all these documents avail-
     able for downloading by the general public.



     6  Zone Coordinator Procedures

     6.1  General

     A Zone Coordinator for FidoNet has the primary task of main-
     taining the nodelist for his Zone, sharing it with the other
     Zone Coordinators, and ensuring the distribution of the master
     nodelist (or difference file) to the Regions in his Zone.  He
     is also responsible for coordinating the distribution of
     Network Policy documents and FidoNews to the Regional Coordi-
     nators in his zone.

     The Zone Coordinator is responsible for the maintenance of the
     nodelist for his administrative region.  The Administrative
     Region has the same number as his zone, and consists of nodes
     assigned for administrative purposes not related to the send-
     ing and receiving of normal network mail.
     FidoNews 6-14                Page 21                   3 Apr 1989


     A Zone Coordinator is charged with the task of ensuring the
     smooth operation of his Zone.  He does this by supervising the
     Regional Coordinators.

     If a Zone Coordinator determines that a Regional Coordinator
     is not properly performing his duties (as outlined in section
     5), he should seek a replacement for that Regional Coordina-
     tor, or take other action as he sees fit.

     The Zone Coordinator defines the geographic boundaries of the
     regions within  his zone and sets the time for the Zone Mail
     Hour.

     The Zone Coordinator is responsible for reviewing and approv-
     ing any geographic exemptions as described elsewhere in this
     document.

     The Zone Coordinator is responsible for insuring the smooth
     operation of gates between his zone and all other zones for
     the transfer of interzonal mail.

     The Zone Coordinators are responsible for the selection of the
     International Coordinator from among their ranks.


     6.2  Selection

     The Zone Coordinator is selected by an absolute majority vote
     of the Regional Coordinators within his zone.


     7  International Coordinator Procedures

     7.1  General

     The International Coordinator is the "first among equals" Zone
     Coordinator.

     The International Coordinator has the primary task of coordi-
     nating the creation of the master nodelist by managing the
     distribution between the Zones of the Zone nodelists.  The
     International Coordinator is responsible for definition of new
     zones and for negotiation of agreements for communication with
     other networks.  ("Other network" in this context means other
     networks with which FidoNet communicates as peer-to-peer, not
     "network" in the sense of the FidoNet organizational level.)

     The International Coordinator is also responsible for coordi-
     nating the distribution of Network Policies and FidoNews to
     the Zone Coordinators.

     The International Coordinator is responsible for coordinating
     the activities of the Zone Coordinator Council.  The Interna-
     tional Coordinator acts as the spokesman for the Zone Coordi-
     nator Council.

     FidoNews 6-14                Page 22                   3 Apr 1989


     In cases not specifically covered by this document, the Inter-
     national Coordinator may issue specific interpretations or
     extensions to this policy.  The Zone Coordinator Council may
     reverse such rulings by a majority vote.

     7.2  Selection

     The International Coordinator is selected (or removed) by an
     absolute majority vote of the Zone Coordinators.


     8  Referenda

     The procedures described in this section are used to ratify a
     new version of FidoNet policy, which is the mechanism by which
     policy is changed.  This procedure is also used to impeach a
     Zone Coordinator.


     8.1  Initiation

     A referendum on policy modification is invoked when a majority
     of the FidoNet Regional Coordinators inform the International
     Coordinator that they wish to consider a proposed new version
     of Policy.


     8.2  Announcement and Results Notification

     Proposed changes to Policy are distributed using the same
     structure which is used to distribute nodelist difference
     files and FidoNews.  Results and announcements related to the
     referendum are distributed by the coordinator structure as a
     part of the weekly nodelist difference file.  The Interna-
     tional Coordinator provides copies to the editor of FidoNews
     for inclusion there, although the official announcement and
     voting dates are tied to nodelist distributions.

     If it is adopted, the International Coordinator sets the
     effective date for a new policy through announcement in the
     weekly nodelist difference file.  The effective date will be
     not more than one month after the close of balloting.


     8.3  Eligibility to Vote

     Each member of the FidoNet coordinator structure at and above
     Network Coordinator is entitled to one vote.  (Hub coordina-
     tors do not vote.)  In the case of the position changing hands
     during the balloting process, either the incumbent or the new
     coordinator may vote, but not both.

     Network coordinators are expected to assess the opinions of
     the members of their network, and to vote accordingly.  A
     formal election is not necessary, but the network coordinator
     must inform the net of the issues and solicit input.  The
     FidoNews 6-14                Page 23                   3 Apr 1989


     network coordinator functions as the representative of the
     rank and file members of FidoNet.


     8.4  Voting Mechanism

     The actual voting mechanism, including whether the ballot is
     secret and how the ballots are to be collected, verified, and
     counted, is left to the discretion of the International Coor-
     dinator.  Ideally, ballot collection should be by some secure
     message system, conducted over FidoNet itself.

     In order to provide a discussion period, the announcement of
     any ballot must be made at least two weeks before the date of
     voting commencement.  The balloting period must be at least
     two weeks.


     8.5  Voting is on a whole Policy Document

     Given that Policy is intertwined and self referencing, a rela-
     tively simple change may require several alterations of the
     document.  In order to simplify the process, balloting is done
     on choices between whole documents, rather than individual
     amendments.  In the simplest case, this means voting yea or
     nay to a new document.  If a number of alternatives are to be
     considered,  they must be presented as whole documents, from
     which one is chosen.


     8.6  Dual Majorities

     A Policy amendment is considered in force if, at the end of
     the balloting period, it has received a majority of the votes
     cast, and has received a majority of the network-coordinator
     votes cast, and has received a majority of the regional-coor-
     dinator votes cast.

     In the case of multiple policy changes which are considered on
     the same ballot, a version must receive more than 50% of the
     votes cast to be considered ratified.  "Abstain" is a valid
     vote in this case, effectively being a vote for not changing
     the current policy as it simply increases the number of votes
     required to ratify the proposed change.


     8.7  Impeachment of a Zone Coordinator

     8.7.1  Initiation

     In extreme cases, a Zone Coordinator may be impeached by
     referendum.  Impeachment of a Zone Coordinator does not re-
     quire a Policy violation.  An impeachment proceeding is in-
     voked when a majority of the Regional Coordinators in a zone
     request the International Coordinator to institute it.

     FidoNews 6-14                Page 24                   3 Apr 1989


     8.7.2  Procedure as in Policy Referendum

     The provisions of sections 8.2 and 8.3 apply to impeachment
     referenda.

     The dual majority described in section 8.6 applies.  Only
     coordinators in the affected zone vote (even if the zone
     coordinator is also the International Coordinator).

     8.7.3  Voting Mechanism

     The balloting procedures are set, the votes are collected, and
     the results are announced by a Regional Coordinator chosen by
     the Zone Coordinator who is being impeached.  The removal of
     the Zone Coordinator is effective two weeks after the end of
     balloting if the impeachment carries.

     8.7.4  Limited to once per year

     The removal of a Zone Coordinator is primarily intended to be
     a mechanism by which the net as a whole expresses displeasure
     with the way Policy is being interpreted.  At one time or
     another, everyone is unhappy with the way policy is inter-
     preted.  In order to keep the Zone Coordinators interpreting
     policy as opposed to defending themselves, at least one full
     calendar year must elapse between impeachment referenda (re-
     gardless of how many people hold the position of Zone Coor-
     dinator during that year.)

     Should a Zone Coordinator resign during an impeachment pro-
     cess, the process is considered null and void, and does not
     consume the "once per year quota".


     9  Resolution of Disputes

     9.1  General

     The FidoNet judicial philosophy can be summed up in two rules:

          1) Thou shalt not excessively annoy others.

          2) Thou shalt not be too easily annoyed.

     In other words, there are no hard and fast rules of conduct,
     but reasonably polite behavior is expected.  Also, in any
     dispute both sides are examined, and action could be taken
     against either or both parties. ("Judge not, lest ye be
     judged!")

     The coordinator structure has the responsibility for defining
     "excessively annoying".  Like a common definition of pornogra-
     phy ("I can't define it, but I know it when I see it."), a
     hard and fast definition of acceptable FidoNet behavior is not
     possible.  The guidelines in this policy are deliberately
     vague to provide the freedom that the coordinator structure
     FidoNews 6-14                Page 25                   3 Apr 1989


     requires to respond to the needs of a growing and changing
     community.

     The first step in any dispute between sysops is for the sysops
     to attempt to communicate directly, at least by netmail,
     preferably by voice.  Any complaint made that has skipped this
     most basic communication step will be rejected.

     Filing a formal complaint is not an action which should be
     taken lightly.  Investigation and response to complaints
     requires time which coordinators would prefer to spend doing
     more constructive activities.  Persons who persist in filing
     trivial policy complaints may find themselves on the wrong
     side of an annoying-behavior complaint.  Complaints must be
     accompanied with verifiable evidence, generally copies of
     messages; a simple word-of-mouth complaint will be dismissed
     out of hand.

     Failure to follow the procedures herein described (in particu-
     lar, by skipping a coordinator, or involving a coordinator not
     in the appeal chain) is in and of itself annoying behavior.


     9.2  Problems with Another Node

     If you are having problems with another node, you should first
     try to work it out via netmail or voice conversation with the
     other sysop.

     If this fails to resolve the problem, you should complain to
     your Network Coordinator and his Network Coordinator.  If one
     or both of you is not in a network, then complain to the
     appropriate Regional Coordinator.  Should this fail to provide
     satisfaction, you have the right to follow the appeal process
     described in section 9.5.


     9.3  Problems with your Network Coordinator

     If you are having problems with your Network Coordinator and
     feel that you are not being treated properly, you are entitled
     to a review of your situation.  As with all disputes, the
     first step is to communicate directly to attempt to resolve
     the problem.

     The next step is to contact your Regional Coordinator. If he
     feels that your case has merit, there are several things he
     may do.  For example, he may order a change of Network Coordi-
     nators, or even the disbanding of your network, though this is
     unlikely.  If you have been excommunicated by your Network
     Coordinator, that judgement may be reversed, at which point
     you will be reinstated into your net.

     If you fail to obtain relief from your Regional Coordinator,
     you have the right to follow the appeal process described in
     section 9.5.
     FidoNews 6-14                Page 26                   3 Apr 1989


     9.4  Problems with Other Coordinators

     Complaints concerning annoying behavior on the part of any
     coordinator are treated as in section 9.2 and should be filed
     with the next level of coordinator.  For example, if you feel
     that your Regional Coordinator is guilty of annoying behavior
     (as opposed to a failure to fulfill his duties as a coordina-
     tor) you should file your complaint with the Zone Coordinator.

     Complaints concerning the performance of a coordinator in
     carrying out the duties mandated by policy are accepted only
     from the level immediately below.  For example, complaints
     concerning the performance of Regional Coordinators would be
     accepted from Network Coordinators and independents in that
     region.  Such complaints should be addressed to the Zone
     Coordinator after an appropriate attempt to work them out by
     direct communications.


     9.5  Appeal Process

     A decision made by a coordinator may be appealed to the next
     level.  Appeals must be made within two weeks of the decision
     which is being appealed.  All appeals must follow the chain of
     command; if levels are skipped the appeal will be dismissed
     out of hand.

     An appeal will not result in a full investigation, but will be
     based upon the documentation supplied by the parties at the
     lower level.  For example, an appeal of a Network Coordina-
     tor's decision will be decided by the Regional Coordinator
     based upon information provided by the coordinator and the
     sysop involved; the Regional Coordinator is not expected to
     make an independent attempt to gather information.

     The appeal structure is as follows:

        Network Coordinator decisions may be appealed to the
        appropriate Regional Coordinator.

        Regional Coordinator decisions may be appealed to the
        appropriate Zone Coordinator.  At this point, the Zone
        Coordinator will make a decision and communicate it to
        the Regional Coordinators in that zone.  This decision
        may be reversed by a majority vote of the Regional Coor-
        dinators.

        Zone Coordinator decisions may be appealed to the Inter-
        national Coordinator.  The International Coordinator will
        make a decision and communicate it to the Zone Coordina-
        tor Council, which may reverse it by majority vote.

     If your problem is with a Zone Coordinator per se, that is, a
     Zone Coordinator has committed a Policy violation against you,
     your complaint should be filed with the International Coordi-
     nator, who will make a decision and submit it to the Zone
     FidoNews 6-14                Page 27                   3 Apr 1989


     Coordinator Council for possible reversal, as described above.


     9.6  Statute of Limitations

     A complaint may not be filed more than 60 days after the date
     of discovery of the source of the infraction, either by admis-
     sion or technical evidence.  Complaints may not be filed more
     than 120 days after the incident unless they involve explicit-
     ly illegal behavior.


     9.7  Right to a Speedy Decision

     A coordinator is required to render a final decision and
     notify the parties involved within 30 days of the receipt of
     the complaint or appeal.


     9.8  Return to Original Network

     Once a policy dispute is resolved, any nodes reinstated on
     appeal are returned to the local network or region to which
     they geographically or technically belong.


     9.9  Echomail

     Echomail is an important and powerful force in FidoNet.  For
     the purposes of Policy Disputes, echomail is simply a differ-
     ent flavor of netmail, and is therefore covered by Policy.  By
     its nature, echomail places unique technical and social de-
     mands on the net over and above those covered by this version
     of Policy.  In recognition of this, an echomail policy which
     extends (and does not contradict) general Policy, maintained
     by the Echomail Coordinators, and ratified by a process simi-
     lar to that of this document, is recognized by the FidoNet
     Coordinators as a valid structure for dispute resolution on
     matters pertaining to echomail.  At some future date the
     echomail policy document may be merged with this one.


     9.10  Case Histories

     Most of FidoNet Policy is interpretive in nature.  No one can
     see what is to come in our rapidly changing environment.
     Policy itself is only a part of what is used as the ground
     rules for mediating disputes -- as or more important are the
     precedents.

     In order to accommodate this process, case histories may be
     added to or removed from this document by the International
     Coordinator, with such a revision subject to reversal by the
     Zone Coordinator Council.  Should Policy be amended in such a
     way to invalidate a precedent, Policy supersedes said prece-
     dent.  (A carefully prepared amendment would address this by
     FidoNews 6-14                Page 28                   3 Apr 1989


     removing the precedent reference as a part of the amendment.)

     Although a case may be removed, the text of a case history may
     not be modified by any mechanism.  Case history is written
     close to the time of the decision, by those involved with it.
     Amending the text of a case history is the same as revising
     history, something quite inappropriate in an organization
     dedicated to moving information.



     10  Appendices

     10.1  General

     The Appendices of this document are exceptions to the normal
     ratification process.  Section 10.2 can be changed by the
     appropriate Zone Coordinator, and section 10.3 may be modified
     by the International Coordinator (see Section 9.10).


     10.2  Timing of Zone Mail Hour

     Zone Mail Hour is observed each day, including weekends and
     holidays.  The time is based upon Universal Coordinated Time
     (UTC), also known as Greenwich Mean time (GMT).  In areas
     which observe Daylight Savings Time during part of the year,
     the local time of zone mail hour will change because FidoNet
     does not observe Daylight Savings Time. The exact timing of
     Zone Mail Hour is set for each zone by the Zone Coordinator.

     In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to
     1000 UTC.  In each of the time zones, this is:

          Eastern Standard Time          4 AM to 5 AM
          Central Standard Time          3 AM to 4 AM
          Mountain Standard Time         2 AM to 3 AM
          Pacific Standard Time          1 AM to 2 AM
          Hawaii Standard Time          11 PM to Midnight

     In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to
     0330 UTC.

     In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to
     1900 UTC.  In each of the time Zones involved this is:


       GMT +12 Zone                        6:00 AM to 7:00 AM
       (New Zealand)

       GMT +10 Zone                        4:00 AM to 5:00 AM
       (East Australia)
       (Papua New Guinea)
       (Micronesia)

       GMT +9.5 Zone                       3:30 AM to 4:30 AM
     FidoNews 6-14                Page 29                   3 Apr 1989


       (Central Australia)

       GMT +9 Zone                         3:00 AM to 4:00 AM
       (Japan)
       (Korea)
       (Eastern Indonesia)

       GMT +8 Zone                         2:00 AM to 3:00 AM
       (Hong Kong)
       (Taiwan)
       (Central Indonesia)
       (Philippines)

       GMT +7 Zone                         1:00 AM to 2:00 AM
       (Malaysia)
       (Singapore)
       (Thailand)
       (Western Australia)
       (Western Indonesia)


     10.3  Case Histories


     Case histories of past disputes are instructive to show gener-
     al procedures and methods.  Any decision may be included in
     this document by a majority vote of either the Zone Coordina-
     tor Council or the Regional Coordinators.

     Policy4 significantly changes the functions of the Zone and
     International Coordinators.  In the following cases which were
     decided using Policy3, substitute "Zone Coordinator" for all
     occurrences of "International Coordinator(*)".


     10.3.1  The Case of the Crooked Node

     A sysop of a local node was using network mail to engage in
     unethical business practices.  His Network Coordinator became
     very annoyed at this, and dropped the local from his nodelist.

     The local appealed to his Regional Coordinator for assignment
     as an independent node.  The Regional Coordinator, after
     checking with the Network Coordinator, decided that the Net-
     work Coordinator was right to be annoyed.  Independent status
     was denied.

     The International Coordinator(*) did not intervene.


     10.3.2  The Case of the Hacker Mailer

     A sysop of a local node made use of file attaches for extra
     users to mail himself the USER.BBS file from several local
     boards.  The sysops of these boards felt annoyed at this, and
     appealed to their Network Coordinator, who agreed and dropped
     FidoNews 6-14                Page 30                   3 Apr 1989


     the offending node from the nodelist.

     The Regional Coordinator was not consulted.

     The International Coordinator(*) did not intervene.


     10.3.3  The Case of the Bothered Barker

     A local node became annoyed with his Network Coordinator for
     failing to provide services.  Repeated complaints to his Net-
     work Coordinator did not satisfy him, so he appealed to the
     International Coordinator(*).

     The International Coordinator(*) dismissed the complaint
     because the Regional Coordinator had not been consulted.

     The local node submitted his complaint to his Regional Coordi-
     nator, who investigated the case and discovered that there was
     some justice to the complaint.  He advised and assisted the
     Network Coordinator in configuring his system to provide an
     improved level of service to the local nodes.

     The Regional Coordinator also decided that the local node was
     being too easily annoyed, in that he was expecting services
     not normally required of a Network Coordinator.  The local
     node was informed as to the true duties of a Network Coordina-
     tor, and was advised to lower his expectations.


     10.3.4  The Case of the Busy Beaver

     A local node which was operated by a retail establishment was
     engaged in making "bombing runs" to mail advertisements over
     FidoNet.  His Network Coordinator felt annoyed and handling
     the outgoing traffic for a commercial operation, and asked the
     local node to leave the network.

     The local node applied to the Regional Coordinator, and was
     granted status as an independent node in his region.


     10.3.5  The Mark of the Devil

     A local sysop whose board was used in conjunction with voodoo
     rites, hacking, phreaking, and obscene material applied to a
     Network Coordinator for a node number.  The Network Coordina-
     tor deemed that this board was exceptionally annoying, and
     denied the request.

     The Regional Coordinator was not consulted.

     The International Coordinator(*), on seeing that the Regional
     Coordinator had not been consulted, dismissed the case out of
     hand.  No further appeals were made.

     FidoNews 6-14                Page 31                   3 Apr 1989


     10.3.6  The Case of the Sysop Twit

     A patron of various local nodes had been roundly recognized by
     all sysops as a twit.  The user obtained his own system,
     became a sysop, and applied for a node number.  The Network
     Coordinator denied the request.  No appeals were made.


     10.3.7  The Case of the Echomail Junkie

     A local node became enamored with echomail and joined several
     conferences, routing his outbound mail through his network.
     He then started an echomail conference of his own and began
     relaying echomail between several systems, again routing it
     all through his network.

     His Network Coordinator observed that network performance was
     becoming seriously impaired.  The offending node was told to
     hold it down.  A compromise was reached whereby much of the
     echomail traffic was no longer routed through the network, and
     routed echomail was limited to twenty messages per night.  No
     appeals were made.


     10.3.8  The Case of the Bouncing Board

     A local user decided to establish a node to promote a worthy
     charity.  The machine being used was also used for various
     other activities during the day, and the sysop was often
     called away.  His coworkers would often forget to bring the
     board up at the end of the day while he was away, so the node
     was often down for extended periods.  The Network Coordinator,
     finding the node unable to receive mail, would mark it down.
     The sysop would return, restart the board, and ask to be
     reinstated.

     The Network Coordinator eventually decided that the sysop was
     not able to maintain a reliable system, and removed him from
     the nodelist completely.  Subsequent requests for a node
     number from the same sysop were turned down.  No appeals were
     made.


     10.5  Credits, acknowledgments, etc.

     Fido and FidoNet are registered trademarks of Fido Software,
     Inc.




                                          Index

     -1/-1,  2.3
     Additional mail events in local network  2.1.8
     Administrative Region  6.1
     FidoNews 6-14                Page 32                   3 Apr 1989


     Advantages to network membership  2.2
     Alteration of mail  2.1.5
     Answering machine  2.3
     Announcement of voting results 8.2
     Annoying behavior  1.3.5, 1.4.8, 2.1.1, 2.1.2, 2.1.4, 2.1.6,
          2.1.7, 2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
     Appeal chain  9.5
     Availability of NodeList  1.3.4
     Balloting Period  8.4
     Bombing run  4.2
     BossNode  1.2.1
     Boundaries  1.3.2
     Calling areas  1.3.2, 5.6, 5.7
     Case histories  9.10, 10.3
     Changing node numbers  4.3, 5.2
     Commercial messages  2.1.4, 4.2
     Contributions to FidoNews  1.3.1
     Current nodelist  2.1.11
     Daylight Savings Time  2.1.14
     Difference file  4.5, 5.8, 8.2
     Disclosing private mail  2.1.6
     Discussion period  8.2
     Disputes  9
     Distribution of ballots  8.2
     Down  2.3, 4.4, 5.5
     Downloading by users  3.6, 4.5, 5.8
     Dual majority  8.6, 8.7.2
     EchoMail  1.4.5, 4.2, 9.9
     Effective date (policy change)  8.2
     Elections  1.4.1
     Eligibility to vote  8.3
     Encryption  2.1.4, 4.2
     Exceptions  5.6
     Excessively annoying behavior  1.3.5, 1.4.8, 2.1.1, 2.1.2, 2.1.4,
          2.1.6, 2.1.7, 2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
     Exclusivity of Zone Mail Hour  2.1.8
     Excommunication  2.1.12, 4.3, 5.2, 9
     Exemptions, node location  1.3.2, 5.6
     Familiarity with policy  2.1.2, 2.2
     FidoNet, definition  1.2.6
     FidoNews  1.3.1
          availability 3.1, 4.5, 5.8
     FTSC  2.4
     Gateway  2.1.3
     Geography  1.3.2, 5.6
     Glue  4.5
     Hats  3.4
     Host-routed mail  4.2
     How to obtain a node number  2.2
     Hub  1.4.6  4.4
     Illegal behavior  2.1.1, 9.6
     Illegal mail  4.2
     Impeachment  8.7
     In-transit mail  2.1.6.1
     Independent node  4.2, 5.2
     Inter-zonal questions  1.4.2
     FidoNews 6-14                Page 33                   3 Apr 1989


     International Coordinator  1.4.1, 1.4.9, 7
     International FidoNet Association  1.2.6
     Language  1.0
     Levels of FidoNet  1.2, 1.4
     Local calling areas  1.3.2
     Local policies  1.2, 3.3
     Mail  1.4.5, 4.2
     Majority  8.6, 8.7.2
     Member of area administrated  3.5
     Modification of mail  2.1.5
     National Mail Hour  see Zone Mail Hour
     Network
          advantages 2.2
          boundaries 1.3.2, 5.4
          definition 1.2.3
          forming 2.4, 5.3
          hub 1.4.6, 4.4
          numbers 2.2, 5.4
     Network Coordinator  1.4.5
          procedures 4
          replacement 5.7, 9.3
     Network Mail Hour  see Zone Mail Hour
     New sysops  2.1.2, 3.6
     Node numbers  4.3, 5.2
        obtaining  2.2
     Nodelist  1.3.4, 2.2, 4.4, 5.5
          availability 3.1, 4.5, 5.8
          changes 4.4, 5.2
          current 2.1.11
          definition 1.3.4
          format 10.3
          official 1.3.4
     Nodes
          definition 1.2.2
          down 2.3
     Observing mail events  2.1.8, 2.1.10
     Obtaining a node number  2.2
     Offensive messages  2.1.5
     Partial nodelist  1.3.4
     Pirated software  2.1.1
     Point of origin  2.1.3
     Points  1.2.1, 1.4.8, 2.1.3
     Policy  3.1, 3.3, 4.5, 5.8
          changing 8
          familiarity with 2.1.2, 2.2
          local 1.2, 3.3
     Precedent  3.7, 9.10, 10.3
     Private messsages  2.1.6
     Private network  1.2.1
     Private nodes  2.1.9
     Problem resolution  9
     Public BBS  3.6
     Ratification  7.1
     Referendum  1.4.1, 8
     Regional Coordinator  1.4.4
          procedures 5
     FidoNews 6-14                Page 34                   3 Apr 1989


          replacement 6.1, 9.4
     Regions  1.2.4
     Replacement of coordinators  1.4.9
     Replacing services  3.4
     Requirements to be in NodeList  1.3.4, 2.1.2, 2.2
     Resignation of ZC  8.7.4
     Resolution of disputes  9
     Results Announcement  8.2
     Review of decisions  3.7
     Review of routed traffic  2.1.4
     Routing  2.1.4 - 2.1.7, 4.2
     Routing Hub  1.4.6, 4.4
     Rules  9.1
     Speedy decision  9.7
     Statute of limitations  9.6
     Submissions to FidoNews  1.3.1
     Sysop procedures  2
     System operator (sysop)  1.4.7
     Three-tiered networks  1.4.6
     Time limit on decision  9.7
     Timing of Zone Mail Hour  2.1.13, 2.1.14, 10.2
     Top-down  1.4.9
     Tradition  3.7
     Trivial network  5.3
     Unattended systems  2.3
     Updates to nodelist  3.2
     User  1.4.8
     User access during ZMH  2.1.8
     Vacation  2.3
     Vote  8
          eligibility 8.3, 8.7.2
     ZMH see Zone Mail Hour
     Zone Coordinator  1.4.3, 6
          election 1.4.9, 6.2
          impeachment 8.7
          procedures 6
          removal 6.2
          resignation during impeachment 8.7.4
     Zone Coordinator Council  1.4.2, 7.1
     Zone Mail Hour  1.3.3, 2.1.8
          timing 2.1.13, 2.1.14, 10.2
     Zones
          definition 1.2.5
          new 1.4.2
          unique 1.3.2







     -----------------------------------------------------------------
     FidoNews 6-14                Page 35                   3 Apr 1989


     Jeff Sheese, JStek BBS
     Fidonet 1:109/116   (Netmail HOST routed via 1:109/100)
     EggNet 99:9200/1    (Netmail HOST routed via 99:9200/0)

       ZOW, Yet Another Fantastically New File Packer! (Part 2 of 2)

     Yes, yet ANOTHER fantastically new file packer is about to hit
     the public domain software scene!

     If you read last week's Fidonews article about ZOW, your probably
     wondering how I can do all this wonderful stuff in one program.
     Well, here is the English psuedo-code that I used to develop the
     software package.  Remember, I mentioned that ZOW formats are
     public domain!

     1.   The command line for calling ZOW is "ZOW cmd FILENAME.EXT",
          where 'cmd' is GET or PUT.
     2.   To pack a file of any given size to only 2K one must issue
          the command "ZOW PUT FILENAME.EXT".
     3.   To retrieve a file from it's ZOW format, one must issue the
          command "ZOW GET FILENAME.EXT".
     4.   ZOW parses the command line to determine the command,
          whether it be GET or PUT.
     5.   Method for PUT, or packing the data file:
          a.   ZOW parses the command line to get the filename and
               extender.
          b.   ZOW creates the file "FILENAME.ZOW", using ZOW as the
               filename extender.
          c.   ZOW stores a copyright notice, starting at the
               beginning of "FILENAME.ZOW", ending with an ASCII end
               of file mark.  This is so that anyone using the TYPE
               command to list the contents of the ZOW formatted file
               will see that it's a ZOW file.
          d.   ZOW stores the original "FILENAME.EXT" after the ASCII
               end of file mark.
          e.   ZOW fills the rest of the 2048 byte "FILENAME.ZOW" file
               with random numbers.  The amount of time to do this is
               determined by a random number generator, seeded with
               the number equal to the size of the original file.
          f.   ZOW closes "FILENAME.ZOW".
          g.   ZOW changes the attributes of "FILENAME.ZOW" so that
               it's a SYSTEM, HIDDEN, READ-ONLY file.

     Next the user does a directory of the floppy disk.  Notice that
     "FILENAME.EXT" is gone and "FILENAME.ZOW" is in it's place?  Also
     notice that "FILENAME.ZOW" is only 2048 bytes long!

     I'm really excited about my new file packer!  As a matter of fact
     I'm going to call a lawyer tomorrow and copyright it!  Forget you
     saw the English Pseudo code!  *I* own it now!  I can make a lot
     of money off this thing and it's mine, all mine!!!  By the time
     you read this I would have copyrighted it!  i'm going to
     copyright it so all you joust queens can forget you ever saw
     it!!!!!!!  forget i said anything about public domain!!!!!!!!
     public domain is for the birds!!!! get real!!!! get a life!!!!

     FidoNews 6-14                Page 36                   3 Apr 1989


                          DENIAL OF COPYRIGHTS

          This article has been provided pursuant to absolutely no
     License Agreement containing restrictions on its use.  This
     article contains all valuable trade secrets and proprietary
     information of JStek Enterprises and is not protected by Federal
     Copyright Law.  It may be copied or distributed in any form or
     medium, disclosed to third parties, or used in any manner not
     provided for in the aforementioned nonexistant License Agreement
     except without prior written authorization from JStek
     Enterprises.

          This article is the property of JStek Enterprises (who has
     their own FedEx account!) as its created work.  This work
     includes certain individual portions provided to JStek
     Enterprises by operators and users of the JStek Bulletin Boards.
     JStek has the right to create and distribute these articles
     based, in part, on rights granted to it by those originating such
     portions.  Other than the rights granted JStek, those creating
     and maintaining the portions retain all residual rights in and to
     each's individual portion.  Specific manure rights are hereby
     granted to whomever wants to clean up the mess.

          Everyone is granted any right to use, sale, duplication or
     distribution of this article for any commercial purpose.  I
     figure if your willing to copy it and present it as your own, I
     must have done something right!

          (This article may be reproduced without permission and may
          also be excerpted out of context in a misleading way. -jes)

     -----------------------------------------------------------------
     FidoNews 6-14                Page 37                   3 Apr 1989


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

     The Veterinarian's Corner
     Excerpts from the ANIMED GroupMail Conference

     by Don Thomson, 1:102/1005

     With the winter weather, and more of us traveling to the ski
     slopes, the proper antifreeze in the radiator can be a lifesaver.
     Unfortunately, many 'do-it-yourselfers' who will do the radiator
     flushes and replace the old coolant with new antifreeze are
     unaware that Ethylene Glycol based antifreezes are highly toxic.

     Ethylene glycol, which acts to lower the freezing point of
     radiator coolant (and also raises the boiling point), is
     particularly attractive to animals.  It has a sweet taste, and if
     simply drained into the street gutter, or into an open catch pan
     where an animal can lap it up, may spell kidney failure in short
     order.

     The first signs of ethylene glycol poisoning are a 'drunken'
     incoordination, but as the agent is metabolized by the liver, it
     becomes a potent toxin for the kidneys.  Treatment must be
     initiated extremely early or severe damage will be done.  Very
     few pets recover without prolonged dialysis if the initial
     poisoning is not treated immediately with the appropriate
     antidotes.

       This is DEFINATELY one case where PREVENTION is paramount!

     DB Thomson, DVM
     1:102/1005
     9:871/16



     -----------------------------------------------------------------
     FidoNews 6-14                Page 38                   3 Apr 1989


     =================================================================
                           LETTERS TO THE EDITOR
     =================================================================

     From: Robert Heller @ 1:321/153.0 (Locks Hill BBS, Wendell, Mass)
     Subject:  "Will ZIP Replace ARC?" (Article by John Herro 1:363/6,
               in FidoNews V6 #11)
     Date: Sat Mar 25, 1989 12:18:24.58

     I'd like to say a few words on the whole "compression wars" that
     has been going on for some time now in various forums.

     Most of the "new" compression/packing/archiving programs only
     run on MS-DOS systems (i.e. Intel 8086 derived systems).  Of the
     many (I have not counted recently) computers I use, both at home
     (2) and at work (many others), only one has a Intel 8086 derived
     CPU, and it does not run MS-DOS.  The computer my BBS runs on is
     a 68000-based system (it presently runs CP/M-68K and will be soon
     running OS-9/68000).   There are only two archiver program that
     runs on all of them (more or less): ARC 5.12 and Zoo (2.01).  ARC
     was an extreem pain to port out of the MS-DOS world (it was not
     written in a portable fashion).  I ported Zoo to OS-9/68000 very
     easily.  While Zoo may not be the fastest (or the tightest)
     packer, it does fairly well.  ARC 5.12 tends to run like a dog
     and does not pack the best, but it is an old program.

     Because I have no way of verifying them, I won't be supporting
     the use of .ZIP files on my bbs.  I do not think it is a good
     idea to make a packing method a "standard" until some effort has
     gone into making software that can handle the proposed "standard"
     archives under many (if not most/all) different operating systems
     and processor types.  ARC was ported in self-defense (with great
     difficulty in some cases).  Zoo was written with the idea of
     being ported to different operating systems, compilers, and
     processor types.  Unless/until the same can be said of PKZIP or
     any of the other "new" compression/packer/archiver programs, I
     don't think we should be talking about establishing standards as
     yet.

     Comments, questions, etc. welcome.

                           Robert Heller
                ARPANet:   Heller@cs.umass.edu
                BITNET:    Heller@UMass.BITNET
                FidoNet:   1:321/153.0 (Locks Hill BBS,
                                        1-508-544-8337,
                                        300/1200/2400 BAUD)
                BIX:       locks.hill.bbs



     -----------------------------------------------------------------
     FidoNews 6-14                Page 39                   3 Apr 1989


     =================================================================
                              LATEST VERSIONS
     =================================================================

                          Latest Software Versions

                           Bulletin Board Software
     Name        Version    Name        Version    Name       Version

     Fido            12k*   Opus          1.03b    TBBS           2.1
     QuickBBS       2.03    TPBoard         5.0    TComm/TCommNet 3.4*
     Lynx           1.22    Phoenix         1.3    RBBS         17.1D


     Network                Node List              Other
     Mailers     Version    Utilities   Version    Utilities  Version

     Dutchie       2.90C*   EditNL         4.00    ARC           6.01*
     SEAdog         4.50*   MakeNL         2.12    ARCmail        2.0*
     BinkleyTerm    2.20*   Prune          1.40    ConfMail      4.00
     D'Bridge       1.18*   XlatList       2.90*   TPB Editor    1.21
     FrontDoor       2.0    XlaxNode       2.32*   TCOMMail       2.1*
     PRENM          1.40    XlaxDiff       2.32*   TMail         8901*
                            ParseList      1.30    UFGATE        1.02*
                                                   GROUP         2.04*
                                                   EMM           1.40
                                                   MSGED         1.99*
                                                   XRS            1.2*

     * Recently changed

     Utility authors:  Please help  keep  this  list  up  to  date  by
     reporting  new  versions  to 1:1/1.  It is not our intent to list
     all utilities here, only those which verge on necessity.

     -----------------------------------------------------------------
     FidoNews 6-14                Page 40                   3 Apr 1989


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

                          The Interrupt Stack


      8 May 1989
        Digital Equipment Corporations User Society (DECUS) will be
        holding its semi-annual symposium in Atlanta, GA. Runs
        through May 12. As usual sysop's will get together and chat.

     19 May 1989
        Start of EuroCon III at Eindhoven, The Netherlands

     24 Aug 1989
        Voyager 2 passes Neptune.

     24 Aug 1989
          FidoCon '89 starts at the Holiday Inn in San Jose,
          California.  Trade show, seminars, etc. Contact 1/89
          for info.

      5 Oct 1989
        20th Anniversary of "Monty Python's Flying Circus"

     If you have something which you would like to see on this
     calendar, please send a message to FidoNet node 1:1/1.

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

     FidoNews 6-14                Page 41                   3 Apr 1989


            OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION

     Mort Sternheim 1:321/109  Chairman of the Board
     Bob Rudolph    1:261/628  President
     Matt Whelan    3:3/1      Vice President
     Bill Bolton    3:711/403  Vice President-Technical Coordinator
     Linda Grennan  1:147/1    Secretary
     Kris Veitch    1:147/30   Treasurer


            IFNA COMMITTEE AND BOARD CHAIRS

     Administration and Finance     Mark Grennan    1:147/1
     Board of Directors             Mort Sternheim  1:321/109
     Bylaws                         Don Daniels     1:107/210
     Ethics                         Vic Hill        1:147/4
     Executive Committee            Bob Rudolph     1:261/628
     International Affairs          Rob Gonsalves   2:500/1
     Membership Services            David Drexler   1:147/1
     Nominations & Elections        David Melnick   1:107/233
     Public Affairs                 David Drexler   1:147/1
     Publications                   Rick Siegel     1:107/27
     Security & Individual Rights   Jim Cannell     1:143/21
     Technical Standards            Rick Moore      1:115/333


                      IFNA BOARD OF DIRECTORS

         DIVISION                               AT-LARGE

     10  Courtney Harris   1:130/732    Don Daniels     1:107/210
     11  Bill Allbritten   1:11/301     Mort Sternheim  1:321/109
     12  Bill Bolton       3:711/403    Mark Grennan    1:147/1
     13  Irene Henderson   1:107/9       (vacant)
     14  Ken Kaplan        1:100/22     Ted Polczyinski 1:154/5
     15  Scott Miller      1:128/12     Matt Whelan     3:3/1
     16  Ivan Schaffel     1:141/390    Robert Rudolph  1:261/628
     17  Neal Curtin       1:343/1      Steve Jordan    1:206/2871
     18  Andrew Adler      1:135/47     Kris Veitch     1:147/30
     19  David Drexler     1:147/1       (vacant)
      2  Henk Wevers       2:500/1      David Melnik    1:107/233

     -----------------------------------------------------------------
     FidoNews 6-14                Page 42                   3 Apr 1989


                                      __
                 The World's First   /  \
                    BBS Network     /|oo \
                    * FidoNet *    (_|  /_)
                                    _`@/_ \    _
                                   |     | \   \\
                                   | (*) |  \   ))
                      ______       |__U__| /  \//
                     / Fido \       _//|| _\   /
                    (________)     (_/(_|(____/ (tm)

            Membership for the International FidoNet Association

     Membership in IFNA is open to any individual or organization that
     pays  a  specified  annual   membership  fee.   IFNA  serves  the
     international  FidoNet-compatible  electronic  mail  community to
     increase worldwide communications.

     Member Name _______________________________  Date _______________
     Address _________________________________________________________
     City ____________________________________________________________
     State ________________________________  Zip _____________________
     Country _________________________________________________________
     Home Phone (Voice) ______________________________________________
     Work Phone (Voice) ______________________________________________

     Zone:Net/Node Number ____________________________________________
     BBS Name ________________________________________________________
     BBS Phone Number ________________________________________________
     Baud Rates Supported ____________________________________________
     Board Restrictions ______________________________________________

     Your Special Interests __________________________________________
     _________________________________________________________________
     _________________________________________________________________
     In what areas would you be willing to help in FidoNet? __________
     _________________________________________________________________
     _________________________________________________________________
     Send this membership form and a check or money order for $25 in
     US Funds to:
                   International FidoNet Association
                   PO Box 41143
                   St Louis, Missouri 63141
                   USA

     Thank you for your membership!  Your participation will help to
     insure the future of FidoNet.

     Please NOTE that IFNA is a general not-for-profit organization
     and Articles of Association and By-Laws were adopted by the
     membership in January 1987.  The second elected Board of Directors
     was filled in August 1988.  The IFNA Echomail Conference has been
     established on FidoNet to assist the Board.  We welcome your
     input to this Conference.

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