2776 lines
123 KiB
Plaintext
2776 lines
123 KiB
Plaintext
|
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 -- max@exlibris.tdkcs.waterloo.on.ca |
|
|||
|
|
| Donald -- donald@exlibris.tdkcs.waterloo.on.ca |
|
|||
|
|
| Tim -- pozar@kumr.lns.com |
|
|||
|
|
| Both Don & Sylvia (submission address) |
|
|||
|
|
| editor@exlibris.tdkcs.waterloo.on.ca |
|
|||
|
|
+----------------------------------------------------------------------+
|
|||
|
|
| 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)
|
|||
|
|
editor@exlibris.tdkcs.waterloo.on.ca
|
|||
|
|
|
|||
|
|
Sylvia -- max@exlibris.tdkcs.waterloo.on.ca
|
|||
|
|
FidoNews 10-14 Page: 49 05 Apr 1993
|
|||
|
|
|
|||
|
|
Donald -- donald@exlibris.tdkcs.waterloo.on.ca
|
|||
|
|
Tim -- pozar@kumr.lns.com
|
|||
|
|
|
|||
|
|
(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 deitch@gisatl.fidonet.org, 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
|
|||
|
|
----------------------------------------------------------------------
|
|||
|
|
|