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.
Copyright 1987 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.
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them.
Everything here is subject to debate. We publish EVERYTHING
received.
Table of Contents
1. ARTICLES ................................................. 1
IFNA Board January Voting Summary ........................ 1
ICONS Can help you communicate ........................... 4
NaughtNet: Another New Network ........................... 6
POLICY4 Draft Proposal from Thom Henderson ............... 11
2. COLUMNS .................................................. 26
The Apple Core ........................................... 26
3. WANTED ................................................... 29
4. NOTICES .................................................. 31
The Interrupt Stack ...................................... 31
Latest Software Versions ................................. 31
FidoNews 5-06 Page 1 8 Feb 1988
DOCKET NUMBER: BOD-122087.01 - PASSED by vote of 13-0-0-0
Resolution: Allowable ballots will contain either YEA, NAY,
ABSTAIN, or HOLD.
Actual text of resolution: Be it resolved that the following
points be instituted relative to the voting process in the Board
of Directors:
A. For each action to be voted upon there shall be four
possible responses:
1. YEA - Election of this option signifies support for the
motion in question.
2. NAY - Election of this option signifies rejection of
the motion in question.
3. ABSTAIN - Election of this option makes the statement
that the voter either has no choice or chooses to not
decide for whatever reason.
4. HOLD - Election of this option signifies a request that
the due date of the motion in question automatically be
held over to the following vote date.
B. In order for a motion appearing on the floor during an
electronic session to be passed or rejected there must be
received a number of such votes from a majority of the total
of all members of the Board eligible to vote, except that
such total shall be reduced by the number of ABSTAIN votes
cast. When a motion fails to receive such a majority of YEA
or NAY votes, it shall automatically be held over to the next
voting period.
DOCKET NUMBER: BOD-121987.02 - HELD by vote of 8-1-7-0
(Will re-appear on the ballot for 88/01/24)
Resolution: The Vice President - Technical Coordinator for IFNA
be given sole responsibility for the contents and format of the
weekly nodelist.
Text of actual resolution: It is hereby resolved that the weekly
nodelist contents and format be under the control of the Vice
President - Technical Coordinator, with changes being voted on by
the full Board of Directors. The FidoNet Technical Standards
Committee is available to assist the VP-TC if necessary. In the
past, the format and content has been covered by document FSC002,
this resolution passes control of the document to the VP-TC, and
gives the full Board of Directors the power to accept or deny
proposed changes.
DOCKET NUMBER: BOD-122087.03 - PASSED by vote of 10-3-3-0
Resolution: Declaration of Ben Baker as an Honorary Member
Text of resolution: It is hereby resolved that, in appreciation
for the many past services rendered to IFNA and to FidoNet in
general, the Board of Directors of the International FidoNet
Association declare Ben Baker as its first Honorary Member.
DOCKET NUMBER: BOD-123087.01 - PASSED by vote of 15-4-1-0
Resolution: IFNA has no desire to effect a policy statement to
control any echomail areas that are not specifically IFNA echos.
Text of actual resolution: IFNA believes that one of the benefits
of an electronic mail system is the free-flow of information in
all forms, including electronic conferencing (ie echomail). IFNA
also has no desire to regulate, control or censor any
conferencing systems used in the FidoNet electronic mail system.
DOCKET NUMBER: BOD-122287.01 - HELD by vote of 9-7-2-1
(Will be held until the BoD Meeting of 88/02/20)
Resolution: Bring discussion of Policy4 back from the Executive
Committee to the full Board of Directors.
Text of actual resolution: Motion to bring back for consideration
by the full board the agenda item IIA Consideration of adopting
FidoNews 5-06 Page 3 8 Feb 1988
revised Policy4. As was sent to executive committee at the last
meeting of the whole on August 23, 1987.
DOCKET NUMBER: BOD-121987.02 - PASSED by vote of 12-5-1-0
Resolution: The Vice President - Technical Coordinator for IFNA
be given sole responsibility for the contents and format of the
weekly nodelist.
Text of actual resolution: It is hereby resolved that the weekly
nodelist contents and format be under the control of the Vice
President - Technical Coordinator, with changes being voted on by
the full Board of Directors. The FidoNet Technical Standards
Committee is available to assist the VP-TC if necessary. In the
past, the format and content has been covered by document FSC002,
this resolution passes control of the document to the VP-TC, and
gives the full Board of Directors the power to accept or deny
proposed changes.
DOCKET NUMBER: BOD-011088.01 - PASSED by vote of ?-0-1-0
Resolution: That a summary document of IFNA Board of Directors
Operating Policy be maintained and be publicly accessible.
Text of actual resolution: It is hereby resolved that a summary
document of Board of Directors Operating Policy be maintained and
be publicly accessible for the membership (or potential members).
The purpose of this document is to maintain a record of items
decided by the Board of Directors which affect the operation of
the Board and are not covered in currently existing documents
such as the Articles of Association and FidoNet Policy &
Procedures document. It is also designed to provide a guideline
concerning the operation of the Board.
It is further resolved that summary documents of Board of
Directors activity and voting results be maintained and be
publicly accessible for the membership (or potential members).
The purpose of this document is to help allow the membership to
be fully informed of the actions of the Board of Directors and to
provide historical documentation of voting results.
Are you afraid that you come across differently
electronically than you do on paper, over the phone or
in person? The answer may be icons! The icons listed
below can help you express those no-verbal signals that
are all but impossible to express over the net.
Any additions to this list would be greatly appreciated!
Send all comments and additions to David Melnik at 107/233.
"I've had nothing yet," Alice replied in an offended
tone: "so I can't take more."
That quote (from Lewis Carroll if you saw a movie of _Alice in
Wonderland_ so bad that it didn't include that line) expresses
the mood of the moment. Or to put it another way:
I'm Nobody! Who are you?
Are you -- Nobody -- too?
Then there's a pair of us!
Don't tell! they'd advertise -- you know!
How dreary -- to be -- Somebody!
How public -- like a Frog --
To tell one's name -- the livelong June --
To an admiring Bog!
-- Emily Dickinson
(Only the table of contents and the overview are presented here.
Other sections are available by request.)
N A U G H T N E T
Policy and Procedures Guide
Version 0
00 Zeroember 1900
0 Overview ................................................ 0
0.0 Definitions ......................................... 0
0.0 The Levels of NaughtNet ............................. 0
0 Sysop Procedures ........................................ 0
0.0 How to get a node number ............................ 0
0.0 If you are going down ............................... 0
0.0 How to join a network ............................... 0
0.0 How to form a network ............................... 0
0 Network Coordinator Procedures .......................... 0
0.0 Routing inbound mail ................................ 0
0.0 Assigning node numbers .............................. 0
0.0 Maintaining the node list ........................... 0
0.0 Passing along node lists and NaughtNews ............. 0
0.0 Forwarding newsletter submissions ................... 0
0 Regional Coordinator Procedures ......................... 00
0.0 Assigning node numbers .............................. 00
FidoNews 5-06 Page 7 8 Feb 1988
0.0 Encouraging the formation and growth of networks .... 00
0.0 Assigning network numbers ........................... 00
0.0 Maintaining the node list ........................... 00
0.0 Overseeing network operations ....................... 00
0.0 Passing along node lists and NaughtNews ............. 00
0.0 Forwarding newsletter submissions ................... 00
0 International Coordinator Procedures .................... 00
0 Resolution of Disputes .................................. 00
0.0 Problems with another node .......................... 00
0.0 Problems with a Network Coordinator ................. 00
0.0 Problems with a Regional Coordinator ................ 00
0.0 Problems with the International Coordinator ......... 00
0.0 Appeals to the International Coordinator ............ 00
0.0 Case Histories ...................................... 00
0.0.0 The Case of the Crooked Node .................. 00
0.0.0 The Case of the Hacker Mailer ................. 00
0.0.0 The Case of the Network Mutiny ................ 00
0.0.0 The Case of the Bothered Barker ............... 00
0.0.0 The Case of the Busy Beaver ................... 00
0.0.0 The Mark of the Devil ......................... 00
0.0.0 The Case of the Sysop Twit .................... 00
0.0.0 The Case of the EchoMail Junkey ................ 00
0.0.0 The Case of the Bouncing Board ................ 00
Chapter 0
OVERVIEW
NaughtNet is a new amateur e-mail network. It is an offspring of
the world-famous Fidonet network.
The founders of Naughtnet believe that Naughtnet addresses all
the problems that past alternate networks were formed to
address, and in fact will address any future problems that
Fidonet nodes have with IFNA and the Fidonet heirarchy. Such
problems, as we see them, include:
o Entirely too much interest shown by certain people in the
functioning of FidoNet, disturbing the conformity of a well-
ordered network;
o Communication is all too possible, with more and more nodes
every week, and echomail making even users able to talk with
those in far-away cities and countries (this being alien to
the initial spirit of FidoNet, where only sysops could
afford to send mail);
o Expansion of BBS and netmail software possibilites
(including Opus and BinkleyTerm), makes it impossible for
the old-time Fido monopoly to continue;
o A tremendous upsurge in the number of people willing to
volunteer for Net, Region, and Zone Coordinators, as well as
chairmen and members of committees, suggests that the sysops
at large want a voice in the operation of Fidonet; this
FidoNews 5-06 Page 8 8 Feb 1988
would be dangerous to the order of the net, and thus should
be eliminated.
We feel that these are the reasons that IFNA has proven a
complete failure and both it and FidoNet should be scrapped in
favor of NaughtNet.
0.0 Definitions
NaughtNet nodes are grouped on several levels. These are as
follows:
o Nodes; A node is a single Naughtnet address. This is the
smallest recognized unit of NaughtNet, and the only one
anybody likes.
o Networks; A network is a collection of nodes, usually in a
relatively small geographic area. Networks coordinate their
mail activity to decrease cost and increase mail throughput.
In NaughtNet it is felt that networks are one of the prime
causes of disorder; nodes are wont to complain when they
don't get everything they want from their network hosts.
Therefore, networks have been eliminated in Naughtnet. We
feel this will lessen both the number of complaints and the
number of people who want a voice in discussions.
o Regions; A region is a well defined geographic area
containing nodes. Of course, the nodes can't be in networks,
but that makes the Regional Coordinator's job easier. Here
are the regions that make up Naughtnet:
o Zones; A zone is a large geographic area containing many
regions, and covering one or more astronomical districts.
These are the zones in NaughtNet:
Solar System -- 0 Rest of Milky Way -- 0
Andromeda Galaxy -- 0 Rest of Local Group -- 0
Rest of Universe -- 0
o NaughtNet; This indicates nothing at all, as should be self-
evident.
0.0 The Levels of NaughtNet
FidoNews 5-06 Page 9 8 Feb 1988
NaughtNet has no real levels, because it has weak legs and can't
climb stairs, and is claustrophobic and can't ride elevators.
But the following will suffice:
o The International Coordinator; The International
Coordinator can compile all of the node lists from all of
the regions and creates the master node list, which could
then be distributed over NaughtNet if the International
Coordinator really wanted to for some reason. The following
is a sample nodelist (with widths wrapped around):
o The Zone Coordinator; In some cases the International
Coordinator will appoint a Zone Coordinator to oversee
FidoNet operations in a given zone. There are no duties or
responsibilities of Zone Coordinators, so usually there
aren't any. In fact, the appointment of a Zone Coordinator
is grounds for removal of any particular IC, so it's not
done a lot; it is however an easy way to resign.
o The Regional Coordinator; The Regional Coordinator
maintains the list of nodes in his region. Usually any given
RC won't bother, since all the nodes in NaughtNet are
unpublished, but sometimes he gets bored.
o The Network Coordinator; Anyone claiming to be a Network
Coordinator is summarily shot in regions where no other
legal jurisdiction exists. In other regions that person will
simply be forced to do thirty pushups, unless that person is
(as well as being part of NaughtNet) an ice-cream salesman,
in which case he will have to eat thirty Frozen Yogurt Push-
Ups <tm>.
o The Network Routing Hub; Network Routing Hubs exist only in
three-tiered networks. Since in NaughtNet there are no
networks, there are obviously no Network Routing Hubs.
Anyone claming to be a Network Routing Hub will suffer the
same fate as his Network Coordinator, or if there is no
Network Coordinator, will be placed in the nearest planetary
mental institution.
o The system operator (sysop); The sysop formulates his own
policy for running his board and dealing with his users, so
that will not be discussed in this document. However, the
sysop must also do everything the IC wants and not argue
about it, even if the sysop feels it's none of the IC's
business.
FidoNews 5-06 Page 10 8 Feb 1988
o The user; Policy and procedures for the individual user
on any given board is determined by that user. Sysops can't
do anything about it, that's just tough.
These levels act to put everybody under the thumb of whoever
takes charge; this is considered desireable because the author
of this document is in charge.
For example, a Regional Coordinator is solely responsible to the
International Coordinator for anything that may or may not
happen in his region. From the point of view of the
International Coordinator, the Regional Coordinator is totally
and completely responsible for the smooth operation of his
region. Likewise, from the point of view of anybody else, the
International Coordinator is just as much an interfering jerk as
he is to the Regional Coordinator.
If a person at any level is unable for any reason to properly
perform his duties, then he will suffer the fate of a Net
Coordinator. That's the breaks.
Ed note: This is one of several proposals for the new POLICY4
document which is being published for review by FidoNet
Sysops and the subcommittee of Membership Services. It
was prepared by Thom Henderson prior to his departure
into AlterNet. Publication of these proposals will
take place in FidoNews weekly until they have all been
seen.
Discussion regarding the new POLICY4 is taking place in
the POLICY4 EchoMail conference.
---------------------------------------------------------------
F I D O N E T
Policy and Procedures Guide
Version 4
* * * P R O P O S A L * * *
1 Overview
1.1 The Levels of FidoNet
1.2 Coordinators
2 Sysop Procedures
2.1 How to get a node number
2.2 If you are going down
2.3 How to form a network
3 Coordinator Procedures
3.1 Administrative tasks
3.1.1 Maintaining the node list
3.1.2 Assigning node numbers
3.1.3 Problem resolution
3.1.4 Formulating local policy
3.2 Node list distribution
3.3 Newsletter distribution
3.4 Network mail distribution
3.5 Anything else
3.6 Specific coordinator procedures
3.6.1 International Coordinator procedures
3.6.2 Zone Coordinator procedures
3.6.3 Regional Coordinator procedures
3.6.4 Network Coordinator procedures
3.6.5 Hub Coordinator procedures
4 Resolution of Disputes
4.1 Case Histories
4.1.1 The Case of the Crooked Node
4.1.2 The Case of the Hacker Mailer
4.1.3 The Case of the Network Mutiny
4.1.4 The Case of the Bothered Barker
4.1.5 The Case of the Busy Beaver
4.1.6 The Case of the Sysop Twit
4.1.7 The Case of the EchoMail Junkey key key
4.1.8 The Case of the Bouncing Board
Chapter 1
FidoNews 5-06 Page 12 8 Feb 1988
OVERVIEW
FidoNet is an amateur electronic mail system. As such, all of
its participants and operators are non-paid volunteers. From
its early beginnings as a few friends swapping messages back and
forth, it has now grown to (August 1987) over 2000 different
systems on four continents.
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 is
an attempt to describe the procedures which have been developed
to manage the network.
1.1 The Levels of FidoNet
FidoNet nodes are grouped on several levels. These are as
follows:
o FidoNet; This indicates the entire public amateur mail
network, as administered by the International FidoNet
Association, and as defined by the weekly node list.
o Zones; A zone is a large geographic area containing many
regions, and covering one or more countries and/or continents.
o 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
independent nodes, which are not a part of any network.
o Networks; A network is a collection of nodes, usually in a
relatively small geographic area. Networks coordinate their
mail activity to decrease cost and increase mail throughput.
o Hubs; A hub is a subdivision of a network that assists in
network management by routing mail to, and by coordinating for,
a collection of nodes in that network. In general only the
larger networks will have hubs.
o Nodes; A node is a single FidoNet address, and is the smallest
recognized unit of FidoNet.
o Points; A point is a node on a private network which is
accessible through a node on FidoNet.
1.2 Coordinators
Each subdivision at each level is managed by a coordinator. A
coordinator is a person who coordinates the technical aspects of
network mail. This entails both administrative and technical
tasks, which will be described later. The following levels of
coordinators are currently recognized:
FidoNews 5-06 Page 13 8 Feb 1988
o The International Coordinator; The International Coordinator
compiles all of the node lists from all of the regions and
creates the master node list, which is then distributed over
FidoNet.
o The Zone Coordinator; A Zone Coordinator maintains the list of
administrative nodes in his zone and accepts node lists from the
Regional Coordinators in his zone. He compiles these lists to
create a zone node list, which he then sends to the
International Coordinator for inclusion in the master node list.
A Zone Coordinator is also responsible for overseeing any zone
gateways in his zone.
o The Regional Coordinator; A Regional Coordinator maintains the
list of independent nodes in his region and accepts node lists
from the Network Coordinators in his region. He compiles these
lists to create a regional node list for his region, which he
then sends to his Zone Coordinator. A Regional Coordinator does
not perform routing services for any nodes in his region.
o The Network Coordinator; A Network Coordinator maintains the
list of any nodes in his network that are not served by a hub
and accepts node lists from the Hub Coordinators in his network.
He compiles these lists to create a network node list for his
network, which he then sends to his Regional Coordinator. A
Network Coordinator is also responsible for forwarding any mail
addressed to nodes in his network.
o The Hub Coordinator; A Hub Coordinator maintains the list of
nodes in his hub and sends it to his Network Coordinator. A Hub
Coordinator is also responsible for forwarding any mail
addressed to nodes in his hub.
o The Point Coordinator; Any node in FidoNet can act as a
gateway to a point network. The Sysop (or system operator) of
that node then acts as the coordinator for his point network.
o The Sysop; A Sysop formulates his own policy for running his
board and dealing with his users, so that will not be discussed
in this document. However, a Sysop must also mesh with the rest
of the FidoNet system if he is to send and receive mail, and
that will be discussed here.
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. Administration
is made possible by operating in a strict top-down manner. That
is, a coordinator at any given level is responsible to the
coordinator immediately above him, and responsible for everyone
below him.
For example, a Regional Coordinator is solely responsible to his
Zone Coordinator for anything that may or may not happen in his
region. From the point of view of the Zone Coordinator, the
Regional Coordinator is totally and completely responsible for
the smooth operation of his region. Likewise, from the point of
FidoNews 5-06 Page 14 8 Feb 1988
view of the Regional Coordinator, the Network Coordinators are
totally and completely responsible for the smooth operation of
their networks.
If a coordinator at any level above sysop is unable for any
reason to properly perform his duties, he can be replaced by his
coordinator at the next level up. For example, if a Regional
Coordinator is failing to perform his duties, then his Zone
Coordinator can appoint a new Regional Coordinator to replace
him.
The primary responsibility of any coordinator is technical
management of network operations. Management decisions should
be made strictly on technical grounds.
Chapter 1
SYSOP PROCEDURES
A sysop of an individual node can pretty much do as he pleases,
as long as he observes the mail events, is not excessively
annoying to other nodes on FidoNet, and does not promote the
distribution of pirated copyrighted software.
National Mail Hour is the heart of FidoNet, as this is when
network mail is passed between systems. Any system which wishes
to be a part of FidoNet must be able to receive mail at this
time. A system which is a member of a network may also be
required to observe additional mail events, as defined by his
Network Coordinator.
Failure to observe the proper mail events is sufficient grounds
for any node to be dropped from FidoNet without notice (since
notice is generally given by FidoNet mail).
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 node list as is practical.
A system which has been dropped from the network is said to be
excommunicated (i.e. unable to communicate). A node which has
been excommunicated may or may not be listed for a time in the
"dog house", which is included in the comments at the end of the
node list. If you find that you have been excommunicated
without warning, then that means that your coordinator was
unable to contact you. You should rectify the problem and
report back.
The exact timing of National Mail Hour is set for each zone by
the Zone Coordinator. In the United States, National Mail Hour
is observed from 0900 to 1000 GMT every day, weekends included.
In each of the United States time zones, this would be as
follows:
FidoNews 5-06 Page 15 8 Feb 1988
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
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.1 How to get a node number
You must first obtain a current node list 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 node list is to locate a
FidoNet bulletin board. No help there; you're on your own.
Most bulletin board lists include at least a few FidoNet
systems, and usually identify them as such, so this shouldn't be
too hard.
If the sysop of any FidoNet system does not have a node list
available for downloading, then he can probably tell you where
to get one.
Once you have a node list, you must determine which coordinator
to apply to. The coordinator of any network or region is always
node zero of that network or region. A Hub Coordinator will
always be indicated in the node list by a "HUB" prefix.
You should apply to the lowest-level coordinator that covers
your area. For example, if you are located within the hub of a
network, then you would apply to the Hub Coordinator. If there
is no network that covers your area, then you would apply to the
Regional Coordinator for your region.
Your application for a node number must be sent to the
coordinator by FidoNet mail, and must include at least 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.
6)The maximum baud rate you can support.
Your coordinator may want additional information. If so, he
will contact you. Please allow at least two to three weeks for
a node number request to be processed.
2.2 If you are going down
FidoNews 5-06 Page 16 8 Feb 1988
If your node will be down for an extended period (more than a
day or two), then you should inform your coordinator as soon as
possible. If you do not do this, then other systems will still
try to reach you while you are down, much to the annoyance of
everyone. Do not under any circumstances put an answering
machine or similar device on your phone line while you are down.
If you do, then calling systems will get the machine repeatedly,
racking up large phone bills, which is very annoying. See the
section on Resolution of Disputes for details on what happens to
annoying people.
If your system goes down without warning, then you may be placed
in the dog house, or even removed from the node list completely.
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 do 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.3 How to form a network
If there are several nodes in your area, but no network, then
you may wish to form your own. You may also be requested to
form a network by your Regional Coordinator.
Your 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 is going to be the Network Coordinator. Your
next step is to inform your Regional Coordinator. You must send
him a FidoNet message with the following information:
1) The region number(s), or network number(s) if a network is
splitting up, that are affected by the formation of your
network. The Regional Coordinator will inform the coordinators
of any affected networks that a new network is in formation.
2) The name that you wish to call your network. Please try to
select a name that relates to your grouping. For example,
SoCalNet for nodes in the Southern California Area and MassNet
for Massachusettes Area. Remember if you call yourself DOGNET
it doesn't help others know what area of the country (or even
what country) your group is in.
3) A copy of the proposed network's nodelist. The nodelist file
should be named Frrr-nnn.NET where rrr is the proposed host's
current region or network number and nnn is his current node
number. For example, if the proposed host is currently listed
as node 5 in region 13, then you would name the file
F013-005.NET. This file should be sent attached to the message
of Application for a Network Number.
SAMPLE FORMAT OF A Frrr-nnn.NET FILE
(Ed note: Sample of St. Louis format NODELIST.BBS goes here.)
FidoNews 5-06 Page 17 8 Feb 1988
Granting of a network number is not automatic. Your Regional
Coordinator will review your application and inform you of his
decision.
Do not send a network number request to the International
Coordinator. All network number requests must be processed by
the Regional Coordinator.
Chapter 3
COORDINATOR PROCEDURES
This chapter describes the procedures followed by all
coordinators at all levels. Later we will go into more detail
on those procedures which are specific to any given type of
coordinator.
All coordinators have four primary duties. In order of
decreasing importance, they are:
1) Administrative tasks.
2) Node list distribution.
3) Newsletter distribution.
4) Network mail distribution.
At first glance it would seem that network mail distribution
should be the highest priority, since after all that's why we're
running a network in the first place. But the first three
priorities are needed to ensure smooth operation of the network,
and hence must have a higher priority.
3.1 Administrative tasks
First and foremost, every coordinator is also the sysop of his
own node. It must be possible for others to reach you by
network mail. So in addition to the other tasks of a
coordinator, you must also observe all of the requirements for
being a node.
3.1.1 Maintaining the node list
A coordinator at any level must maintain his portion of the node
list. Almost any coordinator will have some nodes in his node
list which are not a part of any subgroup. For example, a Zone
Coordinator must maintain a list of administrative nodes for his
zone, and a Regional Coordinator must maintain a list of
independent nodes in his region. A Hub Coordinator (or the
Network Coordinator in a network without hubs) must maintain the
list of all nodes in his area.
A coordinator is responsible for seeing to it that his portion
of the node list is kept reasonably accurate. You should
attempt to implement name changes, phone number changes, and so
FidoNews 5-06 Page 18 8 Feb 1988
forth in this node list as soon as possible. You should also
check from time to time to ensure that all of the listed nodes
are in fact capable of accepting network mail. How best to
accomplish this is left to your discretion.
If a node turns out to be "off the air" with no prior warning
given to you, then you can either mark the node as down, place
it in the dog house, or remove it from the node list completely,
at your own discretion.
3.1.2 Assigning node numbers
You may assign node numbers to new nodes in your list, but keep
in mind the following:
1) It is your responsibility to ensure that the node number you
assign is unique within that region or network.
2) You should try to avoid assigning node numbers when an
existing subdivision of your area already covers the location of
the new node. For example, a Regional Coordinator should try to
avoid assigning independent nodes in a city that has its own
network.
You may also change the numbers of existing nodes in your area,
though you should check with the respective nodes before doing
so.
You should not under any circumstances 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 at
least 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 should use network mail to inform a new node of his node
number, as this helps to insure that he is capable of receiving
network mail.
3.1.3 Problem resolution
From time to time you may be called on to resolve a problem in
your area. This could be a technical problem relating to the
four primary duties of a coordinator, or it could be related to
annoying behaviour on the part of someone in your area.
If the problem is caused by a node or a coordinator immediately
under you, then it is your responsibility to resolve the problem
in whatever manner you deem fit. If the problem is in a
subdivision of your area, then you should first refer it to the
appropriate coordinator. If that coordinator does not resolve
the problem satisfactorily, then you can appoint a replacement.
FidoNews 5-06 Page 19 8 Feb 1988
3.1.4 Formulating local policy
It is your responsibility to formulate any local policies which
are required for the smooth operation of your assigned area.
Any policies you establish must not conflict with any policies
established by a coordinator above you or with this policy
document.
3.2 Node list distribution
The node list is posted weekly on Saturday, along with a
"difference file" giving the changes for the week. It is your
responsibility to obtain the difference file from your
coordinator every week and to distribute it to the coordinators
below you. The method of distribution is left to your
discretion. It is also desirable that you make it available for
downloading by the general user, but this is not required.
3.3 Newsletter distribution
The newsletter, called FidoNews, is published weekly on Monday
and is distributed as an archive named FNEWSvnn.ARC, where "v"
is the volume number and "nn" is the issue number. It is your
responsibility to obtain this archive from your coordinator
every week and to distribute it to the coordinators below you.
The method of distribution is left to your discretion. It is
also desirable that you make it available for downloading by the
general user in both archived an unarchived form, but this is
not required.
3.4 Network mail distribution
It is your responsibility to ensure that network mail in your
area is operating in an acceptable manner. Exactly what this
involves will depend on what level you are at, and will be
discussed in more detail below.
3.5 Anything else
You should encourage sysops and users in your region to
contribute to FidoNews. If you receive any submissions, you
should forward them to the FidoNews publisher. Think of
yourself as being a regional bureau chief on the FidoNews
editorial staff.
FidoNews and the node list are the glue that holds us together.
Without them, we cease to be a community, and become just
another random collection of bulletin boards.
3.6 Specific coordinator procedures
The above outlines the procedures which are followed by all
coordinators. We will now discuss additional procedures
followed by specific types of coordinators.
3.6.1 International Coordinator procedures
FidoNews 5-06 Page 20 8 Feb 1988
The International Coordinator is appointed by the Board of
Directors of the International FidoNet Association, Inc. The
Board of Directors can appoint a replacement for the
International Coordinator at any time.
The International Coordinator is responsible for the weekly
creation of the master node list, and the creation of a weekly
difference file listing node list changes. This difference file
is to be distributed to the various Zone Coordinators on
Saturday morning.
The International Coordinator is responsible for allocating
zones, assigning zone numbers, and for appointing the Zone
Coordinator for each zone.
3.6.2 Zone Coordinator procedures
A Zone Coordinator is responsible for dividing his zone into
regions, assigning region numbers, and for appointing the
Regional Coordinator for each region. A Zone Coordinator also
assigns a pool of numbers to each Regional Coordinator for use
in assigning network numbers.
A Zone Coordinator is responsible for locating nodes willing to
act as zone gates for passing mail between his zone and the
other zones, if at all possible. A Zone Coordinator should not
appoint any node as a zone gate unless the sysop of that node is
willing and able to provide reasonably reliable interzone mail.
Zone gates are highly desirable, but if provided they must be
reasonably reliable.
A Zone Coordinator maintains the list of administrative nodes
within his zone. The administrative nodes will always have a
region number the same as the zone number. For example, the
administrative nodes for Zone 3 will always be in Region 3.
A Zone Coordinator may use administrative node addresses for
whatever he likes, except that any node number which is the same
as another zone number is reserved for the zone gate to that
zone. For example, in Zone 3 the network address "3/2" is
reserved for use by the zone gate that passes mail from Zone 3
to Zone 2.
A Zone Coordinator may not assign a region number that is the
same as any other zone number. This is because administrative
regions are, by definition, present in all zones.
3.6.3 Regional Coordinator procedures
A Regional Coordinator is responsible for approving new
networks, assigning network numbers, and for appointing a
Network Coordinator for each network.
Each Regional Coordinator will be assigned a pool of numbers to
use when assigning network numbers. A Regional Coordinator
should never assign a network number outside of this pool, and
FidoNews 5-06 Page 21 8 Feb 1988
should never assign the same number to more than one network.
If a Regional Coordinator assigns all of the numbers in his
pool, he should apply to his Zone Coordinator for additional
numbers.
A Regional Coordinator should try to avoid the needless
proliferation of networks. Networks should not be allocated on
any basis other than technical and practical considerations
relating to network mail operations. For example, persons
wishing to establish networks on the basis of special interests
or for company mail should be encouraged to investigate the
alternatives, such as echomail conferences and point networks.
A Regional Coordinator is responsible for maintaining the list
of independent nodes within his region. This will consist
primarily of those nodes which are not within the coverage area
of any network. There are, however, certain cases where a node
should not be a member of a network, such as a commercial system
with a large volume of traffic which would clog the network.
The resolution of such special cases is left to your own
discretion.
If several independent nodes in a region are in a "clump", then
the Regional Coordinator should encourage or require them to
form a network. Refer to the sysop procedure on forming a
network for more details.
Note that this does not mean that a Regional Coordinator should
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 circumstances of the situation, and is left to the
discretion of the Regional Coordinator.
It is the responsibility of a Regional Coordinator to ensure
that the networks within his region are operating in an
acceptible manner. This does not mean that he is required to
operate those networks; that is the responsibility of the
Network Coordinators. It means that he is responsible for
seeing to it that the Network Coordinators within his region are
acting responsibly.
A Regional Coordinator is obligated to maintain direct and
reasonably frequent contact with the networks in his region.
The exact method of accomplishing this is left to the discretion
of the Regional Coordinator.
3.6.4 Network Coordinator procedures
A Network Coordinator is responsible for assigning node numbers
to any nodes within his network which are not managed by a Hub
Coordinator. A Network Coordinator is also responsible for
allocating any hubs within his network and for appointing a Hub
Coordinator for each hub. If a Network Coordinator assigns any
Hub Coordinators, then he also assigns a pool of numbers to each
Hub Coordinator for use in assigning node numbers.
FidoNews 5-06 Page 22 8 Feb 1988
It is the responsibility of a Network Coordinator to receive all
inbound mail for nodes in his network and to forward it to its
recipients. How to accomplish this is left to the discretion of
the Network Coordinator. However, there are a few exceptions:
1) Once in awhile a node will try to make a "bombing run"
(sending one message to a great many nodes). Bombing runs are
considered to be annoying, and may be dealt with accordingly.
2) Occasionally a user will appear who receives a great deal of
traffic. If a single node is receiving enough mail to interfere
with mail delivery to the other nodes in his network, then his
Network Coordinator can refer him to his Regional Coordinator
for reassignment as an independent node.
3) The most common source of routing overload is echomail.
Echomail is a nice invention, and offers great benefits, but it
cannot be allowed to degrade the ability of FidoNet to handle
normal message traffic. If a node in a network is routing large
volumes of echomail, the sysop can be asked to either limit the
amount of echomail, or even to stop routing his echomail
completely. The design of echomail is such that it is a simple
matter to do either of these.
A Network Coordinator is responsible for assigning any
additional mail events which may be required for operation of
his network. Any node in a network may be excommunicated for
failing to observe these additional mail events.
A Network Coordinator may appoint a node as the outbound gateway
for his network if he so desires and if one can be found. In no
case should a node be appointed as an outbound gateway unless
the sysop of that node is willing and able to provide reasonably
reliable service. Note that a Network Coordinator is not
required to appoint an outbound gateway. If a Network
Coordinator chooses to appoint an outbound gateway, then it is
left to the Network Coordinator to establish any rules,
policies, and procedures relating to its use.
3.6.5 Hub Coordinator procedures
A Hub Coordinator is responsible for assigning node numbers to
nodes in his area. Each Hub Coordinator will be assigned a pool
of numbers to use when assigning node numbers. A Hub
Coordinator should never assign a node number outside of this
pool, and should never assign the same number to more than one
node. If a Hub Coordinator assigns all of the numbers in his
pool, he should apply to his Network Coordinator for additional
numbers.
It is the responsibility of a Hub Coordinator to receive all
inbound mail for nodes in his hub and to forward it to its
recipients. How to accomplish this is left to the discretion of
the Hub Coordinator. However, the same exceptions apply here as
for a Network Coordinator.
FidoNews 5-06 Page 23 8 Feb 1988
A Hub Coordinator may have additional duties, as assigned by his
Network Coordinator.
Chapter 4
RESOLUTION OF DISPUTES
The world not being perfect, sometimes troubles crop up. Any
organization larger than a cub scout pack needs some sort of
grievance procedure, and FidoNet is no exception.
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!")
In any case of annoying behavior the person to complain to is
the coordinator of the person who is annoying you. For example,
if you have a problem with a point or a user you would complain
to his sysop, or if you have a problem with a Regional
Coordinator you would complain to his Zone Coordinator, and so
on.
If the coordinator you complain to fails to resolve the problem,
then you can complain to his coordinator. For example, if you
had a problem with a Hub Coordinator, you would first complain
to his Network Coordinator. Then if the Network Coordinator
does not resolve the problem, you would complain to his Regional
Coordinator.
Do not ever skip over a coordinator when filing a complaint.
That in itself is annoying.
4.1 Case Histories
A few actual case histories of past disputes may be instructive
to show general procedures and methods. Names have been left
out to protect the guilty.
4.1.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 node list.
The local appealed to his Regional Coordinator for assignment as
an independent node. The Regional Coordinator, on checking with
the Network Coordinator, decided that the Network Coordinator
was within his rights to be annoyed. Independent status was
denied.
FidoNews 5-06 Page 24 8 Feb 1988
4.1.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
the offending node from the node list.
The Regional Coordinator was not consulted.
The International Coordinator did not intervene.
4.1.3 The Case of the Network Mutiny
Several local nodes became annoyed with their Network
Coordinator for failing to provide services. They complained to
him, but nothing was done.
They appealed to their Regional Coordinator, who decided that
they were justified in their annoyance and accepted their
application for a new network number.
4.1.4 The Case of the Bothered Barker
A local node became annoyed with his Network Coordinator for
failing to provide services. Repeated complaints to his Network
Coordinator did not satisfy him, so he appealed to the
International Coordinator.
The International Coordinator, on seeing that the Regional
Coordinator had not been consulted, dismissed the complaint out
of hand.
The local node submitted his complaint to his Regional
Coordinator, 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 Coordinator, and was
advised to lower his expectations.
4.1.5 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.
FidoNews 5-06 Page 25 8 Feb 1988
4.1.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.
4.1.7 The Case of the EchoMail Junkey key key
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.
4.1.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, on finding the node
unable to receive mail, would mark it as down. The sysop would
return, restart the board, and ask to be reinstated as a node.
The Network Coordinator eventually decided that the sysop was
not able to maintain a reliable system, and removed him from the
node list completely. Future requests for a node number from
the same sysop were turned down. No appeals were made.
The Apple Core
Alan Applegate
The Short Line, 1:104/36 (Mail Only)
I've given a lot of thought lately to starting my own column here
in FidoNews. I contacted Dale Lovell (FidoNews Editor) shortly
after his first editorial appeared in FidoNews 5-01, and after
some difficulty getting started, here I am in all my written
glory.
For the overly curious, I operate a mail only node, formerly an
Opus system until I grew tired of my users. I am Editor of Net
104 News (a twice-quarterly newsletter for the Denver net), as
well as a quarterly newsletter for my employer. I am proud to
have written the documentation for one of the most powerful
software packages available to FidoNet: BinkleyTerm. My last
appearance in FidoNews was issue 4-25, where I sputtered on about
archiving programs.
Although I'm proud of what I write, believe me, I do not consider
myself a world class writer, or anything even close.
In upcoming columns, I hope to cover a wide variety of topics
from software reviews, to giving a good dose of mindless dribble
on current issues. I will always welcome your comments and
feedback; send your input to me at the node address listed above.
Flames will not be dignified with a response; general comments
will be replied to if warranted, and as time allows.
I promised Dale that I would shoot for bi-weekly with the column,
we'll see how that unfolds. Now on to column number one.
----------
I had written-up my first column for FidoNews several weeks ago,
and although the column is still timely, I've decided to shift it
down a couple of weeks in favor of something more appropriate.
In my introduction, I mentioned "some difficulty getting
started." I was referring to getting off to a rough start in my
attempts to communicate with Dale Lovell about starting my
column.
Although I'm no old timer to FidoNet, I'm also no spring chicken.
I'd like to believe, however accurate or inaccurate, that I have
played and continue to play a role in the shaping of FidoNet.
What's been built here is a marvel of modern technology.
Inexpensive, real-time, rapid, easy, convenient written
communication at our fingertips. Inexpensive is the one element
that strikes me most; that, and being rapid. I can send a
message overnight (or even quicker) to a friend on the other side
of the country for less than the cost of a postage stamp. If I
FidoNews 5-06 Page 27 8 Feb 1988
wanted to get the same message there by conventional means, say
Federal Express, I'd drop a ten-spot every time I got the urge to
communicate.
No, FidoNet isn't going to be threatening Federal Express'
dominant role in overnight delivery, or closer to our genre, MCI
Mail and other such services. It's not that the potential isn't
there, it's our system.
When trying to contact Dale about my column, I sent at least
three messages over the course of two weeks or so. I never did
receive a response back from Dale. Since I personally witnessed
my mail being sent to Dale's SEAdog, I assumed that he might
harbor some sort of antagonism toward me for some reason, and I
dropped the idea of writing a column.
A week or so ago in a burst of renewed interest, I decided to
ship-off one more message (my fourth) to Dale to 'give him one
more chance' to explain the reason he never wrote me. I believe
I said something to the effect that he 'owed me an explanation.'
Not 10 minutes after I crashed the message to him in the early
morning hours, I received a response back via crash mail that
plainly stated that it was his fourth response...
He explained that he normally routes his outbound mail through
someone in his net, and was certain (I believe he'd already
checked) that the mail did make it out of his net, and we assume,
to my local net coordinator. I never received the mail.
After sending a message to my coordinator (a very dedicated man),
I remembered that he had had some problems with his hard disk
over the past few weeks, and the responses could simply have
slipped through the cracks.
There is not a single point to this article, but several.
First, FidoNet is not a for-profit system. It works most of the
time because it just happens to. No one "owes" anyone anything.
People volunteer, and they are expected to carry out their duties
or pass along the baton to someone else. That doesn't mean that
our systems are always free of hardware or software
problems...that's part of the nature of our hobbiest roots.
PROBLEMS DO OCCUR.
Second, when problems occur, be patient. Just because it would
appear that there's some sort of obvious problem or situation,
doesn't mean that one's assessment is necessarily correct.
Patiently investigate where the problem might be, but don't point
fingers. WHEN PROBLEMS OCCUR, BE PATIENT.
Third, just because you don't get a response from someone doesn't
mean they hold anything against you. People are busy, and
sometimes don't get around to responding. Occasionally, messages
are accidently deleted before one has a chance to respond.
Sometimes, as in my case, people DO respond, you just don't know
it because you never got the response (see the first item). WHEN
FidoNews 5-06 Page 28 8 Feb 1988
YOU GET NO RESPONSE, DON'T ASSUME ANYTHING.
I learned the hard way I guess, and in the process, kind of made
an ass out of myself (I always reserve the right to do that).
Dale was particularly understanding, and sent me a considerate,
patient response (and I finally received it). He could just as
easily have told me where to stick my FidoNews columns.
People too often do just that...respond to flames with more fire.
Folks, two wrongs do not make a right...one of the oldest
proverbs in the book.
In most of the documentation I write (including this column, see
my introduction) I say, "Flames not dignified with a response."
I try my hardest to hold by that. I may write a response then
erase it, just to get it out of my system, but generally, I
simply don't respond. I refuse to stoop to the level of people
who insist upon tearing apart what I say.
Sending flames does no one any good. What the person is trying
to say is lost because it's so heavily engulfed in flames, and
the person who receives the fireball is too busy screaming about
it to make an appropriate response. This is not productive.
I don't mind constructive criticism. I strive to do well with
whatever it is that I do. Constructive criticism helps me
improve and understand. But the minute the match touches the can
of Sterno, forget it. I'll take my criticism like I take my
pizza...room temperature.
So I've decided not to respond to flames. Now all I need to do
is be a little more careful about starting them in the first
place. My apologies to Dale...he's obviously a nice guy. After
all, my column's in print, isn't it?
Reporter writing an article for the NY Times on the threat of
"virus' ("mole,) "worm" and/or trojan horse "attack code"
programs seeks reports of real experiences with these often
distructive, sometimes playful, devices. I'm interested in any
reports about incidents involving PCs, minis or micros.
Please forward replies to Vin McLellan at Fido 101/154, (voice)
617-426-2487, or Snail
: 125 Kingston St., Boston, Ma. 02111.
TRW Real Estate Information Systems, in Anaheim, CA is seeking a
creative Senior Programmer/Analyst to aid in the analysis,
design and implementation of a new generation of micro/mainframe
systems running in an IBM PC-AT compatible multitasking
environment.
We are looking for motivated, independent thinker with a minimum
of two years MS-DOS micro programming in C or Macro Assembler
and two years mini/mainframe programming. Experience in
structured development techniques and systems analysis/design
required. Familiarity with micro-mainframe communications,
micro hardware, and networks is desirable. Direct customer
interface is common, so good written and oral communication
skills are needed.
Please forward your resume with work history and references to:
TRW Real Estate Information Systems, Professional Employment,
Dept. DL-101, 2000 S. Anaheim Blvd., Suite 100, Anaheim, CA
92805. An equal opportunity employer.
19 Feb 1988
Start of the International FidoNet Associations Board of
Directors meeting in St. Louis. Meeting runs through the 21st.
25 Aug 1988
Start of the Fifth International FidoNet Conference, to be
held at the Drawbridge Inn in Cincinnatti, OH. Contact Tim
Sullivan at 108/62 for more information. This is FidoNet's big
annual get-together, and is your chance to meet all the people
you've been talking with all this time. We're hoping to see
you there!
24 Aug 1989
Voyager 2 passes Neptune.
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
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.
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
c/o Leonard Mednick, MBA, CPA
700 Bishop Street, #1014
Honolulu, Hawaii 96813-4112
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 first elected Board of Directors
was filled in August 1987. The IFNA Echomail Conference has been
established on FidoNet to assist the Board. We welcome your
input to this Conference.
The IFNA publications can be obtained by downloading from Fido
1:1/10 or other FidoNet compatible systems, or by purchasing
them directly from IFNA. We ask that all our IFNA Committee
Chairmen provide us with the latest versions of each
publication, but we can make no written guarantees.
System Enhancement Associates SEAdog $60.00 _____
SEAdog price as of March 1, 1987
ONLY 1 copy SEAdog per IFNA Member
Fido Software's Fido/FidoNet $100.00 _____
Fido/FidoNet price as of November 1, 1987
ONLY 1 copy Fido/FidoNet per IFNA Member
International orders include $10.00 for
surface shipping or $20.00 for air shipping _____
SUBTOTAL _____
HI. Residents add 4.0 % Sales tax _____
TOTAL _____
SEND CHECK OR MONEY ORDER IN US FUNDS:
International FidoNet Association
c/o Leonard Mednick, MBA, CPA
700 Bishop Street, #1014
Honolulu, HI. 96813-4112
USA
