F I D O  N E W S --                   Vol.10  No.14    (05-Apr-1993)
+----------------------------+-----------------------------------------+
|  A newsletter of the       |                                         |
|  FidoNet BBS community     |         Published by:                   |
|          _                 |                                         |
|         /  \               |      "FidoNews" BBS                     |
|        /|oo \              |       +1-519-570-4176     1:1/23        |
|       (_|  /_)             |                                         |
|        _`@/_ \    _        |       Editors:                          |
|       |     | \   \\       |         Sylvia Maxwell    1:221/194     |
|       | (*) |  \   ))      |         Donald Tees       1:221/192     |
|       |__U__| /  \//       |         Tim Pozar         1:125/555     |
|        _//|| _\   /        |                                         |
|       (_/(_|(____/         |                                         |
|             (jm)           |      Newspapers should have no friends. |
|                            |                     -- JOSEPH PULITZER  |
+----------------------------+-----------------------------------------+
|               Submission address: editors 1:1/23                     |
+----------------------------------------------------------------------+
|  Internet addresses:                                                 |
|                                                                      |
|    Sylvia -- [email protected]                       |
|    Donald -- [email protected]                    |
|    Tim    -- [email protected]                                      |
|    Both Don & Sylvia    (submission address)                         |
|              [email protected]                    |
+----------------------------------------------------------------------+
|       For  information,   copyrights,   article   submissions,       |
|       obtaining copies and other boring but important details,       |
|       please refer to the end of this file.                          |
+----------------------------------------------------------------------+
========================================================================
                         Table of Contents
========================================================================

1.  Editorial.....................................................  2
2.  Articles......................................................  2
     The Cynic's Sandbox, v2.0ReallyWideAlphaForAnyOne...........  2
     Why Policy 4.1C deserves our serious attention..............  4
     Commodore Geos Echo Available...............................  6
     Responce to Stanton McCandlish..............................  6
     OS2 echos...................................................  9
     Policy Proposals: The Cart Before the Horse?................ 10
     Rebuttal to an Anonymous Critic............................. 14
     FidoNet Policy Document Version 5........................... 17
3.  Fidonews Information.......................................... 48
FidoNews 10-14                 Page:  2                    05 Apr 1993


========================================================================
                             Editorial
========================================================================
We Lied.

There are TWO policy documents in this issue, although there
won't be any more, probably.

We are getting bulges of requests for information about sending
mail from FidoNet to Internet, and queries from exotic sounding
internet addresses about how to "get on" FidoNet.  For example,
to whom and where should we refer someone in the Dominican
Republic who wants to start a BBS?  Also, during said mail bulges
i managed to lose an announcement about a Chinese language
e-'zine and would its sender very kindly re-send it?

Spring is coming easily la-de-da, cactuses between cabling on
tables are sprouting little green things.  I'm still waiting for
my monitor to sprout.  Why is it difficult to get anything
started when beginnings happen so naturally in plant-life?
Vine-like networks tangle around and i just watch.  It is too
easy to be inert and accepting unless some buttons are pushed
and rewards are possible.  Not much truly interesting seems to
happen unless somebody tries something new simply to try
something new.

oh...whaa...excuse me, D.T. [ET in moments such as this] in
muttering something over my shoulder about how God is a computer
who invented man as a bootstrap loader...

"man".  Hrrrumph.  Try wiring a net without gender changers.
========================================================================
                              Articles
========================================================================
The Cynic's Sandbox, v2.0ReallyWideAlphaForAnyOne
R. Cynic

It's Spring, it must be time for a policy proposal.

Boy, and I was getting bored with Fight-O-Net.  Now we have
Pol5, Pol4.1c, caller ID, and another well-thought-out-type-
III-packet-proposal-which-will-be-ignored-until-someone-writes-
code.  I don't think I've ever had so much fun with clothes on.

I'd like to take this moment, if I may, to submit the R. Cynic
Pol6 Proposal, which I hope you'll all examine with a 10x
magnifier.

Policy Six
Final Version
1 April 1993

0.  Legal Stuff
This document is FraggleWare.  To register, sing the Fraggle
FidoNews 10-14                 Page:  3                    05 Apr 1993

Rock theme.  You forgot the last verse.  Try Again.

1. Overview

Fight-O-Net is a whole buncha systems with little more than
FTS-0001 in common, and sometimes, if they run FrontDoor, not
even that.

2. Language

The official language of Fight-O-Net is english, preferably
with as many fancy technical words as you can think of to
confuse the hopeless newbies and teen sysops.

3. The Rules

3.1  The Boss

Fight-O-Net should be controlled by whoever's screaming the
loudest for democracy.  Anyone who wants it that badly should
be allowed to go nuts trying to run it.

3.2  Complaints

Policy Complaints should be referred to node 1/1, along with
all other junk mail.  If you send enough, you may wind up
running Fight-O-Net!

3.3  Echomail policy

Echomail, defined as mail with lots of Echos (Dupe Loops) and
lots of missing mail (Caused by dupe killers) is already
fascist and governed by non-democratically elected vengeful
moderators who don't follow their own rules.  It will be
ignored by this document, except as precedent for the actions
of The Boss.

3.3.1  Echomail renaming

Echomail shall be more accurately known as FlameMail.

3.4  Excessively Annoying Systems

Excessively Annoying Systems, those run by any member of the Good Old
Boys network, shall be dropped from the nodelist until such time as
hell freezes over.

3.5  Sense of proportion

A sense of proportion is unimportant in Fight-O-Net.

4.  Anthem

The official song of Fight-O-Net is below.  Sing to "America, the
Beautiful", or "The Star Spangled Banner", or "We ain't gonna take
FidoNews 10-14                 Page:  4                    05 Apr 1993

it" by Twisted Sister.

Democracy, democracy,
we pin our hopes on thee,
and someday soon,
we hope to have,
a grunt for Z1C

Spam, Spam, Spam, Spam,
Spam, Spam, Spam, Spam,
Spam, Spam, Spam, Spam,
Spam, Spam, Spam, Spam.

5.  Credits, acknowlegments, etc.

Fight-O and Fight-O-Net are trademarks of Fight-O software, Inc.
I'd also like to thank Nets 2605 and 2606, Richard Bash (for no
apparent reason), Pablo Kleinman, Tom Jennings, my mother, and
that cute redhead I had a crush on in 6th grade.

Next time in the Cynic's Sandbox:  Caller ID - For the man who has
nothing to hide...

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

Why Policy 4.1C deserves our serious attention

Why 4.1C deserves our serious attention

I read with great interest, two things in last week's edition (1013) of
Fidonews; the article about DRAFT008 and the little article by Glen
Johnson that preceded the full text of the 4.1C proposal.

I'm the 'anonymous' person that wrote the original comparison article a
few issues ago. I'm going to remain anonymous, and I'll tell you why.

I've seen what has transpired in the many SYSOP-type conferences over
the last three months with the policy debates. The group that developed
4.1C was the first on the scene, and they and their proposal were
immediately attacked by a number of people for doing so. It was VERY
clear to me, at least, that the reason many people assailed their
document was because of who the authors were, not what the document
said.

Probably the most ludicrous of all the things I saw were the many
utterly horrifying things said by one Bob Germer, who started calling
members of Net 163 names because of their support for democratic
reform in Fidonet. And this person developed a policy draft himself!

The reason I did my article anonymously, is because I don't want my
friends and members of the net I'm in to be categorized, or pre-judged
or labelled because of the things -I- say. I offered my honest
interperetation of both documents, and you all can take that for
what its worth.

FidoNews 10-14                 Page:  5                    05 Apr 1993

I called the other document BAKERPOL because it was distributed by
Christopher Baker, the RC of Region 16. I don't know if he wrote it
himself, nor do I care. But I called it what I did because I under-
stand that he was the person that released it. I don't know
Christopher Baker or the other guy, Ken Tuley, and it doesn't even
matter. I didn't judge the proposals by the names attached to them,
I judged them on their merits.

I never much cared about Fidonet policy, because I get my mail, and
that's all I ever really cared about. Sure, it bothered me a little
that it seemed to be an all-male, political, barb throwing contest
at times, but it really wasn't THAT big of an issue with me.

Then 4.1C came out, and I read it. And it changed my view of things.
Then I read the others that started coming out in rapid-fire
succession after it. And they reinforced my new view of things.

The 4.1C proposal isn't perfect. But it has something very significant
in it; democracy. I've heard the authors of it continually extolling
the virtues of what they call the 'one sysop, one vote' concept, and
I must say, that I think that's a WONDERFUL concept, and the 4.1C
proposal bears that out. I'm thrilled with the idea of letting
regular people vote for their coordinators.

Giving each sysop a vote brings us all back down to Earth; it puts
us all on the same level with one another. After all, people will
tend to support, and help, and cooperate, and work with coordinators
that are there because we WANT them there as opposed to being PUT
there, or elected by only select people (like NCs being the only
people 'allowed' to vote for an RC) . Everyone pitches in, everyone
has a say, and noone's vote is any 'stronger' than anyone elses. I
think its a LOVELY idea.

I like the 4.1C proposal over anything that has come out so far
because it treats Fidonet as a group of PEOPLE, each with their own
equal voice. And coordinators should find it equally appealing, as
it will give them the 'warm & fuzzy' feeling of knowing that there's
no QUESTION that they have the support of the people they're serving.

We've nothing to fear from this proposed policy, I think it'd be
good for us. The Regional Coordinators should allow a vote on it to
take place. It's only fair. And then if it passes a vote, we'll ALL
have an equal opportunity to participate in shaping Fidonet for the
future.

Give us a chance, please?
FidoNews 10-14                 Page:  6                    05 Apr 1993


Commodore Geos Echo Available

Commodore Geos Echo Available
by Steve Dressler

Even today there are still alot of 8 bit Commodore 64's and 128's out
in the market place.  Commodore has an operating system called GEOS.
GEOS is the Windows environment of the Commodore Business Machines.
I have started a GEOS Echo for all people interested in CBM in
hopes to gain enough traffic to justify backbone status.  The
echo is on the E-List, but with little success to date.  At the
present time, there are around 25 messages a week and growing.

People in Zone 3 may request a feed from 3:633/162.  Zone 1 may
request a feed at 1:154/92 or 1:170/202 or 1:170/610.  Each feed is
v.32bis, and mine (170/202) is a ZyXEL 19.2k.

Steve Dressler is the moderator and Steven Guthrie is the
co-moderator (VP of the Tulsa Area Commodore Users Group).
Discussions are about, but not limited to, Commodore Geos related
topics.  It is suprising how serious people take their GEOS in the
Commodore world.

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

Responce to Stanton McCandlish

Chris Farrar
1:246/20 - Windsor, Ontario, Canada
89:488/20

                       Caller ID Revisited

In Fidonews 10-13, Mr. McCandlish had some things to say, and I would
like to take the time here to refute them.  In keeping with the
statement from the Editor, any future responce on Caller ID will be
made in the PHONES echo, available from the Fidonet backbone, or via
netmail.  Netmail, whether or not it has the PVT bit set, can and may
be replied to and quoted publically in the PHONES echo.  Systems
running in the IMEX network, can find a similar conversation in the
IMEX.TELECOM echo, available from your echo feed on the IMEX (zone 89)
backbone.

>I  could  be  slammed harder.  I did NOT say that callers should
>not have to provide BBSs with correct address,  name  and  phone
>number.   The  last  few  criticisms of my letter have hinged on

True, you didn't say that, but how to you intend to discover if the
name, number, and address (if required) _is valid_?  I don't know
about his system, but every week I have at least a couple of twits who
like calling in, and trying to gain access to my system.  If they
aren't twits, then Ronald Reagan, William Clinton, and Al Gore all
decided to call my BBS, one after another, at 2 in the morning.  Why
don't I beleive that they are the caller's real names?  Then again,
FidoNews 10-14                 Page:  7                    05 Apr 1993

I used to have a user, James Bond, (a real person, I saw the birth
certificate), who is a real person.  With CLID, discovering there is a
real Bond, and a fake Reagan, Clinton, et al is a piece of cake.

>that there may be a problem. Again I did not  say  that  CID  is
>Satan incarnate, rather that some thought should be given to its
>use and that people should be patient and wait until policy  has
>been  updated and nodelist flags defined to account for CID-only
>systems. Is this so difficult to grasp?  As  for  long  distance

But you have yet to give a valid reason WHY people should wait for new
nodelist flags.  The technology is available today, why shouldn't it
be used?  The answer is simple, there is no reason why it shouldn't be
implemented.  Also, why do we need nodelist flags?  CLID can keep a
user from connecting with a BBS without stopping a mailer from
connecting for mail sessions, and how many users download the nodelist
each week for a BBS list anyway.

>callers:  why  verify  them?  What nut is going to call you long
>distance, at THEIR expense to lie to you  so  they  can  get  an
>extra  account  to  cheat  SRE  with, or whatever? It just isn't
>likely.

Sorry.  There are nuts that will call to upload their favorite trojan
and virii, lord knows I've found enough that LD callers have no
uploading abilities until after they have been validated.  There are
people who do get their kicks from uploading virii, and doing it LD
makes it harder to track them down.

>        And finally, the merits of Canadian vs US  law  is  real
>neat  and  all  but  totally  irrelevant.  READ the article, for

Hardly irrelevant.  Laws in countries are different, and you cannot
expect that views will be identical between different countries.
Living in a border city, I have seen enough people, on both sides of
the border, who don't realize that when they pass the line down the
middle of the Detroit River, that they are subject to different laws,
and regulations.  The number of Michigan motorists that get arrested
at sobriety roadblocks is proof of that, as they claim them to be
unconstitutional, and then want Detroit cops to come and get them, as
they don't consider Windsor police officers having any jurisdiction
over them.

>chrissakes.  And only last thing, I just want to  emphasize  yet
>AGAIN  that when I say CID harms privacy I am not refer- ring to
>sysops, but rather to less savoury folks.  By forcing caller ID,
>sysops  in  effect  demand  that  we  send caller ID info to ALL
>numbers.  When the telcos come up with all  call  blocking  that
>can  be  temporarily  disabled  with  a  keypad code to dial one
>number, then fine, CID your heart out.  Until  that  time  comes

Why should we wait to implement CLID for your convienence?  If you are
calling "less savoury folks", you have several options:

1) Install a data line, and call them off it, so if they do call
FidoNews 10-14                 Page:  8                    05 Apr 1993

   you back, they will never reach you.
2) Call from work
3) Call from a pay phone
4) Petition whatever group that regulates phones in your state to
   allow either disabling on a per call basis, or switch to allowing
   blocking on a per call basis, by dialing your equivelant of *69.

And, not everywhere has global blocking, such as there is where you
live.  Here in Ontario (Canada), the only style of blocking available
is the per call, dial a * code, and then make your call, the same way
you would go about temporarely disabling Call Waiting to make a data
call.

>you  are  doing  everyone  as  disservice by demanding Caller ID
>info.  Why not USE CID if it is given, and voice verify the rest
>without a hassle? Simple.

Why should the system operator have to take the time to do voice
verifications, when there are faster, easier, and more convienent ways
of validation.  Voice verification creates longer delays for validation
of callers, involves either calling directly, and running up the
sysop's phone bill, which is generally high enough already, or calling
collect, in which case the sysop's phone number appears on the user's
phone bill within a month, removing the sysop's right to privacy.  You
can then end up having to make several calls to voice verify, if the
person isn't in when you call, etc.

>PS:  the  idea  that  having  CID  blocking  would  make someone
>prosecutable for un- authorized access is a very silly fantasy.

I would suggest that you take a look at Section 342.1 of the Criminal
Code (Canada).  It specifically spells out what is considered the
offence, and the punnishment.  342.1(1) puts it simply and clearly,
and very easy to read and understand, as can be seen below:

342.1 (1) Every one who, fraudulently and without color of right,
 (a) obtains, directly or indirectly, any computer service,
 (b) by means of an electro-magnetic, acoustic, mechanical or other
 device, intercepts or causes to be intercepted, directly or
 indirectly, any function of a computer system, or
 (c) uses or causes to be used, directly or indirectly, a computer
 system with intent to commit an offence under paragraph (a) or (b),
 or an offence under section 430 in relation to data or a computer
 system
is guilty of an offence and liable to imprisonment for a term not
exceeding ten years, or is guilty of an offence punishable on summary
conviction.

(2) In this section,

"computer program" means data representing instructions or statements
that, when executed in a computer system, causes the computer system to
preform a function;

"computer service" includes data processing, and the storage or
FidoNews 10-14                 Page:  9                    05 Apr 1993

retrieval of data;

"computer system" means a device that, or a group of interconnected
or related devices one or more of which,
  (a) contains computer programs or other data, and
  (b) pursuant to computer programs,
     (i) preforms logic and control, and
     (ii) may preform any other function;

"data" means representations of information or of concepts that are
being prepared or have been prepared in a form suitable for use in a
computer system;

"electro-magnetic, acoustic, mechanical or other device" means any
device or apparatus that is used or is acapable of being used to
intercept any function of a computer system, but does not include a
hearing aid used to correct subnormal hearing of the user to not better
than normal hearing.

"function" includes logic, control, arithmetic, deletion, storage and
communication or telecommunication to, from or within a computer system;

"intercept" included listen to or record a function of a computer
system, or acquire the substance, meaning, or purport thereof.
R.S. 1985, c27

Section 430, as mentioned in the above, is in regards to mischief, and
mischief in relation to data, including destruction of data.

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

OS2 echos
From: Byron Miller                         (1:106/433)

Well, here is my first posting to fidonews, and i thought i would pass
on some interesting info to my fellow OS/2 SysOps

As you may have seen, OS/2 has been growing, and Very Rapidly. Many SysOps
Are slowly Converting there BBS over to OS/2, but i hear lots of complaints
about the limited supply of OS/2 speceific BBS software. Pete Norloff
has taken the stand has started the OS2BBS_DEV echo...

This echo is for the Discussion of OS/2 BBS programing and requests and
ideas that people would like to see in a BBS System. Many OS/2 programmers
are starting to find their way to the echo, and we are looking for some
more talented people to jump in..

The following Systems carry the echo, and would happily send it to you
upon request.

1:292/60       1:280/304
1:110/535      1:289/27
1:202/514      1:201/2104
1:273/714

FidoNews 10-14                 Page: 10                    05 Apr 1993

I Hope to see some great programmers jump in, and look forward to seeing
the Best BBS packages for OS/2 anytime soon..

And while were discussing OS/2... you might like to find out more info
so here are some of the Non-Backbone Echo's that Might be of Interest
to All.

OS2BEGIN    Beginners Questions And Answers
OS2BBS_DEV  Developing/Programming OS/2 specific BBS software/utils
OS2CDROM    Using CD-ROMS with OS/2
OS2COMM     Communications with OS/2 via networks such as TCP/IP
OS2DP       Development/Use of Databases under OS/2
OS2DOS      Using/Configuring programs to run under OS/2 DOS box
OS2GAMES    Running games under OS/2, great info to get Games to work right
OS2REXX     Programming and using REXX under OS/2
OS2VIDEO    Video Drivers, hardware, and configuring options
OS2WPS      Using the OS/2 "W"ork "P"lace "S"hell
OS2WP       Word Processing under OS/2
OS2_13      Using, Discussion about OS/2 1.3
TEAMOS2     Users sharing ideas on use of OS/2 and its promotion.

These echos are available on MANY OS/2 BBS's and should be requestable from
the nodes listed above.

Hope to see many of you in Fidonet in these echos!

Byron Miller
SysOp of North Shore BBS (OS/2 BBS of Course)
1:106/433

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

Policy Proposals: The Cart Before the Horse?
Jack Decker
Fidonet 1:154/8

Policy Proposals: The Cart Before the Horse?

I've been reading the articles on the proposed revisions to Policy 4,
and while I agree that there is a crying need to replace Policy 4, I
get the feeling that both proposals are an attempt to provide better
ways to put out flames without ever addressing the actual cause of the
fires.

I just want to make a couple of comments that I wish the authors of
these proposals would consider.  First and most important, please let
technology take care of technological problems.  Fidonet policy is
primarily a political document, telling us how we are supposed to
interact with each other.  The trouble is, it is so long that many
sysops never read the whole thing, and fewer remember enough of what
they read to really affect their day-to-day operations.  Fidonet isn't
a government, it's a hobby, so why try to make governmental type
regulations?

Suppose we could spend less time worrying about how people in Fidonet
FidoNews 10-14                 Page: 11                    05 Apr 1993

relate to each other?  We'd have fewer flames, our policy document
could be shorter and more concise, and everyone would lead a generally
happier life (one would hope so, anyway)!

What are the major causes of flames and disagreements in Fidonet?  No,
I don't mean the APPARENT cause, I mean the ROOT cause.  These are
often two entirely different things.  Many policies were invoked to
solve specific problems that may have been known only to a few.  These
root problems were responsible for the creation of perhaps a whole body
of policy (formal or informal) that may now be a problem in itself.

As an example, consider that the ever-expanding size of the Fidonet
nodelist has been responsible for a whole host of proposals, the net
effect of which would be to exclude some nodes from the nodelist.  Many
of the arguments over what status points should have could be more
easily resolved if points could somehow be included in the nodelist,
but at this point NO ONE wants to see the nodelist grow any larger.

Or consider the totally screwed up format of Fidonet echomail messages.
I have yet to hear from anyone who does not agree that the current
Fidonet message format leaves a lot to be desired (and is a
programmer's nightmare!), but what you may not realize is that the lack
of effective duplicate message control was in part responsible for some
of the ridiculous geographic restrictions found in Fidonet policy (at
least, that was the claim at the time the restrictions were added...
more on that later).

How do we deal with these problems?  Unfortunately, because few seem to
recognize the root cause of such problems, we attempt political fixes
that no one's really happy with (not even the so-called power mongers
after a while, because they become targets for all the flak).  I would
like to suggest that any new Policy document should give us some
mechanism for effecting TECHNICAL changes to Fidonet that could do far
more to help us solve our problems than any amount of words on paper
ever could.

Therefore, I'd like to make a couple of proposals for the next Policy
document:

First, give at least the IC, and hopefully others in Fidonet the right
to open discussion on technical matters in Fidonet, with the idea of
setting or revising Fidonet technical standards.  This should be at
least a semi-orderly process and should include specific time frames
for each part of the process.  Here's one possible outline of the
process:

1) Initial discussion phase:  Is it broke?  Do we need to fix it?  What
would we like to see in any new proposals?  (Example:  Do we need a new
nodelist format?  Should we stop issuing a nodelist covering all zones?
What are the problems with the present format?)

2) Request for proposals:  In this phase we ask interested groups or
individuals to submit FORMAL proposals for the new standard.  There
should be a deadline date for this!

FidoNews 10-14                 Page: 12                    05 Apr 1993

3) Discussion of proposals:  A time period where the proposals are made
available to any interested party.  Comments go back to the authors of
the proposals, who basically have the freedom to modify their proposals
based on user input.  Consolidation of similar proposals would be
encouraged.

4) Release of final draft of proposals:  After comments have been
received, the authors would release their final drafts of their
proposals.

5) Vote on the proposals:  At this point the proposals under
consideration would be voted on.  If no one proposal receives a clear
majority, a runoff vote may be necessary.  Again, a specific date
should be set for the vote, lest it be put off indefinitely (it's only
a hobby, so folks tend to procrastinate)!

6) Implementation of the proposals:  This should be far enough in the
future to allow software authors time to make any adjustments needed to
their software.

Again, the above is only a possible outline.  My point is that we need
SOME sort of mechanism like this, clearly defined in Policy.  The
current system (arguing the subject in the NET_DEV echo until everyone
is sick of it!) doesn't make it.  If the current system worked,
something would have been done about the nodelist problem years ago.
As it is, we are helpless to make needed technical changes because we
have no official mechanism in place to make those changes.  This is
something that REALLY needs to be included in the next Policy, in my
opinion.

I mentioned the Fidonet message format earlier.  Just about all the
technically-minded folks agree it's a nightmare, yet I think probably
thousands of person-hours of effort have gone into creating proposals
for a new message format.  Some were posted in NET_DEV, some were
published in Fidonews, but in the end they all suffered the same fate:
They were all eventually ignored!  Not because the proposals were all
bad, but because there's simply no process in place that allows them to
be formally considered by the net as a whole.

Now, I personally think we should just adopt the standard message
format used in the Internet (as described in Internet document RFC-1136
and similar documents), possibly with some Fidonet-specific extensions
(message header lines that start with "X-FTN-<keyword>:" for Fidonet
specific information).  This would make us far more compatible with the
Internet, and avoid all the pitfalls now associated with
echomail-to-newsgroup conversion (something that a growing number of
sysops seem to be interested in).  But in any case, something needs to
be done, because many of our flame wars can be traced to the message
format!

Why?!?, I hear you ask.  Well, consider that the insane geographic
restrictions found in Policy 4 were only added in that document... that
is to say, there were no such restrictions in Policy 3 and earlier
documents.  And the important thing to keep in mind is that the
justification for adding these restrictions was almost entirely based
FidoNews 10-14                 Page: 13                    05 Apr 1993

on on the existence of dupe loops in echomail.  Now, some of us may
believe that wasn't the REAL reason (in fact, one report that came to
me was that the restrictions were added at the request of ONE RC who
didn't like the idea that nodes could "opt out" of being in HIS region)
but it doesn't really matter; the point is that the (POLITICAL)
restrictions were justified due to the (TECHNICAL) problems of echomail
dupes!  As it turned out, the restrictions didn't fix the problem (in
fact, the greatest advances in duplicate message elimination have come
about because of improved software that catches and rejects dupes) but
we have to live with them.

And, of course, the geographic restrictions remove the option of
"voting with your feet" (in a figurative sense) if you can't get along
with the NC or RC above you.  I don't mean to sound provincial, but it
surprises me especially that North American sysops who would scream
bloody murder if told they could only shop at one particular
supermarket or eat at one particular restaurant (based solely on where
they live) will so easily accept the notion that they can participate
in their hobby via only one point of contact based on their geographic
location.

Many of the disputes we have in Fidonet could be resolved rather
painlessly (for all concerned) if folks who just plain don't like each
other weren't forced to interact with each other.  Consider all the
messages you've read were someone didn't get along with their NC or
RC... wouldn't it save us all a lot of anguish if that person could
simply find another net to join?  Yeah, I know that for some reason
that concept is considered heresy in Fidonet, but I don't understand
why.  The Internet, and many other nets work quite well without
imposing such stupid restrictions (although the Internet has what might
be considered an opposite problem... because folks there AREN'T
required to associate with each other, it sometimes happens that
someone who wants a feed can't get one locally, because none of the
local folks already connected to the Internet want to give a feed to
the new person.  I'm NOT saying we should go to that extreme... sysops
should be ALLOWED to join their local net, but not REQUIRED to).

So, along with some mechanism for getting technical changes implemented
in Fidonet, I'd like to see the removal of sections of Policy that
attempt to compensate for technical shortcomings with political
solutions.  The ridiculous geographic restrictions are a prime example,
but there are other such things buried in there.  Maybe we could even
shorten Policy enough so that folks would READ it!

Anyway, please give this some consideration, and please remember that
Fidonet Policy affects all sysops in all zones, and we should not
lightly add things to Policy just to resolve some specific local
conflict.  But above all, don't put the "cart before the horse" by just
adding new regulations without giving us some way to fix the underlying
technical problems.  Let's start finding technical solutions to those
problems!
FidoNews 10-14                 Page: 14                    05 Apr 1993


Rebuttal to an Anonymous Critic

A Non-Anonymous Reply on Policy Draft Differences
Ken Tuley, 1:374/98

Having openly asked for comments and suggestions in every
echomail and netmail contact in which I have discussed ideas for
future Policy, I was a little disappointed to see the level of
disinformation included in the article in FNEWSA12 by an
anonymous "analyst".  Hopefully, those who went on to read the
draft itself could see through the smoke and mirrors of selective
quoting and recombination of statements, but I feel compelled to
respond for the sake of clarity.  Also for clarity, I have taken
the liberty of replacing references to the draft with its name as
distributed [DRAFT008].

>                             [DRAFT008]                    4.1C
> NC,RC selection         not specific, each net       Democratic
>                         has its own method           elections
>                                                      one sysop
one
>                                                      vote. Term
is
>                         No term                      two years

These are specifically designated as being determined by local
policies developed by the SYSOPS of those nets/regions.

> (Policy 4.1C requires a 2/3 majority of the Zone Coordinators
to
> elect an Internation Coordinator. [DRAFT008] requires just a
> majority of the ZCs and give control of the election to the RCs
if
> the ZCs can't seem to come up with a winner.)

Given the difficulty 10 zone 1 RCs had deciding on a ZC, it
seemed reasonable to allow a fall-back selection process that
involved a larger voting pool.  The difference between "majority"
and "2/3" is a single person.

> Replacement of          By RC,ZC regardless       20% below can
call > NC,RC                   of sysops                 a sysop
election.
>                         wishes.                   to
replace,limited

The interesting distinction here is that 4.1c continues to make
the RC responsible for the NCs (and ZC for RCs), but provides no
authority to act.  DRAFT008 provides for the TEMPORARY
replacement of an RC or NC sho is not performing his duties only
until the local policy can be invoked to select a replacement.
The *C is obligated to support the wishes of the majority of
sysops in the affected net/region.

FidoNews 10-14                 Page: 15                    05 Apr 1993

> The Policy 4.1C proposal gives SYSOPS the authority to recall
or
> replace coordinators whom they  feel are not performing.

What about the *C above who is responsible for his actions??

> [DRAFT008] on the other hand, gives unlimited authority to the
RCs
> to replace an NC, and unlimited authority to the ZC to replace
an
> RC.

Not unlimited...  The RC may remove an NC for failure to perform
the duties listed in Fidonet Policy and HAVE THE NET MEMBERSHIP
SELECT A REPLACEMENT.  The same applies to the ZC for an RC.

Under [DRAFT008], all 2000 sysops in a Region could object to
the
removal of their RC, yet the ZC would still have the authority to
do
so.)

> Local policies

> The 4.1C proposal keeps a unified Fidonet under one basic set
of
> guidelines. It also provides for the implementation of local
> policies provided that they are not more RESTRICTIVE than 4.1C
> itself.

This is essentially the same in both drafts, except that DRAFT008
gives an example of one thing that might "ordinarily" be in a
local policy.

> [DRAFT008] allows for local definition of what should be
net-wide.
> Like what "excessively annoying" is.)

Wrong!  DRAFT008 refers to "Fidonet Policy" for the definition of
excessively annoying.  It simply requires that applicants for
node numbers familiarize themselves with applicable local
policies as well.

> Points                Access can be refused          no change
from
>                                                      existing

Since any sysop may refuse access to any user, neither of these
is a change from existing policy.  DRAFT008 simply reinforces the
fact than running a mailer as a point does not automatically
grant you access to all systems.

> Excommunications       Notice to next level           no change
from
>                        required                       existing
FidoNews 10-14                 Page: 16                    05 Apr 1993


No argument here.  I would expect most excommunications to be
appealed, so I believe it reasonable to notify the *C above if
you have done so.  It just prevents surprises.

> Policy Ratification    Can be selectively          Whole
document
>                        changed by section.         must be
presented

> (Fidonet has always adopted entire policy documents, not
amendments
> by section. The reasons why are even stated in current policy.

The reason stated is "to simplify the process".  I think the
sysops of Fidonet are capable of dealing with sectional
amendments, and allowing them helps to focus attention on the
specific changes offered.  Besides, "always" is a misdirected
term, since provisions for adoption of new policies didn't even
exist prior to the current policy.

> (A significant change in 4.1C over current policy is that it
moves
> the level of approval of policy referendums DOWN a notch to the
NC
> level. [DRAFT008] still gives complete control over policy
> referendums to the RCs)

I have already stated in public discussions that I would support
addition of a threshold for NCs to trigger a referendum, but the
4.1c proposal of 5% is absurd (that's 29 NCs at the present
time).  There are more nets than that in the state of Florida
alone!  Something like 50% of the RCs 'or' 20% of the NCs would
be more reasonable (IMO).

> How local policy comes into existence is not specified in
> [DRAFT008], yet the *C structure is required to abide by it
when
> judging "excessively annoying".

I don't know where this came from.  The *C structure is required
to abide by local policies in recognizing the *C selected under
it, but the section on resolution of disputes that talks about
excessively annoying behavior makes no reference to local
policies.

> [DRAFT008] introduces more uncertainty into Fidonet as there
can be
> as many "policies" on a local level as there are
nets+regions+zones
> and they may CONFLICT with each other.
Granted, but they may not conflict with any policy above them.
This is already the case.  Some nets have policies on cost
recovery, outbound netmail routing, hub responsibilities and
other procedures that vary from one net to another.  I don't see
FidoNews 10-14                 Page: 17                    05 Apr 1993

this as a problem.

The biggest difference between DRAFT008 and 4.1c is in where the
responsibility lies to make the democratic process work.
DRAFT008 puts it in the hands of the local sysops through
encouragement of local policies consistent with Fidonet Policy.
4.1c puts it in the hands of the IC to develop some unknown
future procedure for accomplishing its goals.


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

FidoNet Policy Document Version 5
                         FidoNet Policy Document

Version 5
Draft 008
03/12/93

1  Overview

This document establishes the policy for sysops who are  members
of the FidoNet organization of electronic mail systems.  FidoNet
is defined by a NodeList  issued  weekly  by  the  International
Coordinator.

Separate  policy documents may be issued at the zone, region, or
net level to provide  additional  detail  on  local  procedures.
Ordinarily,  these lower- level policies may not contradict this
policy, but will add procedural information  specific  to  those
areas,  such as methods of coordinator selection.  However, with
the approval of the International Coordinator, local policy  can
be   used   to  implement  differences  required  due  to  local
conditions.  These  local  policies  may  not  place  additional
restrictions  on  membership in FidoNet beyond those included in
this document, other than enforcement of local mail periods.

1.0 Language

To facilitate the largest possible readership, all international
Fidonet  documents will be written in English.  Translation into
other languages is encouraged.

1.1 Introduction

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

FidoNet is not a common carrier or a value-added service network
and  is  a  public  network  only in as much as the independent,
constituent nodes may individually provide public access to  the
network through their systems.
FidoNews 10-14                 Page: 18                    05 Apr 1993


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
describes the procedures which have been developed to manage the
network.

1.2 Organization

FidoNet   systems   are   grouped   on   several   levels,   and
administration   is   decentralized   to   correspond  to  these
groupings.  This overview provides a summary of  the  structure;
specific  duties of the coordinator positions are given later in
the document.

1.2.1 Individual Systems and System Operators

The smallest subdivision of FidoNet is  the  individual  system,
corresponding  to  a  single  entry in the nodelist.  The system
operator (sysop) formulates a policy for running the  board  and
dealing  with  users  if  the  sysop  provides  access to others
through that node.  The sysop must mesh with  the  rest  of  the
FidoNet  system  to  send and receive mail, and the local policy
must be consistent with other levels of FidoNet.  BBS  operation
is not required to be a Fidonet sysop.

1.2.1.1 Users

The  sysop  is responsible for the actions of any user when they
affect the rest of FidoNet.  (If a user is annoying,  the  sysop
is  annoying.) Any traffic entering FidoNet via a given node, if
not from the sysop, is considered to be from a user and  is  the
responsibility of the sysop.  (See section 2.1.3.)

1.2.1.2 Points

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

In supporting points, the bossnode may make use of a private net
number which should not be  generally  visible  outside  of  the
bossnode-point  relationship.  Unfortunately,  should  the point
call  another  system  directly  (to  do  a  file  request,  for
example), the private network number will appear as the caller's
address.  In this way, points are different  from  users,  since
they  operate  FidoNet-compatible  mailers  which are capable of
contacting systems other than the bossnode.  Outside  the  local
FidoNews 10-14                 Page: 19                    05 Apr 1993

bossnode, a point may be refused access to other Fidonet systems
since points are considered users and sysops have  full  control
over users' access to their systems.

1.2.2 Networks and Network Coordinators

A  network  is a collection of nodes in a local geographic area,
usually defined by an  area  of  convenient  telephone  calling.
Networks coordinate their mail activity to decrease cost.

The  Network Coordinator is responsible for maintaining the list
of nodes for the network, and for  forwarding  netmail  sent  to
members  of  the  network from other FidoNet nodes.  The Network
Coordinator may make arrangements to  handle  outgoing  netmail,
but is not required to do so.

The  Network  Coordinator  is selected by the nodes of that net.
Nets  are  encouraged  to  formulate  policies   regarding   the
mechanism for accomplishing this.

1.2.2.1 Network Routing Hubs

Network  Routing  Hubs exist only in some networks.  They may be
appointed by the Network Coordinator, in order to assist in  the
management  of a large network.  The exact duties and procedures
are a matter for the Network Coordinator  and  local  policy  to
arrange,  and  will not be discussed here, except that a network
coordinator may not delegate responsibility to mediate disputes.

1.2.3 Regions and Regional Coordinators

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.

The Regional Coordinator maintains the list of independent nodes
in the region and accepts nodelist  segments  from  the  Network
Coordinators  in  the  region.  These  are  compiled to create a
regional nodelist, which is then sent to the  Zone  Coordinator.
A  Regional  Coordinator  does  not  perform  message-forwarding
services for any nodes in the region.  The Regional  Coordinator
may  participate  in  netmail  routing  between  the coordinator
levels, but is not required to do so.

Regional Coordinators are selected by the nodes of that  region.
Regions  are  encouraged  to  formulate  policies  regarding the
mechanism for accomplishing this.

1.2.4 Zones and Zone Coordinators

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

The  Zone Coordinator compiles the nodelist segments from all of
FidoNews 10-14                 Page: 20                    05 Apr 1993

the regions in the zone, and creates  the  master  nodelist  and
difference  file,  which is then distributed over FidoNet in the
zone.  A Zone Coordinator does  not  perform  message-forwarding
services  for  any  nodes in the zone.  The Zone Coordinator may
participate in netmail routing among the coordinator levels, but
is not required to do so.

Zone   Coordinators   are  selected  by  the  Net  and  Regional
Coordinators in that zone as representatives  of  the  nodes  to
whom they provide service (see section 8.3).

1.2.5 Zone Coordinator Council

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

1.2.6 International Coordinator

The  International  Coordinator coordinates the joint production
of the master nodelist by the Zone Coordinators.

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

The  International  Coordinator  is   selected   by   the   Zone
Coordinators.  See section 7.2.

1.2.7 Top-down Organization.  Checks and Balances.

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 top-down manner.  That is,  a
person at any given level is responsible to the level above, and
responsible for the level below.

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

If a person at any level  above  sysop  is  unable  to  properly
perform  their  duties,  the  coordinator  at the next level may
replace them.  For example, a Regional Coordinator who fails  to
FidoNews 10-14                 Page: 21                    05 Apr 1993

perform  may  be  replaced  by  the  Zone  Coordinator.  Interim
replacements will be appointed  until  such  time  as  a  formal
replacement   can  be  selected  under  the  local  or  regional
policies. Such appointments will  be  considered  final  in  the
absence of such policies.

To  provide  for  checks  and  balances  at the highest level of
FidoNet, there is an exception to  this  top-down  organization.
The  International Coordinator is selected by a majority vote of
the coordinators of the Zone  Coordinators  (see  section  7.2).
Similarly,  decisions  made by the International Coordinator can
be reversed by the Zone Coordinator Council. Decisions  made  by
other  coordinators are not subject to reversal by a vote of the
lower level, but instead  are  subject  to  the  appeal  process
described in section 9.5.

1.3 Definitions

1.3.1 FidoNews

FidoNews  is  a weekly newsletter distributed in electronic form
throughout the network.  It is  an  important  medium  by  which
FidoNet sysops communicate with each other.  FidoNews provides a
sense of being a community  of  people  with  common  interests.
Accordingly,  sysops  and  users are encouraged to contribute to
FidoNews.  Contributions are submitted to  the  node  listed  in
Fidonews and in the nodelist for that purpose; a file describing
the format to be used is available  from  that  and  many  other
systems.

1.3.2 Geography

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

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

There  are  cases  in  which  the  local  calling  areas lead to
situations where logic dictates that a node  physically  in  one
FidoNet  Region  should be assigned to another.  In those cases,
with  the  agreement  of  the  Regional  Coordinators  and  Zone
Coordinator involved, exemptions may be granted. Such exemptions
FidoNews 10-14                 Page: 22                    05 Apr 1993

are described in section 5.6.

1.3.3 Zone Mail Hour

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

1.3.4 Nodelist

The  nodelist  is  a  file  updated  weekly  which  contains the
addresses  of  all  recognized  FidoNet  nodes.   This  file  is
currently  made available by the Zone Coordinator not later than
Zone Mail Hour each Friday, and is available electronically  for
download  or  file  request at no charge.  To be included in the
nodelist, a system must meet the requirements  defined  by  this
document. No other requirements may be imposed.

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

1.3.5 Excessively Annoying Behavior

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

There is a distinction between excessively annoying behavior and
(simply) annoying behavior.  For example, there  is  a  learning
curve  that  each  new  sysop  must climb, both in the technical
issues of how to set up the software and the  social  issues  of
how  to  interact with FidoNet.  It is a rare sysop who, at some
point in this journey, does not manage to  annoy  others.   Only
when  such  behavior  persists,  after  being pointed out to the
sysop, does it becomes  excessively  annoying.   This  does  not
imply that it is not possible to be excessively annoying without
repetition (for example, deliberate falsification of mail  would
likely  be  excessively  annoying  on  the  very first try), but
simply  illustrates  that  a  certain  amount  of  tolerance  is
extended.

See section 9 for more information.

1.3.6 Commercial Use

FidoNews 10-14                 Page: 23                    05 Apr 1993

FidoNet  is  an  amateur  network.  Participants spend their own
time and money to make it work for the good of  all  the  users.
It  is  not  appropriate  for  a  commercial  enterprise to take
advantage of  these  volunteer  efforts  to  further  their  own
business  interests.   On  the  other  hand,  FidoNet provides a
convenient and  effective  means  for  companies  and  users  to
exchange information, to the mutual benefit of all.

Network  Coordinators  could  be  forced to subsidize commercial
operations by forwarding host-routed  netmail,  and  could  even
find  themselves  involved  in  a  lawsuit  if any guarantee was
suggested for mail delivery.  It  is  therefore  FidoNet  policy
that  commercial  mail  is  not  to be routed. "Commercial mail"
includes mail which furthers specific business interests without
being  of  benefit  to  the  net  as  a whole.  Examples include
company- internal mail, inter-corporate mail,  specific  product
inquiries   (price  quotes,  for  instance),  orders  and  their
follow-ups, and  all  other  subjects  specifically  related  to
business.

2 Sysop Procedures

2.1 General

2.1.1 The Basics

As  the sysop of an individual node, you can generally do as you
please, as long as you operate a mailer compatible with FTS-0001
specifications,   observe   mail  events,  are  not  excessively
annoying to other nodes  in  FidoNet,  and  do  not  promote  or
participate  in the distribution of pirated copyrighted software
or other illegal behavior via FidoNet.

2.1.2 Familiarity with Policy

In order to understand the meaning of "excessively annoying", it
is  incumbent  upon  all  sysops to occasionally re-read FidoNet
policy.  New sysops must familiarize themselves with this policy
and  any  applicable  local,  regional  or  zone policies before
requesting a node number.

2.1.3 Responsible for All Traffic Entering FidoNet Via the Node

The sysop listed in the nodelist entry is  responsible  for  all
traffic entering FidoNet via that system.  This includes (but is
not limited to) traffic entered by users, points, and any  other
networks  for  which  the  system  might act as a gateway.  If a
sysop allows "outside" messages to enter FidoNet via the system,
the  gateway  system  must be clearly identified by FidoNet node
number as the point of origin of that message, and it  must  act
as  a  gateway  in  the  reverse direction.  Should such traffic
result in a violation of Policy,  the  sysop  must  rectify  the
situation as soon as notified.

2.1.4 Encryption and Review of Mail
FidoNews 10-14                 Page: 24                    05 Apr 1993


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

2.1.5 No Alteration of Routed Mail

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

2.1.6 Private Netmail

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

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

2.1.6.1 No Disclosure of in-transit mail

Disclosing  or in any way using information contained in private
netmail traffic not addressed  to  you  or  written  by  you  is
considered  annoying  behavior,  unless  the  traffic  has  been
released by the author or the recipient or is a part of a formal
policy  complaint.   This does not apply to echomail which is by
definition a broadcast medium, and where private mail  is  often
used to keep a sysop-only area restricted.

2.1.6.2 Private mail addressed to you

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


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

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

2.1.7 Not Routing Mail

You are not required to route traffic if you have not agreed  to
do  so.   You  are not obligated to route traffic for all if you
route it for any, except as required of a Net Coordinator if you
hold   that  position.   Routing  traffic  through  a  node  not
obligated to perform routing without the permission of that node
may be annoying behavior.  This includes unsolicited echomail.

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

2.1.8 Exclusivity of Zone Mail Hour

Zone Mail Hour is the heart of FidoNet, as this is when  network
mail is passed between systems.  Any system which wishes to be a
part of FidoNet must be able to receive mail  during  this  time
using  the  protocol  defined  in  the current FidoNet Technical
Standards Committee publication (FTS-0001 at 2this writing).  It
is  permissible  to  have  greater  capability  (for example, to
support additional protocols or extended mail  hours),  but  the
minimum  requirement is FTS-0001 capability during this one hour
of the day.

This time is  exclusively  reserved  for  netmail.   Many  phone
systems  charge  on  a  per-call  basis, regardless of whether a
connect, no connect, or busy signal is  encountered.   For  this
reason,  any  activity other than normal network mail processing
that  ties  up  a  system  during  ZMH  is  considered  annoying
behavior.  Echomail  should not be transferred during ZMH.  User
(BBS) access  to  a  system  is  prohibited  during  ZMH.   File
requests should not be honored during ZMH.
FidoNews 10-14                 Page: 26                    05 Apr 1993


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

2.1.9 Private Nodes

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

Private  listings affect each member of FidoNet, since they take
up space in everyone's nodelist.  Private listings which are for
the  convenience  of  one  sysop  (at the expense of every other
sysop in FidoNet) are a luxury  which  is  no  longer  possible.
Non-essential  redundant listings (more than one listing for the
same telephone number, except as  mandated  by  FTSC  standards)
also  fall  into  this  category.   Sysops requesting private or
redundant listings must justify them with a statement explaining
how  they  benefit  the  local  net  or FidoNet as a whole.  The
Network Coordinator or  Regional  Coordinator  may  review  this
statement  at any time and listings which are not justified will
be removed.

2.1.10 Observing Mail Events

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

2.1.11 Use of Current Nodelist

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

2.1.12 Excommunication

A system which has been dropped from the network is said  to  be
excommunicated  (i.e.  denied  communication).  If you find that
you have been excommunicated without warning,  your  coordinator
was  unable  to  contact you. You should rectify the problem and
contact your coordinator.
FidoNews 10-14                 Page: 27                    05 Apr 1993


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

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

2.1.13 Timing of Zone Mail Hour

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

2.1.14 Non-observance of Daylight Savings Time

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

2.2 How to obtain a node number

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

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

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

Once you have located the network or region in your area, send a
message  containing  a request for a node number to node zero of
that network or region.  The request must be sent by netmail, as
this indicates that your system has FidoNet capability.

You  must  set up your software so that the from-address in your
message does not cause problems for the coordinator who receives
it.   If  you  pick the address of an existing system, this will
cause obvious problems.  If your software is  capable  of  using
address -1/-1, this is the traditional address used by potential
sysops.  Otherwise use net/9999 (e.g. if you are applying to net
123,  set  your system up as 123/9999).  Many nets have specific
FidoNews 10-14                 Page: 28                    05 Apr 1993

instructions available to potential sysops and these  procedures
may indicate a preference for the from-address.

The  message  you  send  must  include  at  least  the following
information:

    1) Your name.
    2) The phone number to be used when calling your system.
    3) The name of your system.
    4) The city and state where your system is located.
    5) Your voice phone number.
    6) Your hours of netmail operation.
    7) The maximum baud rate you can support.
    8) The type of mailer software and modem you are using.

Your coordinator may contact  you  for  additional  information.
All information submitted will be kept confidential and will not
be  supplied  to  anyone  except  the  person  who  assumes  the
coordinator   position   at   the  resignation  of  the  current
coordinator.

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

Please  allow at least two weeks for a node number request to be
processed. If you send your request to a  Regional  Coordinator,
it may forwarded to the appropriate Network Coordinator.

2.3 If You are Going Down

If  your  node  will be down for an extended period (more than a
day or two), inform your coordinator as soon as possible.  It is
not  your  coordinator's  responsibility to chase you down for a
status report, and if your system stops accepting mail  it  will
be removed from the nodelist.

Never put an answering machine or any other device which answers
the phone on your phone line while you are  down.   If  you  do,
calling systems will get the machine repeatedly, producing large
phone bills, which is very annoying.  In short, the  only  thing
which  should  ever answer the telephone during periods when the
nodelist  indicates  that  your  node  will   accept   mail   is
FidoNet-compatible software which accepts mail.

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

2.4 How to Form a Network

If there are several nodes in your area, but no network,  a  new
network  can  be formed.  This has advantages to both you and to
FidoNews 10-14                 Page: 29                    05 Apr 1993

the rest of FidoNet. You receive better availability of nodelist
difference  files  and  FidoNews,  and  everyone  else  can take
advantage of host-routing netmail to the new network.

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

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

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

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

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

3 General Procedures for All Coordinators

3.1 Make Available Difference Files and FidoNews

Each  Coordinator  is  responsible  for  obtaining  and   making
available,  on  a  weekly  basis,  nodelist difference files and
FidoNews.

3.2 Processing Nodelist Changes and Passing Them Upstream

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

3.3 Ensure the Latest Policy is Available

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

FidoNews 10-14                 Page: 30                    05 Apr 1993

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

3.4 Minimize the Number of Hats Worn

Coordinators  are  encouraged  to  limit  the  number of FidoNet
functions they perform.  A coordinator who holds  two  different
positions  compromises  the appeal process.  For example, if the
Network Coordinator is also the Regional Coordinator, sysops  in
that network are denied one level of appeal.

Coordinators   are  discouraged  from  acting  as  echomail  and
software- distribution hubs.  If they do so, they should  handle
echomail  (or  other volume distribution) on a system other than
the administrative system.  A  coordinator's  system  should  be
readily available to the levels immediately above and below.

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

3.5 Be a Member of the Area Administered

A  coordinator  must  be a member of the area administered. That
is, a Network Coordinator must be a member of  that  network  by
virtue  of  geography.   A Regional Coordinator must be either a
member of a network in the  region  or  an  independent  in  the
region.  A Zone Coordinator must be either a member of a network
in the  zone  or  a  regional  independent  in  the  zone.   The
International Coordinator must be a Fidonet sysop.

3.6 Encourage New Sysops to Enter FidoNet

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

3.7 Tradition and Precedent

A coordinator is not bound by the practices  of  predecessor  or
peers  beyond  the  scope  of this document and other applicable
net, region or zone policies.

In addition, a new coordinator  has  the  right  to  review  any
decision  made  by  predecessors for compliance with Policy, and
take whatever actions may be necessary to rectify any situations
not in compliance.
FidoNews 10-14                 Page: 31                    05 Apr 1993


3.8 Technical Management

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

3.9 Review and Acceptance of Lower Policies

Individual regions and nets are encouraged to formulate policies
to deal with local  issues  not  specifically  covered  in  this
document.   It  is  the responsibility of coordinators to review
policies submitted from lower levels for compliance with  higher
policies,  and  to  support  those policies whenever possible in
deciding matters related to those areas.

In  the  absence  of  procedures  determined  by  local/regional
policies,  the  coordinator  should attempt to act in accordance
with the interests and wishes of the majority of  nodes  in  the
affected area.

4 Network Coordinator Procedures

4.1 Responsibilities

A Network Coordinator has the following responsibilities:

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

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

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

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

5) To  make  available  to  nodes  in  the  network  information
regarding Fidonet elections and referenda, to solicit input from
those nodes and to act as a representative  of  those  nodes  in
such elections when appropriate.

4.2 Routing Inbound Mail

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

If a node in your network is receiving large volumes of mail you
can request that the sysop contact the systems which are sending
this mail and request that  they  not  host-route  it.   If  the
FidoNews 10-14                 Page: 32                    05 Apr 1993

problem  persists,  you can request your Regional Coordinator to
assign the node a number as an independent and drop  the  system
from your network.

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

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

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

4.3 Assigning Node Numbers

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

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

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

You should use network mail to inform a new sysop  of  the  node
number,  as  this  helps to insure that the system is capable of
receiving network mail.

If a node in your network is acting in a  sufficiently  annoying
manner,  you  can  take  whatever  action  you deem appropriate,
according to the circumstances of  the  case  and  due  process.
Notification  must  be given to the Regional Coordinator if that
action taken is excommunication of a node.

4.4 Maintaining the Nodelist

You should implement name changes, phone number changes, and  so
forth  in your segment of the nodelist as soon as possible after
FidoNews 10-14                 Page: 33                    05 Apr 1993

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

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

4.5 Making Available Policies, Nodelists and FidoNews

As a Network Coordinator  you  should  obtain  a  new  issue  of
FidoNews and a new nodelist difference file every week from your
Regional Coordinator. The nodelist difference file is  currently
made  available  each  Friday,  and  FidoNews  is published each
Monday.  You must make these files available to all nodes in the
network,  and  you  are encouraged to make them available to the
general public for download.

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

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

5 Regional Coordinator Procedures

5.1 Responsibilities

A Regional Coordinator has the following responsibilities:

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

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

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

FidoNews 10-14                 Page: 34                    05 Apr 1993

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

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

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

7)  To  make available to Net Coordinators and independent nodes
in  the  region  information  regarding  Fidonet  elections  and
referenda,  to  solicit  input from the independent nodes and to
act as a representative of those nodes in  such  elections  when
appropriate.

5.2 Assigning Node Numbers

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

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

You should use network mail to inform a new sysop  of  the  node
number,  as  this  helps to insure that the system is capable of
receiving network mail.

If a node in your region is acting in  a  sufficiently  annoying
manner,  you  can  take  whatever  action  you deem appropriate,
according to the circumstances of  the  case  and  due  process.
Notification must be given to the Zone Coordinator if the action
taken is the excommunication of a node.

If you receive a node number request from outside  your  region,
you   must  forward  it  to  the  Regional  Coordinator  of  the
applicant's region.  If you receive a node number request from a
new node that is in an area covered by an existing network, then
you must forward the request to the Coordinator of that  network
instead of assigning a number yourself.

If  a  network  forms  in an area for which you have independent
nodes, those nodes will be transferred to the local  network  as
soon  as is practical, unless those independent node assignments
were made for reasons of high volume or commercial traffic.

5.3 Encouraging the Formation and Growth of Networks

FidoNews 10-14                 Page: 35                    05 Apr 1993

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

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

If  several independent nodes in your region are in a local area
you should encourage them to form a network,  and  if  necessary
you may require them to form a network.  See section 2.4.

5.4 Assigning Network Numbers

It  is  your  responsibility  to  assign  network numbers to new
networks forming within your region.  You are assigned a pool of
network   numbers   to   use  for  this  purpose  by  your  Zone
Coordinator.   As  a  part  of  this   function,   it   is   the
responsibility   of  the  Regional  Coordinator  to  define  the
boundaries of the networks in the region.

5.5 Maintaining the Nodelist

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

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

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

5.6 Geographic Exemptions

There  are  cases  where local calling geography does not follow
FidoNet regions.  In exceptional  cases,  exemptions  to  normal
geographic   guidelines   are   agreed   upon  by  the  Regional
Coordinators and Zone Coordinator involved. Such an exemption is
FidoNews 10-14                 Page: 36                    05 Apr 1993

not  a right, and is not permanent.  When a network is formed in
the proper region that would provide local calling access to the
exempted  node,  it  is  no  longer exempt.  An exemption may be
reviewed and revoked at any time  by  any  of  the  coordinators
involved.

5.7 Overseeing Network Operations

It is your responsibility as Regional Coordinator to ensure that
the networks within your region are operating in  an  acceptable
manner.   This  does  not  mean that you are required to operate
those networks;  that  is  the  responsibility  of  the  Network
Coordinators.   It  means  that you are responsible for assuring
that the Network Coordinators  within  your  region  are  acting
responsibly.

If you find that a Network Coordinator within your region is not
properly performing the duties outlined in Section 4, you should
take   whatever   action  you  deem  necessary  to  correct  the
situation, up to and including removing the Net Coordinator from
that position and having the net membership select a replacement.

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

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

5.8 Making Available Nodelists, Policies, and FidoNews

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

It is your responsibility to make these available to all Network
Coordinators  and independent nodes in your region as soon as is
practical after you receive them.  The method of distribution is
left  to  your discretion.  You are encouraged to make all these
documents available for downloading by the general public.

6 Zone Coordinator Procedures

6.1 General

FidoNews 10-14                 Page: 37                    05 Apr 1993

A  Zone  Coordinator  for  FidoNet  has  the  primary  task   of
maintaining the nodelist for the Zone, sharing it with the other
Zone Coordinators, and ensuring the distribution of  the  master
nodelist  (or  difference file) to the Regions in the Zone.  The
Zone  Coordinator  is  also  responsible  for  coordinating  the
distribution  of  Fidonet  Policy  documents and FidoNews to the
Regional Coordinators in the zone.

The Zone Coordinator is responsible for the maintenance  of  the
nodelist  for  the  administrative  region.   The Administrative
Region has the same number as the zone, and  consists  of  nodes
assigned  for administrative purposes not related to the sending
and receiving of normal network mail.

A Zone Coordinator is charged with  the  task  of  ensuring  the
smooth operation of the Zone.

If  a Zone Coordinator determines that a Regional Coordinator is
not properly  performing  the  duties  outlined  in  section  5,
whatever  action  deemed  necessary  may  be  taken,  up  to and
including removing the Regional Coordinator from  that  position
and having the nodes of the region select a replacement.

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

The Zone Coordinator is responsible  for  creating  new  regions
within  the  zone  when  regions  become too large for efficient
coordination by a single Regional Coordinator.

The Zone Coordinator is responsible for reviewing and  approving
any geographic exemptions as described in section 5.6.

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

The  Zone  Coordinators are responsible for the selection of the
International Coordinator.

6.2 Selection

The Zone Coordinator is selected by a majority vote of  the  Net
and   Regional   Coordinators   within   the   zone,  voting  as
representatives of their nodes (see section 8.3).

7 International Coordinator Procedures

7.1 General

The  International  Coordinator  has   the   primary   task   of
coordinating the creation of the master nodelist by managing the
distribution between the  Zones  of  the  Zone  nodelists.   The
International  Coordinator  is responsible for definition of new
zones and for negotiation of agreements for  communication  with
FidoNews 10-14                 Page: 38                    05 Apr 1993

other  networks.   ("Other  network" in this context means other
networks with which FidoNet communicates  as  peer-to-peer,  not
"network" in the sense of the FidoNet organizational level.)

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

The  International  Coordinator  is responsible for coordinating
the  activities  of   the   Zone   Coordinator   Council.    The
International  Coordinator  acts  as  the spokesman for the Zone
Coordinator Council.

In  cases  not  specifically  covered  by  this  document,   the
International  Coordinator may issue specific interpretations or
extensions to this policy.  The  Zone  Coordinator  Council  may
reverse  such  rulings by a majority vote.  These extensions are
valid until such time as a policy  referendum  may  be  held  to
ratify or reject such extensions.

7.2 Selection

The  International  Coordinator  is  selected (or removed) by an
absolute majority vote of the Zone Coordinators with input  from
the   Regional   Coordinators.   In  the  event  that  the  Zone
Coordinators are unable to select an  International  Coordinator
by  absolute  majority,  the  International  Coordinator will be
selected by a majority of the Regional Coordinators.

8 Referenda

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

8.1 Initiation

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

8.2 Announcement and Results Notification

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

If  it  is  adopted,  the  International  Coordinator  sets  the
FidoNews 10-14                 Page: 39                    05 Apr 1993

effective date for a new  policy  through  announcement  in  the
weekly  nodelist  difference  file  and Fidonews.  The effective
date will be  not  more  than  one  month  after  the  close  of
balloting.

8.3 Eligibility to Vote

Each  member  of  the FidoNet coordinator structure at and above
Network Coordinator is entitled to one vote.  In the case of the
position changing hands during the balloting process, either the
incumbent or the new coordinator may vote, but not both.   If  a
person  holds  more  than  one  coordinator position, they still
receive only one vote.

Network Coordinators are expected to assess the opinions of  the
members  of  their  network,  and to vote accordingly.  A formal
election is not necessary,  but  the  Network  Coordinator  must
inform  the  net  of  the issues and solicit input.  The Network
Coordinator functions as the representative of the rank and file
members  of  FidoNet.   Regional  Coordinators will fulfill this
responsibility with regard to independent nodes in their regions.

8.4 Voting Mechanism

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

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

8.5 Voting on a whole Policy Document or Amendments

Policy may be changed as a  whole  document  or  by  section  as
required.  Sections  changed  must  include all cross-references
affected and the corresponding changes to those sections.

Policy changes voted on as whole documents and approved will  be
incremented  to  the next whole number from the previous version
number.  Sectional changes (including multiple sectional changes
approved  in  the  same  referendum)  will  increment the policy
number to the next tenth of the  current  version  number  until
nine  tenths is reached.  Sectional changes that would go beyond
nine tenths will increment to the next  whole  number  from  the
previous version number.

8.6 Decision of vote

A  Policy amendment is considered in force if, at the end of the
balloting period, it has received a majority of the votes  cast.
For  example,  if  there  were 350 eligible voters, 100 of which
cast a vote,  then  at  least  51  affirmative  votes  would  be
FidoNews 10-14                 Page: 40                    05 Apr 1993

required to declare the amendment in force.

In  the  case of multiple policy changes which are considered on
the same ballot, a version must receive more  than  50%  of  the
votes cast to be considered ratified.

8.7 Impeachment of a Zone Coordinator

8.7.1 Initiation

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

8.7.2 Procedure as in Policy Referendum

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

The definition of  "majority"  in  section  8.6  applies.   Only
coordinators in the affected zone vote.

8.7.3 Voting Mechanism

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

8.7.4 Limited to once per year

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

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

9 Resolution of Disputes

9.1 General

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

1) Thou shalt not excessively annoy others.
FidoNews 10-14                 Page: 41                    05 Apr 1993


2) Thou shalt not be too easily annoyed.

In other words, there are no hard and fast rules of conduct, but
reasonably polite behavior is expected.  Also,  in  any  dispute
both  sides  are  examined,  and  action  could be taken against
either or both parties. ("Judge not, lest ye be  judged!").   It
must  be  noted that it is someone's "behavior" (action) that is
subject to this policy.  The content  of  a  person's  words  or
opinions is not necessarily sufficient to be considered annoying
in this context.

Actions that would be considered excessively  annoying  behavior
include  activities that willfully disrupt the operations of one
or more Fidonet systems; using non-existent  or  falsified  node
numbers with the intent of disguising the origin of mail traffic
or of intercepting mail intended for the rightful owner of  that
node number; willfully compromising the integrity of an echomail
conference after having direct links to that conference  severed
by the conference moderator; or illegal activities that involve,
pertain to or utilize Fidonet as part of those activities.

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

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

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

9.2 Problems with Another Sysop

If you are having problems with another sysop, you should  first
try to work it out directly with the other sysop.

If  this  fails  to  resolve the problem, you should complain to
other sysop's Network Coordinator.  If that sysop is  not  in  a
network,  then complain to the appropriate Regional Coordinator.
Should this fail to provide satisfaction, you have the right  to
follow the appeal process described in section 9.5.

9.3 Problems with your Network Coordinator

If  you  are  having  problems with your Network Coordinator and
feel that you are not being treated properly, you  are  entitled
FidoNews 10-14                 Page: 42                    05 Apr 1993

to  a review of your situation.  As with all disputes, the first
step is to  communicate  directly  to  attempt  to  resolve  the
problem.

The  next step is to contact your Regional Coordinator.  If your
case has merit, there are several possible  courses  of  action,
including   a   change  of  Network  Coordinators  or  even  the
disbanding of your network.  If you have been excommunicated  by
your  Network  Coordinator,  that  judgement may be reversed, at
which point you will be reinstated into your net.

If you fail to obtain relief from your Regional Coordinator, you
have the right to follow the appeal process described in section
9.5.

9.4 Problems with Other Coordinators

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

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

9.5 Appeal Process

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

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

The appeal structure is as follows:

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

Regional   Coordinator   decisions   may   be  appealed  to  the
FidoNews 10-14                 Page: 43                    05 Apr 1993

appropriate  Zone  Coordinator.   At  this   point,   the   Zone
Coordinator  will  make  a  decision  and  communicate it to all
affected parties.

Zone Coordinator decisions may be appealed to the  International
Coordinator.  The International Coordinator will make a decision
and communicate it to all affected parties.   Decisions  of  the
International  Coordinator  may be reversed by a majority of the
Zone Coordinators.

If your problem is with a Zone Coordinator per se,  that  is,  a
Zone  Coordinator  has committed a Policy violation against you,
your  complaint  should  be   filed   with   the   International
Coordinator,  who will make a decision and submit it to the Zone
Coordinator Council for possible reversal, as described above.

A sample process is described in Appendix 3.

9.6 Statute of Limitations

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

9.7 Right to a Speedy Decision

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

9.8 Return to Original Network

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

9.9 Echomail

Echomail is one of many uses of Fidonet.  Echomail is treated as
a  use of Fidonet structure and is covered by Policy only to the
extent that this use affects primary Fidonet operations.  By its
nature,  echomail  places unique technical and social demands on
the net over and above those covered by this Policy.  It  should
be  noted  that  echomail  distribution  is a separate voluntary
arrangement between consenting nodes and is distinctly different
from  the  routing  of  netmail.   In  recognition  of  this, an
echomail policy which extends (and does not contradict)  general
Policy, maintained by the Echomail Coordinators, and ratified by
a process similar to that of this document, is recognized by the
FidoNet Coordinators as a valid structure for dispute resolution
on matters pertaining to echomail.

9.10 Case Histories
FidoNews 10-14                 Page: 44                    05 Apr 1993


Some of FidoNet Policy is interpretive in nature.   No  one  can
see  what is to come in our rapidly changing environment.  While
the history of previous complaints and decisions may  be  useful
as  guidance, each case must be decided on its own merits in the
time and circumstances under which it occurs.

10. Credits, acknowledgments, etc.

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

Appendix --------

The Appendices of this document are  exceptions  to  the  normal
ratification  process and are included for information purposes.
Appendix 1 may be changed by the appropriate  Zone  Coordinator,
and  other  sections  may  be  added or changed as needed by the
International Coordinator.

Appendix 1: Timing of Zone Mail Hour

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

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

    Eastern Standard Time (GMT -5)         4:00 AM to 5:00 AM
    Central Standard Time (GMT -6)         3:00 AM to 4:00 AM
    Mountain Standard Time (GMT -7)        2:00 AM to 3:00 AM
    Pacific Standard Time (GMT -8)         1:00 AM to 2:00 AM
    Hawaii Standard Time (GMT -10)        11:00 PM to Midnight

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

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

    GMT +12 Zone                        6:00 AM to 7:00 AM
         (New Zealand)
    GMT +10 Zone                        4:00 AM to 5:00 AM
         (East Australia, Papua New Guinea, Micronesia)
    GMT +9.5 Zone                       3:30 AM to 4:30 AM
         (Central Australia)
    GMT +8 Zone                         2:00 AM to 3:00 AM
         (Western Australia)

In Fidonet Zone 4, Zone Mail Hour is observed from 0800 to 0900 UTC.

FidoNews 10-14                 Page: 45                    05 Apr 1993

    GMT -3 Zone                         5:00 AM to 6:00 AM
    GMT -4 Zone                         4:00 AM to 5:00 AM
    GMT -5 Zone                         3:00 AM to 4:00 AM

In Fidonet Zone 5, Zone Mail Hour is observed from 0100 to 0200 UTC.

    GMT +0 Zone                         1:00 AM to 2:00 AM
    GMT +1 Zone                         2:00 AM to 3:00 AM
    GMT +2 Zone                         3:00 AM to 4:00 AM
    GMT +3 Zone                         4:00 AM to 5:00 AM

In Fidonet Zone 6, Zone Mail Hour is observed from 2000 to 2100 UTC.  In
each of the time zones involved this is:

    GMT +9 Zone                         5:00 AM to 6:00 AM
         (Japan, Korea, Eastern Indonesia)
    GMT +8 Zone                         4:00 AM to 5:00 AM
         (Hong Kong, Taiwan, Central Indonesia, Philippines)
    GMT +7 Zone                         3:00 AM to 4:00 AM
         (Malaysia, Singapore, Thailand, Western Indonesia)

Appendix 2:    Sample Election Procedure

1. Qualifications and Terms

The  Coordinator  serves  a  term  of one year and may serve any
number  of  consecutive  terms.   Any  sysop   listed   in   the
appropriate   segment  of  the  Fidonet  Nodelist  at  the  time
nominations are opened is eligible to run.   A  simple  majority
(50%  +  1) of votes cast is required to elect a Coordinator. In
the event that no candidate received a majority of votes, a  run
off  election  will  be held between the two candidates with the
greatest number of votes.

2. Nominations

Nominations may be made  either  in  a  designated  echo  or  by
netmail  to  the  election coordinator.  Any netmail nominations
received by the election coordinator will be  cross-posted  into
the  designated  echo.   Any  sysop  listed  in  the appropriate
segment of the Fidonet nodelist may nominate any other  eligible
sysop for the position of Coordinator.

Nominees  must  announce  their  consent to serve in order to be
considered candidates in the election, and are encouraged to  be
available for discussion during the election process.

A  minimum  of  two  weeks  will  be allotted for the nominating
process.

3. Election Coordinator

At  the  start  of  the  election   process,   the   appropriate
Coordinator  will  appoint  a  non-candidate  sysop  as Election
Coordinator. This sysop will have several responsibilities:
FidoNews 10-14                 Page: 46                    05 Apr 1993


Collecting nominations, seconds and  statements  of  consent  to
serve  from  netmail  and the designated echo and finalizing the
election slate.

Posting  the  slate  of  candidates  and   the   voting   format
instructions in the designated echo at the close of nominations.

Submitting  the  slate  of  candidates  and  the  voting  format
instructions to the Coordinator for distribution via netmail  to
all Net and/or Regional Coordinators.

Collecting and tabulating votes submitted.

Notifying  the  Coordinator  of the election results and posting
the election results in the designated echo.

4. Discussion Period

Following the close of nominations and presentation of the slate
of  candidates,  a  minimum  of  two  weeks will be allotted for
discussion before voting begins.

5. Voting Procedures

Net Coordinators in  each  net  will  distribute  the  slate  of
candidates,  voting  instructions  and  voting  schedule  to all
members of their nets via netmail.

Votes must be cast  by  the  node  sysops  via  netmail  to  the
Election  Coordinator.   Due  to  changing technology, the exact
format and mechanism of placing these votes will  be  determined
by  the Election Coordinator at the time of each election.  Once
a vote has been received and validated, it may not be changed.

The Election Coordinator will announce the final  counts  within
seven days of the close of voting.

Challenges  to  the  accuracy  or  completeness of the announced
results must be placed via netmail to the  Election  Coordinator
within  seven  days  of  the  announcement  of  the  results.  A
successful challenge will  necessitate  a  new  election  to  be
initiated.

6. Installation of New Coordinator

The  newly elected Coordinator will be installed in the nodelist
as soon as the transfer of control  files  and  other  necessary
information can be coordinated between the incoming and outgoing
Coordinators, but not later than two weeks from the announcement
of final election results.

Appendix   3:  Sample  Process  for  Resolution  and  Appeal  of
Complaints

FidoNews 10-14                 Page: 47                    05 Apr 1993

The process of complaint and appeal  available  to  all  Fidonet
members,  as  delineated  in sections 9.1 through 9.8, follows a
step by step procedure from the point at which a  complaint  has
been filed.

1. Offender does something to warrant removal from Fidonet.

2.  The Net Coordinator points out this activity to the offender
and offers the opportunity to refrain.

3. The Net Coordinator records the response of the offender.

4. If the offender desists, the case is over.  Otherwise;

5. The Net Coordinator issues a final warning  to  the  offender
stating  that  the  nodelist  entry  will be removed permanently
unless immediate cessation of the offense(s) follows this  final
warning.   Repeating  at  a  later  date  an offense for which a
warning was previously given may be considered refusal to comply.

6. If the offender desists, the case is over.  Otherwise;

7. The Net Coordinator notifies the offender of removal from the
nodelist.

8.   Net  Coordinator records offender's final response (if any)
and removes offender's node number from the nodelist if  no  new
information is received.

9.  Net  Coordinator  advises  Regional  Coordinator of complete
chronology with documentation and the case is closed, or;

10. The offender appeals to the Regional Coordinator and  offers
other  information contrary to the Net Coordinator's account and
requests intervention and/or investigation.

11. If the Regional Coordinator refuses the appeal, the case  is
over. Otherwise;

12.  The  Regional Coordinator agrees to consider the appeal and
advises the Net Coordinator  to  refrain  from  removal  pending
investigation of the appeal.

13.  The Regional Coordinator finds appeal has no merit, advises
Net Coordinator  to  proceed  with  node  removal,  and  advises
offender  of  finding  and  of  the option to appeal to the Zone
Coordinator, or;

14. The Regional Coordinator finds appeal has merit and  advises
Net Coordinator to retain the node's number and to appeal to the
Zone Coordinator if unsatisfied.

15. Steps 10 through 14 may be repeated at the Zone  Coordinator
and International Coordinator levels if necessary.

FidoNews 10-14                 Page: 48                    05 Apr 1993

Appendix 4: Fidonet Technical Standards

The   Fidonet   Technical   Standards   Committee  (FTSC)  is  a
deliberative  body  charged  with  developing  and   maintaining
technical  standards  for  operations  in  a  Fidonet Technology
Network (FTN).  All software used in Fidonet communications must
be in compliance with the appropriate standards, which include:

    FTS-0001  A basic Fidonet technical standard, R Bush
    FTS-0002  (superseded by FTS-0005)
    FTS-0003  (superseded by FTS-0006)
    FTS-0004  Echomail specifications, B Hartman
    FTS-0005  The distribution nodelist, B Baker, R Moore
    FTS-0006  YOOHOO and YOOHOO/2U2, V Periello
    FTS-0007  SEAlink protocol extension, P Becker
    FTS-0008  Bark file-request protocol extension, P Becker
    FTS-0009  Message identification and reply linkage, j nutt

Appendix 5:  File Name Conventions

For  those  systems  accepting  file requests via Fidonet, it is
generally accepted practice that certain  types  of  information
will  be  available  under  commonly  known  alias  names.   The
following are common file aliases:

    FILES     List of files available for file request
    ABOUT     Information about the individual system
    NODELIST  Current full Fidonet nodelist
    NODEDIFF  Current weekly Fidonet nodelist difference file
    FIDONEWS  Current weekly issue of Fidonews
    POLICY    Fidonet policy documents

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

========================================================================
                         Fidonews Information
========================================================================

------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ----------------

Editors: Sylvia Maxwell, Donald Tees, Tim Pozar
Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello,
                            Tom Jennings

IMPORTANT NOTE: The FidoNet address of the FidoNews BBS has been
changed!!! Please make a note of this.

"FidoNews" BBS
   FidoNet  1:1/23                     <---- NEW ADDRESS!!!!
   BBS  +1-519-570-4176,  300/1200/2400/14200/V.32bis/HST(DS)
Internet addresses:
   Don & Sylvia    (submission address)
             [email protected]

   Sylvia -- [email protected]
FidoNews 10-14                 Page: 49                    05 Apr 1993

   Donald -- [email protected]
   Tim    -- [email protected]

(Postal Service mailing address) (have extreme patience)
   FidoNews
   172 Duke St. E.
   Kitchener, Ontario
   Canada
   N2H 1A7

Published weekly by and for the members of the FidoNet international
amateur electronic mail system. It is a compilation of individual
articles contributed by their authors or their authorized agents. The
contribution of articles to this compilation does not diminish the
rights of the authors. Opinions expressed in these articles are those
of the authors and not necessarily those of FidoNews.

Authors retain copyright on individual works; otherwise FidoNews is
copyright 1993 Sylvia Maxwell. All rights reserved.  Duplication and/or
distribution permitted for noncommercial purposes only. For use in
other circumstances, please contact the original authors, or FidoNews
(we're easy).


OBTAINING COPIES: The-most-recent-issue-ONLY of FidoNews in electronic
form may be obtained from the FidoNews BBS via manual download or
Wazoo FileRequest, or from various sites in the FidoNet and Internet.
PRINTED COPIES may be obtained from Fido Software for $10.00US each
PostPaid First Class within North America, or $13.00US elsewhere,
mailed Air Mail. (US funds drawn upon a US bank only.)

BACK ISSUES: Available from FidoNet nodes 1:102/138, 1:216/21,
1:125/1212, (and probably others), via filerequest or download
(consult a recent nodelist for phone numbers).

A very nice index to the Tables of Contents to all FidoNews volumes
can be filerequested from 1:396/1 or 1:216/21. The name(s) to request
are FNEWSxTC.ZIP, where 'x' is the volume number; 1=1984, 2=1985...
through 8=1991.

INTERNET USERS: FidoNews is available via FTP from ftp.ieee.org, in
directory ~ftp/pub/fidonet/fidonews. If you have questions regarding
FidoNet, please direct them to [email protected], not the
FidoNews BBS. (Be kind and patient; David Deitch is generously
volunteering to handle FidoNet/Internet questions.)

SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews BBS, or Wazoo filerequestable
from 1:1/23 as file "ARTSPEC.DOC". Please read it.

"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, Box 77731, San Francisco CA 94107, USA and
are used with permission.

FidoNews 10-14                 Page: 50                    05 Apr 1993

   Asked what he thought of Western civilization,
   M.K. Gandhi said, "I think it would be an excellent idea".
-- END
----------------------------------------------------------------------


You are viewing proxied material from gopher.altexxanet.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.