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 1988 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.
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
Everything You Always Wanted to Know About the #CM: Fla .. 3
Indios (A Network Yarn) .................................. 7
A proposed International Policy .......................... 10
Kids & Computers ......................................... 13
A Sample Net Policy Document Neal Curtin 1:343/1 ......... 16
Proposed Zone 1 Policy ................................... 23
2. COLUMNS .................................................. 36
What is the Price of ECHOMAIL ............................ 36
Top Downloads 5/27/88 - 6/3/88 ........................... 39
3. NOTICES .................................................. 42
The Interrupt Stack ...................................... 42
Latest Software Versions ................................. 42
And more!
FidoNews 5-24 Page 1 13 Jun 1988
IDEAS FOR A NEW -AND BETTER- FIDONET
(Let's make some changes...)
Time goes by, and FidoNet grows every day faster. I don't
think that, when creating the Fido Bulletin Board System, Tom
Jennings knew he was starting something this big.
I have lately read some articles, where sysops express
their discomformity regarding the way things are going right
now, specially with IFNA.
Some sysops chose to form another, parallel net (like
Ryugen Fisher, for example), some others just expressed their
disappointness, and/or moved away from the "BIG net".
Trhu this article, I want to give your my opinion, and to
present you a new idea, a new idea that also contains new
concepts.
From my point of view, DEMOCRACY (not a "new concept"!)
doesn't exist on FidoNet. And when one of the basic things
needed for a large group to survive is not present, it is likely
to fall in an anarchy, where everyone does what he/she wants, no
matter what.
When you live in a country that has a democratic
constitution since 1853, and that while democracy lasted was one
of the most rich and one of the TEN worldpowers and when it lost
democracy, went from being THE RICHEST in the world to one of
the poorest (yes, Argentina was *the richest* country in the
world after WW2, and please, don't ask how it is right now...),
you learn how important democracy is, for something to survive.
I think something MUST BE DONE in FidoNet, before it is
"too late".
The FidoNet nodelist has already 3000+ members, in all
the 5 continents of the world, on about 30 countries. FidoNet
has become a totally INTERNATIONAL network, rather than an
"American one with some nodes overseas".
One of the main purposes of this new concept is to
prevent the desintegration of FidoNet, as well as to make the
actual conditions (a lot) better.
In Latin America we are just starting with the net. There
is still a "familiar climate" within the net, and everybody
cooperates with each other, but as we read some echomail
conferences or FidoNews, we ask ourselves: "Is it gonna happen
the same way down here? Are we working so hard just to get to
that point?".
What I want to propose is the following:
One "FidoNet Association" is created for each of the 4
zones (I'm assuming Latin America as Zone 4).
Those associations may vary in their internal
organization, since each zone's requirements and neccesities are
very different.
When they are finally established, each designates 3
members to take part on the International FidoNet Council, that
is finally formed by those 12 representants of the 4 zones.
FidoNews 5-24 Page 2 13 Jun 1988
Each zone has the right to have the presidency of the
Council for 6 months a year (each has the right to preside the
council once every two years).
The Council's president must be one of the 4
representants sent by the zone who designates him/her, and has
the right to a double vote when a votation is tied.
The International Council is in charge of various things,
like designating the International Technical Coordinator,
setting the technical standards (either directly or by naming a
"technical comitee"), publishing the net's official newsletter,
and establishing the net's basic, international rules.
Comprehensive rules are established by each zone's
association.
The International Council also acts as a "supreme
tribunal" for interzonal disputes. Any disputes within a zone
are to be arbitrated by the zone's association.
The Zonal FidoNet Associations are to be TRANSPARENTLY
DEMOCRATIC, which ensures the democratic qualities of the
International FidoNet Council, as well as of the net itself.
The Zonal Associations have the right to name the
coordinators for all the networks, regions as well as the
zone's.
I personally think this idea has still to be shaped
up. Anyway, the "main idea", that puts a special emphasis in
democracy, as well as on each sysops' right to determine their
coordinators, authorities and delegates to the main,
International Council, is there.
I would like everybody to participate in the development
of this new idea, to ensure it's representability of all the
sysop's wishes.
Please, send mail to node 1200/1 with your opinions (in
North America, you can send it thru 135/14 which is the gateway
to Latin America).
If FidoNet's current authorities, as well as IFNA's
AND a large group of sysops consider the idea feasible, an
echomail conference could be created to ensure everybody's
participation on the development of this new idea.
Thank you for taking the time to read this article, and
thanks IFNA for maintaining a publication where everyone can
express oneself freely.
Pablo Kleinman (1:1200/1 aka 1:60/0)
Sysop's Elected Latin American RC
Buenos Aires, 28 de Mayo de 1988.
Recently there has been a push to clean up the baud flags in the
nodelist. It seems they often get misused and it also seems
that sysops are not following any standard in their use or
nomenclature. Apparently there is a host of new software
becoming available that depends on the correct use and code for
the baud flags, and so an effort is underway to get these
nodelist flags cleaned up. Therefore, this seems like an
opportune time to talk about the use of the #CM: flag.
From my discussions with local sysops it would appear that the
#CM: flag is greatly misunderstood and often misused. To begin
with, the #CM: flag refers to "CONTINUOUS MAIL" capability, not
"CRASH MAIL" capability. There is a distinct and important
difference. Many sysops are running bulletin board and/or
mailer software that supports CRASH mail, but do not have their
systems available for incoming mail 24 hours per day. The #CM:
flag means that you are able to accept mail anytime day or
night, 365 days out of the year (barring unforeseen acts of God,
or nuclear holocaust). In other words, to qualify for the #CM:
flag, you have to have CRASH mail capability AND be running a
system that accepts incoming mail at all times.
The above description would probably get you past the FIDONET
boarder patrol in terms of qualifying you for the #CM: flag, but
there is more to consider. A #CM: "purest" would argue that to
REALLY qualify, you would have to be able to release any
outgoing mail destined for a system that happens to call your
system delivering mail. For example, lets say you are system
X/1 and have some mail to go out to system Y/1. Your outgoing
mail for Y/1 has not been labeled as CRASH mail. Your intent is
for the mail for Y/1 to go out during your next regularly
scheduled mail event (perhaps National Mail Hour). But prior to
your next mail event, system Y/1 happens to call your system to
deliver mail (completely unaware that you have mail for him).
The ideal #CM: system would release the mail to Y/1 at that
time, eliminating the need to wait until X/1's (your) next mail
event, and also preventing X/1 (you) from picking up the cost
for the mail intended for Y/1. Having this kind of continuous
mail capability requires a little more routing finesse. In
order to build a system with this "mail releasing" capability
requires you to have outgoing mail "bundled" at all times
because you cannot predict when a call will come in for which
you happen to have some outgoing mail. How do you do that? It
is really quite easy. The following description refers to how I
do it using SEAdog. I am sure there are other ways to
accomplish the same thing (perhaps even better ways, though I
doubt it). I do not know how this would be accomplished using
OPUS, or Binkley, or any of the myriad other mailer programs. I
only speak SEAdog, I've never learned OMMM (is that some
mystical East Indian mantra???). You'll have to suffer through
someone else's description of this stuff to learn how to do it
with other software.
FidoNews 5-24 Page 4 13 Jun 1988
The idea, as I said before, is to have all outgoing mail bundled
and to give SEAdog permission to release all outgoing mail at
all times. With this in mind, the routing commands are
straightforward:
Hold All
Send-to All
Give-to All
This combination of routing statements bundles all of your
outgoing mail with a "hold" flag on each parcel, and gives
SEAdog permission to release any parcel when the destination
system happens to call in. Now, all that remains is to give
this set of commands a routing tag and stuff that Schedule in
between all your other events. Lets say you give this set of
commands the Schedule J tag (that just happens to be the tag I
am using for this purpose). Now lets say a segment of your
CONFIG.DOG looks like this:
event X40 All 01:00 ;some external event
event C All 01:00 02:00 ;a 1-hour mail event
event D All 03:00 04:00 ;another mail event
You have an hour in there (from 2 until 3 in the AM) when you
are not in a mail event. You are going to want to stuff your
Schedule J in there so that, if a system for which you have
outgoing mail happens to call during that time period, your mail
to him will be released. The revised CONFIG.DOG segment would
look like this:
event X40 All 01:00 ;some external event
event C All 01:00 02:00 ;a 1-hour mail event
event J All 02:00 03:00 ;HERE'S THE BEEF
event D All 03:00 04:00 ;another mail event
As described in the preceding example, you would go through your
entire schedule of events in CONFIG.DOG and stuff "event J" in
between all of your other events such that you are running
"event J" at all times that you are not involved in some other
scheduled event.
There are a couple of other considerations: Most of you
probably are running a bulletin board as well as running a
mailer, and want the ability to have incoming "human" callers
(although I have heard more than one sysop say that they could
run a really neat BBS if people would just stop calling it...).
Remember to add the "BBS" statement in conjunction with each
"event J" so that SEAdog will know to relinquish control to your
BBS when a human calls in during one of those events.
event J All 02:00 03:00 BBS
^^^
Secondly, you are likely to have large blocks of time where you
have no other scheduled events and will want to be running
"event J". For example, I don't have any events to speak of on
FidoNews 5-24 Page 5 13 Jun 1988
my board between 6am and midnight the following day. It is
possible to put one "event J' in there to fill in that entire
block of time. However, that is not extremely desirable because
it limits your use of CRASH mail events. Let me give you an
example. Lets say it's noon and I'm on my lunch break (one of
the few times during the normal business day when I get to play
with my bulletin board). I decide to send some CRASH mail, so I
compose the messages and attach the CRASH flag, then go and eat
my day-old tunafish sandwich. The system will go about its
business attempting to send out my messages, but if the
destination system happens to be busy and the mail does not go
through, then "event J" would be re-installed and the system
would not attempt to send the CRASH mail again until the next
time I have a scheduled event, which in this fishy example, is
not for several more hours. The way around this problem is to
avoid an "event J" that covers multiple hours. Instead, start a
new schedule J every hour when you have large blocks of time in
the day without other scheduled events. Here is an example of
another segment of my CONFIG.DOG that demonstrates this:
event J All 12:00 13:00 BBS
event J All 13:00 14:00 BBS
event J All 14:00 15:00 BBS
...and so forth and so on
Oh...if that weren't enough... to bore you even further with
additional trivia about the #CM: flag, there is one more
consideration that comes to mind. We need to turn this thing
around and look at it from the opposite direction. Lets say you
are sending out CRASH mail and the destination system happens to
have mail waiting for you to pick up, and the sysop of that
destination node has read this silly article and has sprinkled
"event J's" throughout his CONFIG.DOG. His mail for you is
properly bundled and waiting for your call, and his SEAdog has
permission to release mail to you if you happen to call in.
Unfortunately, if you are using SEAdog's predefined "Schedule S"
for your CRASH mail event, you won't pick up your mail even if
the sysop of the destination node has gone to the trouble to set
it up this way, because SEAdog's Schedule S is defined as "Send-
only" (that's what the "S" in Schedule S stands for guys). So
your system will not look for mail addressed to you when it's
out delivering your CRASH mail. There is a quick fix to this
problem however. Simply define a "Schedule S" in your ROUTE.DOG
and give it one simple command:
Schedule S
Pickup All
If you follow the above suggestions, you will have a system that
truly qualifies you for the use of the #CM: flag. You will
accept incoming mail at all times, you will have outgoing mail
bundled and will release those mail packets if they are
addressed to incoming "mail" callers, and you will pick up mail
FidoNews 5-24 Page 6 13 Jun 1988
addressed to you when you are sending out CRASH mail.
Remember, the #CM: flag is preceded with the "#" sign. It is
one of a group of baud flags that indicate the time of day your
system is available for incoming mail. The other members of
this group reflect the beginning of an hour in Greenwich Mean
Time:
#09: Accepts incoming mail beginning 0900 GMT
#18: Accepts incoming mail beginning 1800 GMT
...and
#CM: Accepts incoming mail any ol' time
and lastly (as if that weren't enough), remember that the #CM:
flag is followed with a colon (:). All baud flags are followed
with a colon. If you have several baud flags assigned to your
system, they should be separated by a comma. For example, the
baud flags for my system are:
XP:,#CM:
Next month we'll talk about the XP: flag (gag! belch!...)
Dave Davidson
OPTOMETRY ONLINE
100/514
(Region 14 Coordinator)
Ron jumped up from his desk and began pacing furiously.
"Stupid self-serving twits!" he bellowed at his computer
screen.
A shadow in the doorway startled him.
"Indios? Oh! I wasn't ... I mean ... sorry if I disturbed
you."
Indios was the caretaker and general handyman for the
condominium complex where Ron lived. Rarely did he pay much
attention to anything other than his duties.
"Your sink is fixed." he said with his deep, gravely voice.
"What upsets you?" the old Indian then asked through lips that
barely moved.
"Ahhhhh, I dunno! I am sick and tired of everyone treating me
like dirt!"
His dark, withered face frowning, Indios shuffled his large
frame to an overstuffed chair and sat down.
"How do they do this? I am not understanding."
Ron was surprised. In over 2 years he had never known Indios
to solicit a conversation.
"Well, some people are real idiots and think they know it all.
They like to lord over other people, pretending they are
smarter or better. All they really have are big mouths! I am
going to start defending myself! I am going to be more
assertive!"
"Tell to me the difference of you being 'assertive' and them
having 'big mouths'?" Indios asked without expression.
Ron did not answer.
"You sit in front of this for hours," Indios continued,
pointing to the computer on Ron's desk, "and it angers you.
How can this be?"
"It started off to be fun," Ron answered, "then everyone
started flaming at each other!"
Ron could see that he was only confusing Indios.
FidoNews 5-24 Page 8 13 Jun 1988
"See, with the computer, a bunch of people can leave messages
to each other. It's like a big hobby for computer buffs.
There is an amateur network that I belong to where we can leave
mail. It was fun until it became too crowded. Now everyone
just fights with each other. If someone misspells a word,
someone jumps on him. If someone asks a question or has an
idea that someone else thinks is stupid, then the name calling
starts. We call it 'flaming'."
Indios grunted and nodded that he understood.
"So, you meet people on your machine so you can get angry at
each other. You go to work and your clubs and get angry at
others. Driving your car makes you angry at others ..."
"Exactly!" Ron exclaimed. "Unless you stand up for yourself,
someone will walk all over you! Believe me, when someone
shoves it to me I am going to pay them back in spades!"
The Indian brushed his long, white hair back with his weathered
hands and looked sadly at Ron.
"So much anger ... This will make you better than them? Anger
can at times be a tool but, like a surgeons knife, it should
only be used when all else has failed and the cause is just ...
only then with great care and control. Most swing this blade
recklessly and wound themselves."
"I am sick and tired of reading this crap! I am sick and tired
of these pious bastards jumping on every little thing I do!"
"Maybe they have a fear ... maybe they have a need. The
smallest pups always growl the loudest. The others that are
secure will allow this because they know these pups have needs
that only can be provided for by their pretending dominance.
Even with wolves, the strongest and fastest in the pack will
allow the pretenders their moments, as they know it is their
need and all they can really achieve."
Now Ron was puzzled. "You mean I should just ignore these
twinks?! That I should let them say vile things about me and
others?!"
"Do they strip you of your honor? Are you denied all dignity?
Your family was not threatened, your ability to provide for
those that depend on you was not threatened ... your honor was
not taken."
"I have my pride!"
"Pride is not honor. You must know when NOT to fight before
you will ever know when it is proper TO fight. Your words of
anger are that of a child. Show me the burial sites of those
killed by mere words ..."
Ron knew he was losing the debate. This one was face to face
FidoNews 5-24 Page 9 13 Jun 1988
and the words had texture, tone and emphasis ... not like text
written on a flat monitor screen.
"Take what is good with this and all else in life and leave
behind what is bad." Indios continued, leaning forward, his
eyes fixed in a gaze at Ron. "I know enough about you to say
that you were granted neither the natural gift of a powerful
body nor a powerful mind at birth. You were granted a more
valuable gift, the gift to build whatever body and mind you
choose. There are no boundaries for this gift. All you do,
every day, in all walks, makes you what you are and what you
will be."
Indios then stood and walked to the doorway. Ron remained
silent.
"Will you build your body and soul of sound materials or will
you use the waste of the earth and become all that you
despise?" Indios asked with a hint of a smile as he departed.
Ron strolled slowly back to his desk and sat down in front of
the computer. He hit a key to awaken his blank screen and then
began rereading the message that had upset him earlier. After
a moment he moved on to the next message, leaving the hate
unanswered.
"We're just puppies ... " he mumbled under his breath. "I
guess Fido grew up and had a whole lot of puppies ..."
He then began a reply to a message from a friend in Puerto
Rico. "Take what is good ..."
FidoNet is the worldwide collection of Bulletin Boards that
operate under a protocol established by Tom Jennings called Fido.
The basic structure of the network is as follows, from the lowest
point to the highest.
POINT: A point is the lowest subdivision, and is a system
that is mail only and will only connect to a parent or BOSS node.
It is not listed in the nodelist.
NODE: A node is the lowest public position in the nodelist.
It is normally a fully functional system that can act as a
bulletin board and also send and receive mail and files.
HUB: A hub is a system which is set up to provide a service
to a small group of nodes that is a sub geographical group of a
net.
NET: A net is a geographical collection of Nodes that has
banded together in order to share common interests or reduce
costs.
REGION: This is a collection of nets and independent nodes
that are contained in a larger geographical or geopolitical
entity. The net may also be a special interest group.
ZONE: The zone is a larger collection of regions and nets.
Currently there are three zones, zone1 is North and South
America, zone2 is Europe and Africa, and zone3 is Australia and
the South Pacific area.
There are additional zones, but these are large networks that
do not want to directly participate in the FidoNet Nodelist. They
are zone7, AlterNet, and zone99, GoodEggNet. Communication can be
established with these zones either by means of zone gates or by
including them in your local nodelist.
SECTION II: LEVELS OF FIDONET
The FidoNet Network is broken down into many different
levels much as the hierarchy within any efficient
organization. Thru past history, the following hierarchy has
developed:
1. All System Operators (SysOps) taken collectively
(FidoNet). This is the highest level of the structure, and
represents the entirety of FidoNet.
FidoNews 5-24 Page 11 13 Jun 1988
2. International Coordinator (IC) This position is an
administrative position and is responsible for the publication of
the Nodelist. The IC is also the court of last resort in disputes
between zones.
3. Zone Coordinator (ZC). This position oversees one Zone
of FidoNet and is responsible for the smooth functioning of
FidoNet within that Zone. The ZC is the court of last resort
within his zone, unless the dispute is inter zonal in nature.
4. Regional Coordinator (RC). This position oversees
one Region within a Zone and is responsible for the smooth
functioning of FidoNet within that Region.
5. Network Coordinator (NC). This position oversees one
Network in one Region and is responsible for the smooth
functioning of FidoNet within that Network.
6. SysOp. This is the singular unit of FidoNet. The
SysOp runs his or her own FidoNet capable software such that their
system can function as part of FidoNet within the guidelines
imposed by the various levels of FidoNet above the SysOp level. Those
guidelines are formulated over time as defined in this document.
SECTION III: RESOLUTION OF DISPUTES
Disputes are bound to arise, and the solutions are
many. This document is cover only disputes which are between
zones. Each zone is to develop it's own policy statement for
disputes within it's own area, and each region/net is encouraged
to set up it's own policy, not to conflict with a higher policy.
1. A zone council will be set up comprised of three regional
coordinators from within each zone. In case of a dispute between
zones, a disinterested zone will be selected to act as a court.
Each zone will submit their side of the dispute, not to exceed 10
pages, to the selected zone council. The zone council shall then
make their decision with 10 days of the submittal. The majority
rule applies. Appeals may be made to the IC, who may also form a
council. The IC decision will be final, and there will be no
further mediation.
2. The IC council will consist of at least 2 regional
coordinators from each zone. They will review the same submittal
as the zone council received, and will make their decision in 10
days.
SECTION IV: POLICIES
Each zone is responsible for setting up a zone policy.
This policy will detail the requirements for a Zone Mail Hour
(ZMH), the handling of echo mail, the responsibilities of the
various regional coordinators, and any special conditions which
may exist.
FidoNews 5-24 Page 12 13 Jun 1988
Section V: INTERNATIONAL COORDINATOR
Because of the high position of trust that the IC must
hold, the position must be filled by someone who has not only the
technical qualifications, but must also be free from political
constraints. For this reason, the IC must not hold any other
position with the entire FidoNet community. When the position
becomes vacant, the senior ZC will assume the position until a
new IC can be elected.
The election procedures are as follows:
1. The RC's will nominate a slate of potential
candidates from within their zone. These candidates will then be
proposed to all the NC's, RC's within the zone will elect one
candidate for a inter zonal election.
2. The candidates from the zone elections will then
submit their position in the FidoNews for reading by all the
members of the community. The election will then be held.
3. The time frame for the election of the IC must be
short, and should be accomplished within 30 days.
4. Voting will be done by nets, regions, and zones.
Each net will hold an election process, results to forwarded to
the Region. The Regional independents will vote through the RC.
The RC will forward the Region vote to the ZC. Only votes will be
counted. Abstensions will not count. A pure majority will decide
the outcome.
RECALL procedures.
1. A recall can be initiated at any level.
2. A majority in a net or a region or a zone is
required to start a recall election. The recall election will be
conducted in the same manor as the IC election, but will be a yay
or nay vote only. Upon completion, the IC must abide by the
decision.
3. Each operating area will only be able to start one
protest per year.
1. PURPOSE: The purpose of this document is to deleniate
responsibilities, guidlines, and proceedures for the users
of the KIDS Echo Conference.
2. SCOPE: The KIDS Echo Conference was established to allow
young people up to the age of 18 to have freedom of
information interchange in an environment that is directed
primarily toward an adult audiance. Allowing our children to
have an area of thier own is necessary to give our kids the
opportunity to expand their capabilities in the age of
electronics and home computing. Our children are our most
valued resources in the persuit of a future for a nation
with strong goals in computers. Our future belongs to them.
They are our destiny. The KIDS Echo Conference was designed
with them in mind. Therefore, each adult should encourage
its use and give it direction. Direction without
interferance except to insure that the echo is wholesome and
that it grows with common decency as viewed by the public as
a whole.
3. GENERAL: Teachers are encouraged to allow students to
send traffic such as Pen-Pal letters, history, trivia, and
anything that will encourage and assist in the growth of
their students. Utilize the echo as a training aid limited
only by your knowledge and immagination. Encourage the
exchange of information between students of different
geographical locations for computer science, history,
cultures, etc. Spread the knowledge of this echo to local
school boards and faculty for future projects in computer
science and as a aid in the students growth in a nation with
multiple goals in the arena of computer science.
Parents are encouraged to assist thier children in the
utilization of this echo. This will develope healthy
computing habits and keep the echo interesting for the
children. Parents are also encouraged to promote the echo at
school meetings like the Parent Teachers Accosiation (PTA),
open house funtions at the schools, and through any medium
that will assist the growth of thier children in this area.
Users are encouraged to submit suggestions, comments, and
ideas to help with the growth of this echo. The users are
the heart of the echo and its existance is dependant upon
your utilization of it. Promote a healthy environment which
is suitable for children. Use peer pressure as necessary to
stop any misuse of the echo. Remember the children of this
great nation are our future and they hold the key to the
advancement of a nation with strong goals in the computer
field.
4. RESPONSIBILITIES:
FidoNews 5-24 Page 14 13 Jun 1988
a. SYSTEM OPERATORS (Sysops): Sysops that request and allow
the KIDS Echo Conference on thier Bulletin Board System must
monitor the echo to insure thier users do not abuse other
users or the echo as a whole. This includes reporting any
misuse that the sysop cannot control to the Net Coordinator
or Echo Moderator as necessary. Sysops will not allow foul
language for any reason, missuse of the echo by adults and
children alike, and not allow what is commonly known as
"Flames". If a user utilizes the KIDS echo for message
traffic that is better served by another echo, then the
sysop will direct that user to the appropriate area/echo.
b. USERS: Users are responsible for the echo as a whole.
Therefore, misuse by the users can cause the termination of
the echo in part or as a whole. You must insure that foul
language is not tolerated and not used. Peer pressure is
your tool. Tell another user that he/she is incorrect in
using foul language and that this echo is directed toward
children under the age of 18. If the other user continues,
report it immediately to the System Operator. This can be
done in private as necessary. If the sysop does nothing in a
reasonable leangth of time, report the problem to the Net
Coordinator or to the Echo Moderator. You must utilize the
echo in the context of its design. Keep a healthy acceptable
attitude and enter messages that are suitable for the
children that use the echo. Promote the free exchange of
information and discourage misuse. Traffic such as love
letters, private messages, sexual remarks, racist remarks,
religous comments, and "Flames" are forbidden in this echo.
There are other echoes that allow that kind of abuse or
harrasement (Go there!). Wars are not allowed i.e. Johnny
picking on Joe, Grade 12 verses grade 6, Texas against Porta
Rico, country against country, unless they are in the
context of learning and then they must be from the text
book approved by the Educational Departments.
5. GENERAL INFORMATION: The following information is
submitted for your use as necessary:
a. KidsNews Newsletter: The kidsNews newsletter was created
by Brandy Witherspoon, age 13, of Edwardsville, Illinous,
Net/Node 100/525. She is the Editor and Chief of the
newsletter and has done an outstanding job in its content.
The newletter is maintained and utilized by the users of the
KIDS echo in sharing information, ideas, articles,
editorials, programs, trivia, etc. for the audiance which
the echo is designed for (kids 18 and below). Distribution
of the newsletter can be arranged through the Echo
Moderator or Echo Coordinator. If you would like to submit
articles in the newsletter, send it in the KIDS echo area or
through NetMail to Claude Witherspoon, 100/525. This will
ensure your article is included in the newsletter in a
timely manner.
b. Echo Coordinator: Paul Witherspoon, Net/Node 19/42, San
FidoNews 5-24 Page 15 13 Jun 1988
Angelo, Texas. Data-(915) 949-5645.
c. Echo Moderator: Claude Witherspoon, Net/Node 100/525,
Edwardsville, Illinois. Data-(618) 656-5447.
6. These guidelines are just that "Guidelines". The success
or failure of the KIDS echo is dependant upon your use or
misuse of the echo. Please give comments and thoughts of a
constructive nature to the Echo Coordinator and Echo
Moderator on any topic that has been covered here. You will
recieve a reply I assure you. Thank you for your time and
attention in reguards to the echo. I hope to be talking with
most of you in the future.
Claude Witherspoon
Net/Node 100/525
KIDS Echo Moderator
Policy and Procedures Guide
Net 343 version
Version 1
Chapter 1
OVERVIEW
1.1 The Levels of the Net
The Net is grouped on several levels. These are as follows:
o Network; The network is a collection of nodes,
specifically the city and surrounding territory of Seattle,
reachable from the central area of Seattle by a no-charge fee
from Pacific Northwest Bell.
o Hub; Any Hub will be an extension of the network coordinator
so as to increase the calling capability, or to extend the
net into a new area, until such time as they may be able to
form their own net. Hubs will be established for Echomail,
and for other purposes as may arise.
o Node; 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 Coordinator
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 Echo Coordinator; The node in the net that acts as a
FidoNews 5-24 Page 17 13 Jun 1988
gateway to the regional echo coordinator. The Sysop (or
system operator) of that node then acts as the coordinator
for the network. This Sysop will be responsible for the
coordination and distribution of all echo mail within the
net. Cooperation with the net coordinator is expected, but is
not required. The final decision on echo distribution will
reside with the echo coordinator.
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.
The primary responsibility of any coordinator is technical
management of network operations. Management decisions should
be made strictly on technical grounds.
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. NMH is defined as 1 AM to 2 AM, pacific STANDARD time.
This does not vary with daylight savings time. Additional time
for mail within the net is from 2 AM to 2:30 AM PST. This is to
allow for any mail received by the host (Coordinator) to be
distributed. THIS TIME IS TO BE A RECEIVE ONLY TIME. Only the
host will be sending during this time. During NMH and the net
mail time, no users (callers) are allowed.
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).
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.
Once you have a node list, you must then send Net mail to the
host, 343/0, during NMH. 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.
FidoNews 5-24 Page 18 13 Jun 1988
4) The phone number to be used when calling your system.
5) Your hours of operation.
6) The maximum baud rate you can support.
2.2 If you are going down
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 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.
COORDINATOR PROCEDURES
This chapter describes the procedures followed by the
coordinator at the NET level.
The coordinator has 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.
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.
FidoNews 5-24 Page 19 13 Jun 1988
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 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.
Assigning node numbers
A node number will not be assigned until a formal request from
that system has been received by FidoNet mail. This will ensure
that the system is at least minimally operational. Additionally,
that system will be checked to ensure that it can receive both
mail and files. Before accessing echomail, the system will have
to demonstrate that it can use the echomail system by using the
local NET343 echo. The strict maintenance of this policy has
been one of the great strengths of FidoNet.
Network mail will be used to inform a new node of his node
number, as this helps to insure that he is capable of receiving
network mail.
Problem resolution
If the problem is caused by a node within the net, then you will
contact the net coordinator, who will attempt to resolve the
problem. If the problem is outside of the net, then you should
contact the coordinator of the other net, but be sure that you
send a copy of the complaint to your own coordinator.
If the problem is with the region, send the complaint to the
network coordinators concerned, and to the regional coordinator.
Any complaints received by the network coordinator will be
forwarded to the regional coordinator for information purposes.
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.
FidoNews 5-24 Page 20 13 Jun 1988
Node list distribution
The node list is posted weekly on Saturday, along with a
"difference file" giving the changes for the week. The
nodediff will be distributed to each node as soon as possible.
It is recommended you make it available for download 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 will be
distributed in the same manor as the nodelist. It is also
desirable that you make it available for download by the
general user in both archive an non archive form, but this is not
required.
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.
Specific 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.
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 will be cause for a formal
complaint.
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
FidoNews 5-24 Page 21 13 Jun 1988
network, then his Network Coordinator can refer him to his
Regional Coordinator for reassignment as an independent node.
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.
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.
A Hub Coordinator may have additional duties, as assigned
by his Network Coordinator.
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
FidoNews 5-24 Page 22 13 Jun 1988
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.
This net shall be the one noted for non-flames. No one in this
net shall flame another in the net. If you are thinking of
flaming someone outside the net, be forewarned, a complaint filed
against you by someone outside the net, will be taken seriously,
and steps will be taken. We are friendly, loyal, trustworthy, and
HONEST.
Policy and Procedures Guide
Zone 1 version
Version 0.001
* * * P R O P O S A L * * *
Chapter 1
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. Multi net 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.
FidoNews 5-24 Page 24 13 Jun 1988
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:
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
FidoNews 5-24 Page 25 13 Jun 1988
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 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 2
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.
FidoNews 5-24 Page 26 13 Jun 1988
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 zone 2 National Mail Hour is
observed from 0900 to 1000 GMT every day, weekends included.
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
FidoNews 5-24 Page 27 13 Jun 1988
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
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 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
FidoNews 5-24 Page 28 13 Jun 1988
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 Massachusetts 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.
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 Zone 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.
FidoNews 5-24 Page 29 13 Jun 1988
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 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.
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.
FidoNews 5-24 Page 30 13 Jun 1988
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.
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.
FidoNews 5-24 Page 31 13 Jun 1988
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
The International Coordinator is elected by all regional
coordinators in all zones. In case of a vacancy, the senior zone
coordinator will assume the position until such time as a new
coordinator can be elected.
The International Coordinator is responsible for format of the
node-list and the update files.
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.
FidoNews 5-24 Page 32 13 Jun 1988
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.
A zone coordinator is responsible for the weekly zone and world
nodelist to be published in his zone on Saturdays.
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
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
FidoNews 5-24 Page 33 13 Jun 1988
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
acceptable 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.
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
FidoNews 5-24 Page 34 13 Jun 1988
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.
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
FidoNews 5-24 Page 35 13 Jun 1988
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.
(many thanks to Henk Wevers, who did most of this policy doc.
Minor editing is all that was needed to bring it into conformance
with the changed IFNA doc and the companion IPOLICY.TXT)
This article is going to deal with a subject which is getting
very close to my pocket book and many others as well. In recent
months it seems echomail has not only become popular with SySop's
but users as well. An the question has arisen who should pay for
echomail. This question like most others is fair, and deserves
an answer. Even if it may not be what most folks want to hear.
In recent weeks the feed for most of this region (15) has been
down. I find out by reading echomail, the feed is running six
(6), 9600 baud HST modems (wish I just had one). An he is
getting flamed left and right in almost every echomail area I
read. Then I am politely reminded by a little bird on my
shoulder. I do not know this guy from Adam, he is providing a
service to me and many of the other nodes in the western United
States, and his so called fellow sysops are Flaming him.
So I ask the QUESTION.
"WHAT IS THE PRICE OF ECHOMAIL?"
Like most everyone else except for a few I started picking up
echomail when it really got started. Presently I use two feeds,
one here in Region 15, and one from Region 19. Both are long
distance calls and presently average 10-15 minutes each. It just
so happens both feeds have been affected by the loss of the
western feed. So for a couple of weeks now, messages have been
sporadic to say the least.
I now carry 23 echo areas, some of which are used solely for
myself, and most which are forwarded to other nodes locally. But
I read every single message that comes into this board.
Basically since I have very few users, because I have not
advertised the BBS very much. The BBS is largely a message base,
in fact recently when my internal clock was reset to the year
1990 by a game my son plays. I lost or rather had killed over 7
megs of messages because they were over 15 days old. Yes, I had
read all of them but it makes you wonder. If I am a small system
and have over 7 megs of messages what do some of the other larger
systems have.
Recently purchasing a 2400 Baud Ven-Tel modem I hope to cut my
cost, I do not expect it to be cut in half or anything like that,
even a 50 dollar cut off of 137.00 will help. An if I figure it
right, a 50 dollar cut would pay for my new modem in about 8
months.
FidoNews 5-24 Page 37 13 Jun 1988
I now turn the topic of this article to the real subject. Just
who should pay for echomail? I say this cost MUST be shared by
all of us. If it cost my feeds $80.00 each a month to pickup
their echo mail, and they use a 9600 baud modem. You can figure
the cost of your echo mail using the following formula.
I am most certainly willing to support my feed in any way I can
but if I were to pickup all the echomail he received in a months
time frame, I would have already paid 4 times what he paid just
to get mail from him. But since I do my planning a little bit
ahead I am only picking up those areas I want to read. So my
cost is is not going to be the full cost of echomail to him.
An it would not matter to Ma Bell who gives them the money. If
my feed decided he was no longer going to allow me to poll him
for mail. If he was going to make all the calls and then charge
me a rate comparable to his phone cost. He would in fact, be
doing me a favor, except it would still cost me XX dollars per
month. It is now up to me to decide what I am willing to pay for
my end of echomail.
So what I am going to PRESUME IS:
1. It will cost me to call my feed.
2. Or it will cost me to have him call.
Either way, I will be paying out of my pocket.
I now ask, which is easier? Of course, I call him. I do it at
my own time, when he allows me to do so, normally between 0200
and 0500 in the morning. The cheapest time to call. So
basically it means: ECHOMAIL is going to cost me exactly what I
am willing to pay for it.
As the local and Net 301 feed, I am making several proposals to
those who I distribute mail to on how WE can solve this problem
which will soon face us. They are the only ways I know of US
maintaining our connection.
FidoNews 5-24 Page 38 13 Jun 1988
So it all comes down to these few simple FACTS.
What Price of EchoMail is what you and I are going to be willing
to pay for it. I personally want it as cheap as I can get it.
My wife wants it cheaper. Even if as she put it, it means
cutting back in the number of areas I receive, or telling those
nodes who I make distribution to locally presently at no cost,
except to one who has already agreed to pay his fair share, they
will have to find other means of obtaining the echos they want.
But then if I was a distribution point I would not want 3 or 4
nodes from the same area making pickup. So one way or the other,
MY price for EchoMail will be my monthly PHONE Bill.
Top Downloads: 5/27/8 - 6/3/88
A weekly report of the most popular downloads
from contributing FidoNet systems. Report created
on June 9.
Contributing systems:
135/1
(380/2 - I guess you couldn't get through because of our disk
problems).
Because I'm getting ready to install, format and copy 170
floppies worth of files onto a new hard drive as well as change
some of the look of RAM-SOFT, I'm just presenting you with a
higly edited (not all files are listed) version of the system
report from LogRpt. For those seeing this column for the
first time, this is NOT the way it usually looks.
Although we managed to be up for all but 3 national mail slots in
the past two weeks, we have been down during the day quite often
and the stats look sick compared to previous weeks. Hopefully in
the 6/20 issue we'll be back to normal. (Our other sysop picked
a great week to take a vacation!)
Report for the days 27 May through 02 Jun for a total of 7 days
Statistics based on the board being available for 22.0 hours per
day with a total of 50.0 calls possible per hour.
Total number of calls: 185
Total minutes BBS was in use: 2501 Min.
Average call duration : 13.52 Min.
Utilization of the BBS : 32.48 %
File transactions Average per day
---------------------------------------
Downloads: 137 19.57
Uploads : 11 1.57
Number of new calls: 96 (starting from 0 users, that isn't bad)
Busiest hour was : 0000
FidoNews 5-24 Page 40 13 Jun 1988
Transfer methods total
-----------------------------
SEAlink download/upload: 21
Telink download/upload: 8
Xmodem download/upload: 77
Ymodem download/upload: 11
Zmodem download/upload: 31
FidoNews 5-24 Page 41 13 Jun 1988
External download/upload: 0
If there are any other systems interested in having your
download stats included in this weekly column, please send me
your system via net-mail at 135/1. The complete system report
from LogRpt so I can include utilization stats would be ideal
but is not required. If there are filenames that may not fully
indicate what the file is, please let me know. If there is a
file you particularly want me to list, let me know. I need
to have the information by Monday's Net-mail time in order to
get the stats compiled. Please keep your reports at 7 or 8 days,
Friday to Friday if possible and no longer than 10 days. (We
can accept net-mail anytime of the day [when our HD works] and
are PC-Pursuitable).
James Gilbert
RAM-SOFT Archive Library (9600HST)
1:135/1
18 Jun 1988
Area Code 407 takes effect in East/Central Florida. All Sysops
should adjust their Nodelist entries immediately.
25 Jun 1988
EuroCon II starts in Tiel, Holland. Sponsored by the Dutch
Hobby Computer Club. Will run for 2 days. Contact Hans
Lichthelm at 2:2/999 for information.
16 Jul 1988
A new areacode, 508, will form in eastern Massachusetts and
will be effective on this date. The new area code will be
formed from the current areacode 617. Greater Boston will
remain areacode 617 while the rest of eastern Massachusetts
will form the new areacode 508.
25 Aug 1988
Start of the Fifth International FidoNet Conference, to be
held at the Drawbridge Inn in Cincinnati, 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.
Don Daniels, President
International FidoNet Association
FidoNet 1:107/210
IFNA Status Report for June 1988
PROGRESS DURING THIS PERIOD
General
First of all, I'd like to report that FIDOCON '88 preparation is
still charging ahead. There is a great deal of preparation and
additional effort being expended to make this the biggest and
best FIDOCON ever.
From what I hear, there is an exciting key-note speaker lined-up:
one of the innovators and "mavericks" of the industry. I'll let
the Conference Organizing Committee give you the details when
they're positive that everything is finalized, but it looks like
this will be another highlight. The Committee seems to be going
all out to provide a wide-range of topics, from the very
technical to the important political issues that need to be
resolved. If you hurry, I think you may still have a chance at
the drawing for the U.S. Robotics 9600 HST modem, so get your
registration in now!
Meanwhile, quite a few other activities are underway that sound
very exciting. Should they continue in the direction they appear
headed, it looks like we will have a lot of work to do, but will
stand a very good chance of bringing real distinction to FidoNet
through IFNA.
The first of these, headed up by David Drexler, involves support
for the younger set. There already is a KID'S NET which was
started by the Witherspoon family, I believe. They've given us
some ideas and help and Dave has been able to make several
contacts in related areas. In one such undertaking, several
hundred schools in the U.S. and Australia are already linked
through a commercial network supported as a pilot project by one
of the major carriers. It looks like that support may not
continue into the fall and there may well be a chance for us to
step in and provide some real cost-effective assistance to the
schools that wish to continue.
In another project led by IFNA Vice-President Mark Grennan, a
specially modified mailer is being developed that can be used by
the blind. Several institutions that support the blind are very
interested in the potential of this approach and have indicated
various levels of support. There are still a few problems to be
worked out, but hope is high that we can make quite a
FidoNews 5-24 Page 45 13 Jun 1988
contribution to this segment of our population.
Still another project deals with support for the deaf. Due to
manning problems, we've had difficulty in getting this one
underway. We could use help on all these areas, but particulary
this one which has initial contacts in the D.C. area.
These and other activities going on behind the scenes hold a
great deal of promise for FidoNet to make even a far greater
influence than it already has. But with this potential comes
considerable responsibility and it it very necessary for us all
to settle some of the political and technical issues that
separate us, thereby making it possible for those that wish to
and can support such beneficial endeavors to do so.
Please, if you believe in such activities, make a real attempt to
come to FIDOCON. We need your support and energy to clear some
of the obstacles between us and some really worthwhile
contributions to the public.
ADMINISTRATION AND FINANCE
Unfortunately, Greg Small, who filled the empty Chair of this
committee, has been beset by some overpowering personal
considerations and has had to drop out. This leaves us again,
without a leader for this important area. Certain aspects are
proceeding along regardless, such as the financial work by
Leonard Mednick and various projects by Steve Bonine. But we do
need someone who can organize a great many administrative
services and requirements to make us all more efficient.
BOARD OF DIRECTORS
The BoD has resolved the technical difficulties encountered with
its recent management changeovers. Voting reports appear weekly
in IFNA, so I'll not repeat them here.
BY-LAWS AND RULES
No formal report was received from Steve Jordan. However, we
have been involved in several discussions regarding some
much-needed amendments to the By-laws. Steve's committee is
finalizing the rules for this summer's vote on the suggested
amendments.
EXECUTIVE COMMITTEE
As most of the members of the Executive Committee are forced to
do double duty on other matters, the efforts involved in
replacing Tom Marshall who resigned as Secretary due to personal
and professional concerns, have taken up most of the available
time.
FidoNews 5-24 Page 46 13 Jun 1988
My personal thanks to Tom who has contributed a great deal of
service to FidoNet.
INTERNATIONAL AFFAIRS
No official report was received from Henk Wevers, but he has told
me that they are expecting 120 or more for EuroCon II. Those of
us that will be attending are looking forward to this event - in
my case, I expect it to provide additional input towards our
preparation for FIDOCON.
MEMBERSHIP SERVICES
Phil Ardussi informs me that the tapes from last FIDOCON are
finally ready and will be available at this year's conference.
Plans are already underway for next year's conference. They are
putting the finishing touches on the forms and processes for
evaluating bids for FIDOCON '89. It is expected that bids will
be requested and received in time to make the decision and
announcement at this year's conference.
NOMINATIONS AND ELECTIONS
The chairmanship of this committee was just changed from David
Garrett to Rob Barker on the request of the BoD. Although the
By-laws don't specifically say so, it appears that their intent
was to maintain separation between the IFNA Secretary and the
functions of this committee. Therefore, as David Garrett has
just been elected the new Secretary of IFNA, he was asked to
relinquish the chair. Our thanks to David for his recent efforts
in handling the nominations and working toward the establishment
of the rules for the upcoming election.
PUBLICATIONS
No report was received on this matter from Tim Sullivan (who
is presently concentrating his efforts on FIDOCON!).
TECHNICAL STANDARDS
No report was received from Randy Bush.
ETHICS COMMITTEE
No specific report was received from Bill Allbritten, but I did
get a copy of a draft of a Standard of Ethics for the leadership
of IFNA. I was very impressed with this document, as it appears,
in addition to spelling out various standards of performance and
conduct, to really provide the membership with an independent
mechanism for monitoring the officers and directors of IFNA.
FidoNews 5-24 Page 47 13 Jun 1988
There are still some details to be cleaned up, but I'm confident
everyone will be impressed at the reasonable scope of this
document.
VP-TC
Dave Dodell did not provide a report.
FIDOCON LIAISON
Tim Sullivan's report was summarized above.
PROBLEMS
As can be seen from the above, the extra burdens and lures of the
encroaching summertime have cut into the remaining time available
for FidoNet. This demonstrates that there are plenty of
opportunities for others to get involved and take on some of the
load. In fact, I would really like to call for a maximum limit
on the number of "hats" an individual can wear, due to the
difficulty so many have trying to meet the many other requirments
of life and sysoping.
PROGNOSIS FOR NEXT PERIOD
We are really looking forward to some of the various projects
currently underway coming to fruition.
And of course, FIDOCON should be a marvelous opportunity for us
to get together and continue the new understanding and desire to
work towards solutions that seems to have started to take hold
throughout the Net.
Ken Kaplan 100/22 Chairman of the Board
Don Daniels 107/210 President
Mark Grennan 147/1 Vice President
Dave Dodell 114/15 Vice President - Technical Coordinator
Tom Marshall 107/524 Secretary
Leonard Mednick 12/1 Treasurer
IFNA BOARD OF DIRECTORS
DIVISION AT-LARGE
10 Steve Jordan 102/2871 Don Daniels 107/210
11 Bill Allbritten 11/301 Hal DuPrie 101/106
12 Leonard Mednick 12/1 Mark Grennan 147/1
13 Rick Siegel 107/27 Brad Hicks 100/523
14 Ken Kaplan 100/22 Ted Polczyinski 154/5
15 Jim Cannell 128/13 Kurt Reisler 109/74
16 Vince Perriello 141/491 Robert Rudolph 261/628
17 Rob Barker 138/34 Greg Small 148/122
18 Christopher Baker 135/14 Bob Swift 140/24
19 Vernon Six 19/0 Larry Wall 15/18
2 Henk Wevers 2:500/1 Gee Wong 107/312
If you pay by Credit Card you may also register by Netmailing
this completed form to 108/62 or 1/88 for processing. Please
complete the information below and be sure to include a voice
phone number above so that we can contact you for Credit Card
FidoNews 5-24 Page 51 13 Jun 1988
verification. Rename this file ZNNNXXXX.REG where Z is your Zone
number, N is your Net number, and X is your Node number.
[ ] Visa [ ] MasterCard
Name as it appears
on credit card: ___________________________________________
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
