2428 lines
101 KiB
Plaintext
2428 lines
101 KiB
Plaintext
|
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.
|
|||
|
|
|
|||
|
|
-----------------------------------------------------------------
|
|||
|
|
|