2680 lines
115 KiB
Plaintext
2680 lines
115 KiB
Plaintext
F I D O N E W S -- Vol.10 No.13 (29-Mar-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...................................................... 3
|
||
Memory Still Warm........................................... 3
|
||
Interested in CB Radio? Why not hook into the echo!......... 4
|
||
Magazine reviews: MONDO 2000, bOING bOING, WIRED............ 5
|
||
White House press releases direct to FidoNet!............... 8
|
||
Genetic Algorithm echo being started........................ 9
|
||
The Comics For Sale conference.............................. 9
|
||
Caller id again............................................. 10
|
||
Caller Id....Curse or Help?................................. 11
|
||
$50 or $100 reward offered.................................. 11
|
||
Nodelist Troubles........................................... 12
|
||
CorelDRAW! ECHO............................................. 13
|
||
An open letter to the people who waste bandwidth............ 14
|
||
More on the point nodelist.................................. 14
|
||
Rebuttal to an Anonymous Critic............................. 15
|
||
The TRULY democratic policy proposal revealed............... 18
|
||
3. Fidonews Information.......................................... 46
|
||
FidoNews 10-13 Page: 2 29 Mar 1993
|
||
|
||
|
||
========================================================================
|
||
Editorial
|
||
========================================================================
|
||
The week started with a mail bulge that amounted to 35
|
||
megabytes unarchived. Little did we know that it was all for
|
||
Fidonews. We have received about 175k of articles, and they have
|
||
come in in every form, from properly formated articles to notes
|
||
via internet.
|
||
|
||
That, in turn, is forcing us to take a close look at just
|
||
what kind of policy we should have regarding Fidonet articles.
|
||
(there have been a number of letters, as well, regarding
|
||
Fidonews policy). The short answer to "what is Fidonews policy?"
|
||
is simple. There is none, and there will not be.
|
||
|
||
Everything that arrives will be read, then we will decide
|
||
what to do. Generally, everything will be printed, BUT THAT IS
|
||
NOT A "RULE". A case in point is last week's "policy" article.
|
||
|
||
Frankly, we are feeling a bit suckered. Tom knew what was
|
||
up, and refused to print the huge policy proposals. As soon as
|
||
we got in as editors, one of the authors quickley hit us with an
|
||
article, knowing full well that it had already been refused.
|
||
That was not mentioned. Imediatley, we received two more, each
|
||
of the same length, along with demands that they be printed in
|
||
the name of fair play. Ok, fair play is fair play. One is in
|
||
this week's issue, and one will be in next. That is the end of
|
||
it. Fidonews is a NEWSLETTER. Fifty pages of legalese per week
|
||
is too much. Not because of pertinence, but because it is too
|
||
boring to live with. In the future, we will make policy four
|
||
replacements available for downloading, and run announcements of
|
||
them as they arrive. If they are submited with short articles
|
||
explaining how they differ, those will be considered as articles.
|
||
|
||
We received an excellent letter stating that back and forth
|
||
arguements about issues are better in echos. The writer is
|
||
quite correct. The recent spate of "I said", "you said", "no I
|
||
meant" articles on caller id *are* best suited for echos. Once it
|
||
gets to the arguement stage, then netmail and echos are the best
|
||
forum.
|
||
|
||
So how do we plan to do this? Well, if we have nothing
|
||
else to print, than maybe anything will get in. If we have too
|
||
much, then boring articles will get cut first. Next we will cut
|
||
rude articles, then we will cut the illiterate ones. That
|
||
policy will change weekly.
|
||
|
||
Last but not least, I would ask that people submitting
|
||
articles at least read artspec.doc, and attempt to follow it.
|
||
Files that arrive in my inbound with no title can be dealt with;
|
||
ones that arrive in internet mail, with no carriage returns, no
|
||
linefeeds, totally in upper-case, in non-ascii format, are a
|
||
pain in the butt.
|
||
FidoNews 10-13 Page: 3 29 Mar 1993
|
||
|
||
|
||
========================================================================
|
||
Articles
|
||
========================================================================
|
||
Memory Still Warm...
|
||
|
||
Terry L. Travis of Denver Colorado, a long-time BBS System
|
||
Operator and avid supporter of the electronic community, died
|
||
Tuesday, March 23, 1993 of renal and lung cancer. Terry was 37.
|
||
|
||
Viewing will be from 4 PM to 8 PM Friday (26 Mar 93)
|
||
followed by services 10 AM Saturday (27 Mar 93) at Olinger
|
||
Highland Mortuary, 300 E. 104th Avenue, Northglen, Colorado.
|
||
|
||
Terry was born May 20, 1955 in a small Iowa town. Never
|
||
knowing his real parents, he was shuttled from home to orphanage
|
||
to home until he finally came to Denver.
|
||
|
||
Terry started one of the earliest full-time electronic
|
||
bulletin boards in the country in 1983, keeping it continuously
|
||
running until his death. Many times he skipped meals, and even
|
||
car payments, in order to keep the BBS up and available.
|
||
|
||
He was one of the founders of IBECC, a non-profit
|
||
organization dedicated to the electronic community and the
|
||
handicapped. Terry was also responsible for the daily operation
|
||
of the IBECC BBS, maintaining the system, software, and inter-
|
||
network connections.
|
||
|
||
The BBS, which was his love and his life, will continue
|
||
indefinitely; his friend and associate, Marshall Barry, will
|
||
assume responsibility.
|
||
|
||
Terry was friend to many, dedicating himself to others by
|
||
providing solace and a open door to those who were in need, no
|
||
matter the personal cost. Beneath a gruff and crusty attitude,
|
||
there existed a selfless and caring heart.
|
||
|
||
Terry is survived by a daughter, Tara, with whom he has had
|
||
no contact for more than 17 years. He is also survived by the
|
||
family that adopted him, and thousands of computer enthusiasts
|
||
around the world. He truly shall be missed.
|
||
|
||
He has requested that donations be made to cancer / AIDS /
|
||
MS or other research in the hope that no others shall share his
|
||
fate.
|
||
|
||
Contact: Michelle Weisblat or Marshall Barry at (303) 426-
|
||
1847 (voice); P.O. Box 486, Louisville, CO 80027-0486 (US Mail);
|
||
or electronically to "Michelle.Weisblat@f969.n104.z1.FidoNet.Org"
|
||
|
||
FidoNews 10-13 Page: 4 29 Mar 1993
|
||
|
||
|
||
Interested in CB Radio? Why not hook into the echo!
|
||
Read on for details ...
|
||
From: Tony Vilimek (2:253/511)
|
||
|
||
ATTENTION USERS AND SYSOPS !! **
|
||
|
||
Are you interested in Citizens' Band Radio and want to
|
||
contact others with the same interest? Look no further
|
||
and enter the CB Radio FidoNet message area!
|
||
|
||
>---8<--- A snip from the CB Radio Echo Rules ---8<---<
|
||
|
||
8) Keep on topic. The topic is Citizens' Band Radio;
|
||
This means talking about any CB related stuff like
|
||
contacting other CB users, CB equipment and repairs,
|
||
CB DXing, CB legal waffle, CB help and advise, and
|
||
so on.
|
||
|
||
>---8<-------------------------------------------8<---<
|
||
|
||
This echo has been available from the UK national
|
||
backbone for a while now and has been ticking along nicely.
|
||
I'm now looking for worldwide interest and possible easy
|
||
links, for mail traffic to travel on the back of already
|
||
existing zone to zone echo traffic. If you're into anything
|
||
related with CB Radio, come and chat in this echo NOW and
|
||
tell all your friends about it! Message traffic will
|
||
gaurantee availability to your country! Don't waste any
|
||
more time and start chatting in the CB Radio message area
|
||
NOW! ;-)
|
||
|
||
If you are already gating mail in or out of the UK and
|
||
you're interested in hooking up with this fairly new echo,
|
||
please contact me now by netmail. We can discuss ways of
|
||
setting up a reliable interzone link. Or, you could ask
|
||
your UK link to hook up with the echo as it's already
|
||
locally available to them via the normal UK backbone links.
|
||
Thanks in advance for your time.
|
||
|
||
Cheerz, 10-10 till we do it again! ;-)
|
||
|
||
_ // [ CBBBS System Manager ] /\/\ [ FidoNet: (2:253/511) ] \\ _
|
||
\X/ [ CB Radio Echo Moderator ] _/\_ [ AmigaNet: (39:133/100) ] \X/
|
||
FidoNews 10-13 Page: 5 29 Mar 1993
|
||
|
||
|
||
Magazine reviews: MONDO 2000, bOING bOING, WIRED
|
||
|
||
by Tom Jennings (tomj@fido.wps.com)
|
||
26 Mar 93
|
||
|
||
I usually hate to review things. What a terrible task. But there's an
|
||
exception to everything; here's three.
|
||
|
||
For years, I've lived in this in-between world, I do techy things,
|
||
certainly, but I refuse to overlook the frequently oppressive and
|
||
terrible things done with a lot of the junk I could work on (and, sigh,
|
||
get paid for). And all of it starts right here: how we live, work and
|
||
play with each other. Corporate culture, what I call that crap that
|
||
passes for human interaction in that place you probably call "work", I
|
||
simply cannot live with. It quite literally makes me sick.
|
||
|
||
Most of the people I actually live and play with are utterly
|
||
non-technical, but are intelligent, literate people working on all sorts
|
||
of things, like music, building social centers in ex-countries,
|
||
using punk music to transport ideas and communications to ex-USSR,
|
||
operating community switchboards without grants, etc.
|
||
|
||
Slowly, these two diffuse "groups" are growing into each other, with
|
||
wonderful and exciting results. Previously separated fraternal twins
|
||
are together, essentially.
|
||
|
||
Some of them publish magazines. Here's three I've run into.
|
||
|
||
MONDO 2000
|
||
|
||
I should have taken the hint from my friend Mykel Board; simply never do
|
||
negative reviews. A few months back, in a FidoNews editorial (gasp) I
|
||
basically slagged MONDO. I won't hurt myself further by dragging out my
|
||
original words. Or maybe I shouldn't apologize, and instead point out
|
||
just how much MONDO has *changed* in these last two issues.
|
||
|
||
The first hint something was up was a review of a Stun Gun (Nova
|
||
Industries), in issue #8. A marginal note starts, "People have been
|
||
bashing us for our purported gee-whiz approach to new tech. Where do
|
||
they get these ideas? ...". So Paco Xander Nathan does an excellent
|
||
review -- laid over one of MONDO's silly fashion spreads, with
|
||
the models pointing baroque plastic 'ray guns'... OK, OK, MONDO
|
||
takes hints. Very sharp!
|
||
|
||
#8 has Diamanda Galas on the cover and interviewed inside. She's as
|
||
sharp, witty and nasty as ever. But the coup is the engineered
|
||
collision/interview between the bands U2 and NEGATIVELAND; in case you
|
||
weren't aware, NEGATIVELAND did a parody of sorts of a U2 album,
|
||
including audio samples and sleeve. U2 sued them hard. It was handled
|
||
very meanly. So here we've got oh-so-alternative,
|
||
we're-not-corpersate-rock band U2 trying to talk their way out of
|
||
responsibility for putting NEGATIVELAND way out of business. Very sharp
|
||
mammals at work this issue!! A cryptic story about the cypherpunk list.
|
||
Hmm.
|
||
FidoNews 10-13 Page: 6 29 Mar 1993
|
||
|
||
|
||
I actually read all of issue #8 thinking hmm, by some incredibly bizarre
|
||
accident, this is a great magazine. I even bought it. My boyfriend
|
||
rubbed it in.
|
||
|
||
So then whilst doing laundry, caffiening at Farleys, again, there
|
||
appears issue #9. Yeow! It has Jade on the cover! Jade is a local
|
||
girl, you see, someone who's in one of my social circles, friends of
|
||
friends of mine. So I pick it up and take it to my table, embarrassed to
|
||
be seen with it, grumble.
|
||
|
||
Another story about crypto stuff, the story of PGP, and words from Phil
|
||
Zimmerman, it's author. It's pretty good, and I think would actually
|
||
inform people not already involved (hard to do).
|
||
|
||
A fashion spread, PANIC SEX, with Jade, Bridgette (7-foot tall deathrock
|
||
drag boyfriend of Danielle Hell) with a rifle; Stafford and Heidi,
|
||
lovely boys they are. Not a sign of the usual consumption of other
|
||
peoples' trips, something so so common when covering non-mainstreamy
|
||
societies. OK, so I'm hypersensitive, tough shit. Good job! (Great
|
||
spread!)
|
||
|
||
An interview with LAIBACH, what freaks. Scary. A very decent intro to
|
||
ISDN, why it's worth thinking about. OK, so I bought this issue too. I had
|
||
to admit I was more than pleased.
|
||
|
||
I've only mentioned about 15% of each issue's content. It's been really
|
||
worth getting. I actually read 90% of the last two issues.
|
||
|
||
I also feel just as strongly that most previous issues were mainly
|
||
high-priced fluff and self-indulgence. My my how things can change!!
|
||
|
||
I don't think it's a cooincidental one-shot (though anything's
|
||
possible). The USERS GUIDE TO THE NEW EDGE is excellent. It
|
||
covers a mix of tech, high-gimcrackery, fashion (sigh) and interesting
|
||
people. It plays with form in that there's running parallel texts that
|
||
act as footnotes (a traditional, primitive form of hypertext, usually
|
||
poorly exploited). As always, it has more color than your average
|
||
hallucination. I think they arranged themselves in alignment with
|
||
their actual reality, which is somewhat outside of the things the
|
||
cover, interpreting somewhat for public consumption, approaching but
|
||
not yet falling into the abyss of cooption. Edge indeed! There's no
|
||
formulaic approach to this, you gotta feel your way about. Good luck!
|
||
|
||
(MONDO 2000, Box 10171, Berkeley CA 94709; $24/yr, 4 issues(?) US.
|
||
mondo@well.sf.ca.us)
|
||
|
||
bOING bOING
|
||
|
||
Really a giant zine. Wiseass fringey reviews, commentary, stories, etc.
|
||
You'll recognize a lot of names in common in all this fringey writing
|
||
stuff. It has actually become a "scene". bOING bOING has the character
|
||
of the corner of the planet it's main writers are from, Austin Tex-ass. It
|
||
straddles the cool/nerd boundary fairly well. It's more "downscale" than
|
||
MONDO; they apparently don't have their own oil-well or whatever. These
|
||
FidoNews 10-13 Page: 7 29 Mar 1993
|
||
|
||
are the people who would graffiti the bathroom and hack the stereo at a
|
||
MONDO party.
|
||
|
||
I stumbled upon MONDO #9 somewhere in Seattle this past summer. I read
|
||
it immediately cover to cover *twice*. A review/interview of Lewis
|
||
Shiner's novel SLAM caused me to locate and buy everything he's written
|
||
except FRONTERA (unfindable). Stories on A-life, fake ants, home surgery
|
||
on your cat, zine reviews, columns of odd, unclassifiable wierdness,
|
||
etc. #9 has a flip-over-back-cover parody of MONDO 2000 that is very
|
||
funny -- parodying exactly what I hated so about previous MONDOs. Maybe
|
||
they read it!
|
||
|
||
Alas, #10 was a bad mistake. I'm sure it's temporary. See, it's called
|
||
the "Sex candy for mutants" issue. Sheesh, apparently people from outer
|
||
space are just like us! We're all het males who like to look at boobies!
|
||
Aww come on GUYS!! Sex means -- sexy! Where were hot stories? Read
|
||
TASTE OF LATEX for a sample of a reasonable display of diversity and
|
||
erotica. Hey I thought we were fringey! Don't hip straight guys ever
|
||
imagine sex with their male friends? Having female sex organs?
|
||
What's the best way to jerk off at work? How to read VGA erotica with
|
||
one hand? Sex under the influence of 60-cycle hum and niacin poisoning?
|
||
Women? Oh them! (Well there was one good sex thing, a review of vibrators
|
||
done by two women no less -- but it was borrowed from BEN IS DEAD. Oh
|
||
well.) I know they'll hate to hear this, but MONDO blurs boundaries
|
||
quite well, one thing I overlooked even in their bad old days.
|
||
|
||
Look I'm no sex expert, I'm a nerd too! But if you're gonna do
|
||
something, please, do reiterate the usual dullness on us... it's OK,
|
||
#10 has things of merit, and I still look forward to the rest of my
|
||
subscription, and probably renewing it. I hotly await #11...
|
||
|
||
(bOING bOING, 11288 Ventura Blvd, #818, Studio City CA 91604; $14/yr US, 4
|
||
issues. boing@wixter.cactus.org)
|
||
|
||
(last but by far not the least)
|
||
|
||
WIRED
|
||
|
||
WIRED is less chaotic, less immediate, and more solidly technical, but
|
||
with am excellent take and approach to technology in our large-scale
|
||
social setting. It's not just technophilia, like all the ucky trade rags
|
||
and "PRODUCT WEAKLY" ad-rags. It has the color and flash of the new
|
||
self-referential edge stuff, but a substantial base. It has a sort-of
|
||
multi-page column covering technical and cultural tidbits. Instead of
|
||
just reviews or stories of the wonderful world of technology, it
|
||
attempts to put objects into some sort of perspective -- "flyaway"
|
||
quasi-portable TV-sat base stations, who uses them, how, and their
|
||
effect on media. Sterling's story/report on VR used by the military,
|
||
starts out with the usual gee-whiz hook, but ends up covering it's
|
||
position in the post-cold-war political and economic world.
|
||
|
||
WIRED is bright and colorful, and the major stories start with flashy
|
||
hooks to suck you in, but each follows up with solid writing and
|
||
reporting. Let's hope they can continue to pull this off, and not go the
|
||
way of OMNI (which, as I recall, once had a lot more substantial pop
|
||
FidoNews 10-13 Page: 8 29 Mar 1993
|
||
|
||
science, before it devolved into embarrasing UFO and magic-pill
|
||
stories).
|
||
|
||
Issue #1 also has a talk between Camille Paglia (smart feminist
|
||
troublemaker) and Stuart Brand (Whole Earth stuff and Media Lab),
|
||
discussing Marshall McLuhan, that whacky Canadian who pegged our culture
|
||
so well. OK, I call this a blatant position piece, a statement of where
|
||
WIRED wants to be. I want to be there too!
|
||
|
||
WIRED looks like it might become a major mover. They're independent, yet
|
||
seem to have substantial support, and national distribution. I
|
||
immediately bought a subscription.
|
||
|
||
(You might get the impression I subscribe to magazines all the time; in
|
||
fact I now have a total of four subscriptions, period.)
|
||
|
||
(WIRED, Box 191826, San Francisco CA 94119-1826; $19.95/yr US, 6 issues.
|
||
lr@wired.com)
|
||
|
||
--
|
||
Tom Jennings / tomj@fido.wps.com / World Power Systems / San Francisco CA
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
White House press releases direct to FidoNet!
|
||
|
||
The Office of Media Affairs at the U.S. White House (you know, the
|
||
electronic propaganda ministers for the current regime) have arranged to
|
||
output official press releases, news items, quotable quotes, etc
|
||
directly to FidoNet. (You read it right -- the W.H. O.M.A. knows what
|
||
FidoNet is, and went out of their way to get their propaganda to us --
|
||
OK so of course they would, they want anyone who will listen to read
|
||
their stuff -- but the amazing part is that they noticed -- I'm still
|
||
not sure if this is good or bad -- I seem to have gotten off the
|
||
original point -- everyone here's an American, right? -- I mean -- )
|
||
|
||
OK. Where was I.
|
||
|
||
So the Office of Media Affairs at the U.S. White house has made
|
||
available for direct FidoNet consumption oh never mind. It's available
|
||
as a FidoNet echo conference named INET.WHITE.HOUSE. It is wanting
|
||
people to carry it. You can request a feed from the echomail
|
||
outlet nearest you, though it is not yet on the backbone; if enough
|
||
people ask for it etc. Try AREAFIXing to 1:13/13 for INET.WHITE.HOUSE.
|
||
Maybe that will work, I don't know. Hell, I don't read echo mail.
|
||
|
||
Tom Jennings
|
||
tomj@fido.wps.com
|
||
|
||
PS: It also wants an archive site to hold old stuff; if you own a disk
|
||
manufacturing company or are just plain perverse, you could start archiving
|
||
this stuff and announce in these epages it's availability...
|
||
FidoNews 10-13 Page: 9 29 Mar 1993
|
||
|
||
|
||
--
|
||
Tom Jennings / tomj@fido.wps.com / World Power Systems / San Francisco CA
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
Genetic Algorithm echo being started
|
||
|
||
I have been perusing the Internet lately, and have picked up a liking
|
||
for Neural Net, Artificial Intelligence, & Genetic Algorithm related
|
||
topics. (Referred to as NN,AI and GA respectively from here on in)
|
||
Upon browsing thru the backbone and non-backbone echolists, I noticed
|
||
the AI and NEURAL_NET echoes, which I am now carrying, but nothing
|
||
relating to GA and/or Natural Life type coding/research. Due to this
|
||
I am attempting to start a new echo, with the tentative areaname of
|
||
GA_Echo, which will deal specifically with Genetic Algorithms and the
|
||
uses it can be put to, as well as Natural Life type approaches. If
|
||
you would be interested in carrying this echo, either now or once it
|
||
would make backbone status (assuming interest is sufficient, and a
|
||
number of other things <g>) feel free to contact me via netmail
|
||
at 1:115/100. I am currently finishing the first draft of the
|
||
conference guidelines, and am open to review and/or criticism of said
|
||
document by other GA/NN/AI interested sysops.
|
||
|
||
Paul M. Chartraw
|
||
The Hideaway BBS
|
||
1:115/100
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
The Comics For Sale conference
|
||
Walter Tietjen (FidoNet 1:151/114 - AlterNet 7:42/2022)
|
||
|
||
Rules of the CMX4SALE conference:
|
||
|
||
This is the place to buy/sell/trade comics and comic-character toys.
|
||
|
||
If you use a `handle' on your local BBS, please include your REAL NAME
|
||
in your ad. Also a telephone number &/or Snail-Mail address should be
|
||
included in your ad. Mail/telephone replies to ads take less time than
|
||
replies in the conference.
|
||
|
||
USA - Prices should be in U.S.$
|
||
Other countries - _PLEASE_ specify currency (Example: Canada are those
|
||
prices in U.S.$ or Can-$?)
|
||
|
||
Both personal and commercial ads may appear here.
|
||
|
||
This conference is available in both GroupMail and EchoMail formats
|
||
(SysOp's choice) and is FULLY moderated on the GroupMail side. GroupMail
|
||
TopStar is AlterNet 7:42/2022 a/k/a FidoNet 1:151/114
|
||
|
||
SysOps: You are _WELCOME_ to pass this conference to _ANY_ node
|
||
which wants it. _NO_ pre-approval needed.
|
||
FidoNews 10-13 Page: 10 29 Mar 1993
|
||
|
||
|
||
CMX4SALE conference - active nodes (Z1=FidoNet Z7=AlterNet):
|
||
|
||
Net City Phone
|
||
1:19/37 Russellville AR 1-501-968-3910
|
||
1:124/3112 Dallas, TX 1-214-557-2642
|
||
1:151/114 Raleigh NC 1-919-833-3412
|
||
1:294/1 St. Joseph MO 1-816-233-1357
|
||
1:351/715 Ucluelet, BC Canada 1-604-726-2577
|
||
1:380/7 Shreveport LA 1-318-424-9260
|
||
1:393/3 Justin, TX 1-817-648-2599
|
||
1:2410/290 Dearborn, MI 1-313-562-0051
|
||
1:3625/462 Mobile AL 1-205-633-5875
|
||
1:3628/7 Carolina Beach, NC 1-919-458-7999
|
||
1:3628/10 Carolina Beach, NC (Mail hub) 1-919-458-3033
|
||
1:3641/1 Durham NC 1-919-286-7738
|
||
7:520/560 Lyndhurst, NJ 1-201-935-7968
|
||
7:520/561 Lyndhurst, NJ 1-201-935-1485
|
||
7:520/562 Lyndhurst, NJ 1-201-935-7004
|
||
7:520/563 Lyndhurst, NJ 1-201-935-7008
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
Caller id again
|
||
Stanton McCandlish, SysOp: Noise in the Void Data Center BBS
|
||
FidoNet: 1:301/2 Internet: anton@hydra.unm.edu
|
||
|
||
Well yet again, another person has sent some long winded article
|
||
supporting CID, and again most of it is misinterpretation of
|
||
what I said, based on what the writer wished I had said so that
|
||
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
|
||
just this imaginary point. I said "that's what the login
|
||
questionnaires are for." I agree that CBV can be abused, and
|
||
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
|
||
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. And finally, the merits of Canadian vs US law is real
|
||
neat and all but totally irrelevant. READ the article, for
|
||
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
|
||
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.
|
||
FidoNews 10-13 Page: 11 29 Mar 1993
|
||
|
||
|
||
PS: the idea that having CID blocking would make someone
|
||
prosecutable for un- authorized access is a very silly fantasy.
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
Caller Id....Curse or Help?
|
||
|
||
by Mike Phillips
|
||
1:3602/1015
|
||
|
||
I have been following the discussion of the benefits/risks of using
|
||
and/or having caller id installed as a first line of defense for some
|
||
time now both here on Fido and on other networks as well.
|
||
|
||
It would seem that most of the gripes, complaints and general bitching is
|
||
really being blown out of proportion. Here in Talladega where I live, we
|
||
have yet to be able to get Caller-ID. Because >I< want to ensure that I
|
||
REALLY am calling the person who left the phone number information
|
||
during logon I voice verify. If you call in long distance, expect the
|
||
call to be collect....my phone bill is high enough already.
|
||
|
||
You can rest assured that I will install Caller-ID as soon as I can
|
||
along with control software that will control access to my BBS via this
|
||
technology. IF you feel that having the teleco "giving" me your number
|
||
than more than likely you wouldn't enter the correct number when you
|
||
logon any ways and definitely would not allow me to call you collect. It
|
||
all boils down to one thing ladies and gentleman....you are calling MY
|
||
HOUSE, using MY COMPUTER and downloading software that I have spent GOOD
|
||
money to collect. IF you do not want to allow my system to automatically
|
||
verify you then....DONT CALL ME!
|
||
|
||
I have set up several BBS 's for business use (before the advent of
|
||
Caller-ID) and in several circumstances, Caller-ID would have provided a
|
||
level of security that nothing else will. In one instance, there are two
|
||
stores that need to transfer sales data at the end of the day...with
|
||
Caller-ID, the ONLY modem that will "get through" is the one that is
|
||
calling from the number programmed into the Caller-ID software. This
|
||
feature alone allowed me to make a custom software sale (along with
|
||
hardware) that I would not have made otherwise. There is so much to gain
|
||
by using Caller-ID that I think every SYSOP should investigate using it.
|
||
Hell, even some of the newer modems are incorporating the Caller-ID
|
||
"box" into the modems....does that tell us something?
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
$50 or $100 reward offered
|
||
BY J. Alec West (1:105/135)
|
||
|
||
Recently, I called the National Computer Virus Association
|
||
BBS in California (aka McAfee Associates) to download the latest
|
||
version of their SCAN.EXE and CLEAN.EXE shareware and associated
|
||
documentation. It might be good to include in the next issue of
|
||
FidoNews that these recent versions are available for download
|
||
from the NCVA BBS, 1-408-988-4004. Callers don't have to be
|
||
FidoNews 10-13 Page: 12 29 Mar 1993
|
||
|
||
'registered users' to download from this board and there is no
|
||
charge for doing so (beyond the cost of Ma Bell for the LD
|
||
call). But, besides that, the opening screens at logon showed
|
||
the following information:
|
||
|
||
***********************************************************************
|
||
NOTICE: $50 REWARD.
|
||
|
||
Old Timers. If you were a user of McAfee Associates first Scan program
|
||
from late 1987 or early 1988 PLEASE contact John McAfee at 408-980-3601 or
|
||
40-988-3832. Your call will be much appreciated. Thanks.
|
||
|
||
P.S. If you were a REGISTERED user double the reward!!!
|
||
**********************************************************************
|
||
|
||
Methinks Mr. McAfee 'misplaced' his original software and is
|
||
willing to pay for copies of it. Since his software has been in
|
||
widespread use throughout the modem community, surely someone
|
||
out there could have it...and profit from finding it and letting
|
||
McAfee have it back. Unfortunately, I only got my system 2
|
||
years ago...and can't cash in. But someone might have this
|
||
software in their archives. Is this FidoNews-applicable?
|
||
|
||
Editors note: We thought so ...
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
Nodelist Troubles
|
||
|
||
Nodelist Troubles
|
||
By Roland van der Put, 2:285/301.1
|
||
|
||
Hello!
|
||
|
||
In the last couple of FidoNews issues there appeared a few articles
|
||
about the FidoNet nodelist. This is anther one. I will introduce
|
||
myself first. I am Roland van der Put, living in Holland and I am a
|
||
student. Being the author of the program Nodelist Updater, I have a
|
||
lot of experience with the FidoNet nodelist and difference files.
|
||
Therefor, I would like to react on several articles which appeared in
|
||
FidoNews.
|
||
|
||
Vol. 10 No. 6: Is there a programmer in the house?!, by Tom Jennings.
|
||
|
||
Tom, I can answer this question with yes. At the moment I am working
|
||
on a program called Nodelist Generator. It is my intention that this
|
||
program becomes the replacement for MakeNl. I already have an alfa
|
||
version which can handle nodelist segments for Hubs, but I have just
|
||
started and programming takes a lot of time. Because I will be very
|
||
busy with examinations the next 8 weeks, it may take some time before
|
||
the first working beta version comes out. I planned to release the
|
||
first beta version somewhere in June. Stay tuned...
|
||
|
||
Vol. 10 No. 6: Nodelist Problems Cost Sysops *MEGA* Bucks!, by Tom
|
||
Hall.
|
||
FidoNews 10-13 Page: 13 29 Mar 1993
|
||
|
||
|
||
Thanks for explaining why things went wrong. It seems that we have
|
||
come to the same conclusion. MakeNl fails to handle these errors. I
|
||
will try to correct these kinds of errors in Nodelist Generator. I
|
||
also want to make it a bit more user-friendly. Because generating
|
||
difference files is a complicated business, it can not be done within
|
||
a few weeks. After a busy period of 8 weeks, I will have three months
|
||
of holiday: lot's of time to continue programming.
|
||
|
||
Vol. 10 No. 9: *A FidoNet (FTN) Domain Name Service, by Robert Heller.
|
||
|
||
It is my opinion that your proposal is to difficult to understand, at
|
||
least for some of us. The FidoNet nodelist works, but it is getting
|
||
big. Many BBS'es only use a Zone nodelist or a Region nodelist. This
|
||
helps a lot. Having three different addresses is too complicated. I
|
||
have another solution which I will explain in the next part of my
|
||
article.
|
||
|
||
Vol. 10 No. 10: Interfacing FidoNet with the Internet, by Gavin
|
||
Hurlbut.
|
||
|
||
I agree with you that exchanging mail with other networks is not as
|
||
easy as it should. But I already see that FidoNet echomail is gated to
|
||
and from InterNet! I have a different solution for the same problem.
|
||
If I want to send mail to someone on Internet then I will have to use
|
||
an UFGATE system. Now I have to look for myself to which node I should
|
||
send my mail. The message also needs to have a special format. Why
|
||
can't I send mail to 'gjhurlbut@1302.watstar.waterloo.ca' just by
|
||
entering this address in my editor? Why does it have to be so
|
||
complicated? If I could enter an Internet address at the address
|
||
prompt then my mailer and routing software should be able to take care
|
||
of it. If an address does not end with 'fidonet.org' then it should be
|
||
gated to Internet. The only thing that needs to be modified are some
|
||
software programs. The UFGATE system(s) can be obtained from the
|
||
nodelist.
|
||
|
||
Well, that's it for now. I hope to see some comments on my thoughts...
|
||
|
||
Roland van der Put
|
||
|
||
BTW: Nodelist Updater can be frekked with 'NU' at 2:285/301 and
|
||
2:285/307 in case you are interested.
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
CorelDRAW! ECHO
|
||
|
||
By Mike Griffin
|
||
CorelDRAW! Echo
|
||
|
||
With the growing number of DTP (Desk Top Publishing) people, CorelDRAW!
|
||
has gained it's share of popularity. With version 2.0, the product was
|
||
a good tool for graphic illustrations and DTP. With version 3.0, the product
|
||
has matured into one of the most powerful tools for DTP and graphic art.
|
||
Soon version 4.0 will be released and promises to be the best all around
|
||
FidoNews 10-13 Page: 14 29 Mar 1993
|
||
|
||
collection of graphics programs.
|
||
|
||
I have decided that I would try and get a worldwide echo going that would
|
||
cover topics concerning CorelDRAW's ability. This would be a great place
|
||
to swap tips, clip art and sample drawings. Questions could be answered by
|
||
our expert users and together we could all learn some shortcuts.
|
||
Whether you are a professional publisher or commercial artist, or just a
|
||
hobbyist, this echo will enhance your ability to express yourself.
|
||
|
||
If you are interested in receiving it, please contact me via netmail at the
|
||
following address.
|
||
|
||
Mike Griffin
|
||
CorelDRAW! Echo
|
||
1:106/5999
|
||
|
||
Thank You and Happy Publishing!
|
||
Mike Griffin
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
An open letter to the people who waste bandwidth
|
||
Steve Mulligan, 1:163/307.30
|
||
|
||
Why! Why do you waste my time and money! Don't ya think I
|
||
needed that money? Well, I did. We're in a recession ya know.
|
||
Well, so come on eh!?
|
||
|
||
When are ya gonna stop quoting 80% of message text when you
|
||
reply? When are you gonna get rid of those long signature lines at
|
||
the end of your messages? When are you gonna start using an origin
|
||
line, to show your origin? And did you know that origin lines are
|
||
supposed to be a certain length or else some software crashes? I
|
||
found that out the other day. So shorten your origin lines okay?
|
||
|
||
I don't care how many addresses you have! I don't care how
|
||
many echo's you moderate! So don't tell me! Leave that waste of
|
||
my money out of your messages okay? I don't want them.
|
||
|
||
Thank you. That's all I gotta say. For now.
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
More on the point nodelist
|
||
Steve Mulligan, 1:163/307.30
|
||
|
||
Well, a lot of people have sent me mail about the point
|
||
nodelist. People have told me that Version 7 nodelists support 4D
|
||
points so, any point who wants to be in, just NetMail me and you'll
|
||
be added to the point nodelist. Please send what city you live in
|
||
and what you want to call your BBS in the nodelist.
|
||
|
||
A few other people have also sent me their own point lists.
|
||
What I am asking is for every sysop reading this who has a point
|
||
list on their system, to send it to me via NetMail. Please, help
|
||
FidoNews 10-13 Page: 15 29 Mar 1993
|
||
|
||
the point nodelist grow so we can shrink the size of the full
|
||
nodelist.
|
||
|
||
Don't forget, the point nodelist can be freq'ed each Friday as
|
||
PRIVLIST.* from 1:163/307.
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
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
|
||
FidoNews 10-13 Page: 16 29 Mar 1993
|
||
|
||
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.
|
||
|
||
> 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
|
||
FidoNews 10-13 Page: 17 29 Mar 1993
|
||
|
||
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
|
||
|
||
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
|
||
FidoNews 10-13 Page: 18 29 Mar 1993
|
||
|
||
> 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
|
||
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.
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
The TRULY democratic policy proposal revealed
|
||
By Glen Johnson 1:2605/269
|
||
|
||
If you all read the 'anonymous' article in last week's Snooze,
|
||
then this really needs no introduction.
|
||
|
||
This is Fidonet Policy Draft version 4.1c, submitted to the
|
||
RCs for consideration of referendum on January 17, 1993.
|
||
|
||
This document is the one that opened the floodgates and caused
|
||
a bunch of other "policies" to be drafted. 4.1c is the standard
|
||
against which others are being compared. I urge you all to read
|
||
it, and when you do, you'll understand why it has such strong
|
||
support around the world. It is the first, and only, proposal
|
||
that puts Fidonet squarely in hands of the sysops, where it
|
||
belongs. One sysop, one vote.
|
||
|
||
Significant contributions were made to this policy by Howie Ducat,
|
||
NC 278; yours truly, NC 2605; Rich Wood, NEC 278; Bob Moravsik,
|
||
1:2606/583; and Ron Dwight, ZC2. And many other folks.
|
||
|
||
Yes Virginia, democracy IS a popular idea ....
|
||
|
||
FidoNet Policy Document Version 4.1c January 17, 1993
|
||
|
||
REVISION SUMMARY:
|
||
|
||
1. *C's elected by sysops for two year terms, except IC which is
|
||
appointed (or removed) by 2/3 ZC's. There is a replacement
|
||
election procedure added (recall), impeachment removed. THIS IS
|
||
THE MOST SUBSTANTIAL CHANGE.
|
||
2. Election rules issued by IC
|
||
3. Fidonews address changed
|
||
4. Updated to agree with present practice.
|
||
5. Appeal of ZC decision now ONLY to IC.
|
||
6. Referendum on policy changes may now be tripped by 5% of NCs
|
||
FidoNews 10-13 Page: 19 29 Mar 1993
|
||
|
||
7. Examples in section 10 removed.
|
||
8. Duplicate statements removed.
|
||
9. Minor clean up.
|
||
_______________________
|
||
|
||
This policy document is being submitted for ratification in
|
||
accordance with the provisions of version 4.07. If ratified it
|
||
supersedes version 4.07 passed June 9, 1989
|
||
|
||
1 Overview
|
||
|
||
This document establishes the policy for sysops who are members of
|
||
the FidoNet organization of electronic mail systems. FidoNet is
|
||
defined by the NodeList segments issued weekly under the direction
|
||
and supervision of the 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. 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 members of FidoNet beyond those
|
||
included in this document, other than enforcement of local mail
|
||
periods.
|
||
|
||
1.0 Language
|
||
|
||
The official language of FidoNet is English. All documents must
|
||
exist in English. Translation into other languages is encouraged.
|
||
|
||
1.1 Introduction
|
||
|
||
FidoNet is an amateur electronic mail system. As such, all of its
|
||
participants and operators are unpaid volunteers. From its early
|
||
beginning as a few friends swapping messages back and forth (1984),
|
||
it now (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 on their system.
|
||
|
||
FidoNet is large enough that it would quickly fall apart of its own
|
||
weight unless some sort of structure and control were imposed on
|
||
it. 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 with these groupings. This overview
|
||
provides a summary of the structure; specific duties of the
|
||
coordinator positions are given later in the document.
|
||
FidoNews 10-13 Page: 20 29 Mar 1993
|
||
|
||
|
||
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 (Fidonet Sysop) formulates a policy for running the board
|
||
and dealing with users. 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.
|
||
|
||
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.
|
||
|
||
1.2.3 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 elected by a majority of votes cast by
|
||
Fidonet Sysops in a Net, and serves a term of two years.
|
||
|
||
1.2.3.1 Network Routing Hubs
|
||
|
||
FidoNews 10-13 Page: 21 29 Mar 1993
|
||
|
||
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 the hubs to arrange, and
|
||
will not be discussed here, except that a network coordinator
|
||
cannot delegate responsibility to mediate disputes.
|
||
|
||
1.2.4 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 nodelists 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 is elected by a majority of votes cast by
|
||
the Fidonet Sysops in the Region, and serves a term of two years.
|
||
|
||
1.2.5 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 nodelists from all of the regions
|
||
in the zone, and creates the master nodelist and difference file,
|
||
which is then distributed over FidoNet in the zone. A Zone
|
||
Coordinator does not perform message-forwarding services for any
|
||
nodes in the zone.
|
||
|
||
Zone Coordinators are elected by a majority of votes cast by the
|
||
Fidonet Sysop in the Zone. They serve a term of two years.
|
||
|
||
1.2.6 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-zonal issues. This
|
||
includes, but is not limited to: working out the details of
|
||
nodelist production, mediating inter-zonal disputes, and such
|
||
issues not addressed at a lower level of FidoNet.
|
||
|
||
1.2.7 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 elections -- arranging
|
||
FidoNews 10-13 Page: 22 29 Mar 1993
|
||
|
||
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 (or removed) by a two
|
||
thirds majority of the Zone Coordinators, and serves a term of two
|
||
years.
|
||
|
||
1.2.8 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.
|
||
|
||
Understanding that there may be rare occassions where a coordinator
|
||
may need to be replaced, a replacement election may be held upon
|
||
petition of 20% of the number of individuals on one level lower.
|
||
Only TWO such elections may be held during the term of a
|
||
coordinator. In the event such an election results in a
|
||
replacement coordinator, the replacement coordinator shall serve
|
||
out the remainder of the term without being subject to a
|
||
replacement election. (Choose your candidates wisely).
|
||
|
||
Nothing in this section shall be interpreted to allow a replacement
|
||
coordinator to violate this policy.
|
||
|
||
1.2.9 Election Procedures
|
||
|
||
The International Coordinator shall issue such reasonable rules and
|
||
regulations to carry out the elections required herein, provided
|
||
however, no sysop shall be prevented from running for any elected
|
||
position .
|
||
|
||
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 node 1:1/23; a file describing the
|
||
format to be used is available from 1:1/23 and many other systems.
|
||
FidoNews 10-13 Page: 23 29 Mar 1993
|
||
|
||
|
||
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 are described in
|
||
section 5.6.
|
||
|
||
1.3.3 Zone Mail Hour
|
||
|
||
Zone Mail Hour (ZMH) is a defined time during which all nodes in
|
||
a zone are required to be able to accept netmail. Each Fidonet
|
||
zone defines a ZMH and publishes the time of its ZMH to all other
|
||
Fidonet zones. See sections 2.1.8 and 10.2.
|
||
|
||
Zone Mail Hour has previously been referred to as National Mail
|
||
Hour and Network Mail hour. The term Zone Mail Hour is more
|
||
accurate.
|
||
|
||
1.3.4 Nodelist
|
||
|
||
The nodelist is a file updated weekly which contains the addresses
|
||
of all recognized FidoNet nodes. This file is currently made
|
||
available by the Zone Coordinator not later than Zone Mail Hour
|
||
each Saturday, and is available electronically for download or file
|
||
request at no charge. To be included in the nodelist, a system
|
||
must meet the 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, produced under the
|
||
direction and supervision of 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.
|
||
FidoNews 10-13 Page: 24 29 Mar 1993
|
||
|
||
|
||
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.
|
||
|
||
1.3.6 Commercial Use
|
||
|
||
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 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
|
||
FidoNews 10-13 Page: 25 29 Mar 1993
|
||
|
||
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 policy 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.
|
||
|
||
2.1.4 Encryption and Review of Mail
|
||
|
||
FidoNet is an amateur system. Our technology is such that the
|
||
privacy of messages cannot be guaranteed. 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 system 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
|
||
FidoNews 10-13 Page: 26 29 Mar 1993
|
||
|
||
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 as 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.
|
||
|
||
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, unless you hold a Network Coordinator or Hub
|
||
Coordinator position. Routing traffic through a node not obligated
|
||
to perform routing without the permission of that node may be
|
||
annoying behavior. This includes unsolicited echomail.
|
||
|
||
If 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.
|
||
FidoNews 10-13 Page: 27 29 Mar 1993
|
||
|
||
|
||
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 this 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.
|
||
|
||
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.
|
||
|
||
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 impact 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, Regional or Zone
|
||
Coordinator 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).
|
||
|
||
FidoNews 10-13 Page: 28 29 Mar 1993
|
||
|
||
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.
|
||
|
||
Systems may also be dropped from the nodelist for cause. See
|
||
section 9, and sections 4.3 and 5.2.
|
||
|
||
It is considered annoying behavior to assist a system which was
|
||
excommunicated in circumventing that removal from the nodelist.
|
||
For example, if you decide to provide an echomail feed to your
|
||
friend who has been excommunicated, it is likely that your listing
|
||
will also be removed.
|
||
|
||
2.1.13 Timing of Zone Mail Hour
|
||
|
||
The exact timing of Zone Mail Hour for each zone is set by the Zone
|
||
Coordinator. See section 10.2.
|
||
|
||
2.1.14 Non-observance of Daylight Savings Time
|
||
|
||
FidoNet does not observe daylight savings time. In areas which
|
||
observe daylight savings time the FidoNet mail schedules must be
|
||
adjusted in the same direction as the clock change. Alternatively,
|
||
you can simply leave your system on standard time.
|
||
|
||
2.2 How to obtain a node number
|
||
|
||
You must first obtain a current nodelist so that you can send mail.
|
||
You do not need a node number to send mail, but you must have one
|
||
in order for others to send mail to you.
|
||
|
||
The first step in obtaining a current nodelist is to locate a
|
||
FidoNet node. 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. Networks are more restricted in area
|
||
FidoNews 10-13 Page: 29 29 Mar 1993
|
||
|
||
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 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) Your voice telephone number
|
||
3) The name of your system.
|
||
4) The city and state where your system is located.
|
||
5) The phone number to be used when calling your system.
|
||
6) Your hours of operation, netmail and BBS.
|
||
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, racking up large
|
||
phone bills, which is very annoying. In short, the only thing
|
||
FidoNews 10-13 Page: 30 29 Mar 1993
|
||
|
||
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 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
|
||
|
||
Any Coordinator is responsible for obtaining and making available,
|
||
on a weekly basis, nodelist difference files and FidoNews.
|
||
|
||
FidoNews 10-13 Page: 31 29 Mar 1993
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
FidoNews 10-13 Page: 32 29 Mar 1993
|
||
|
||
3.7 Tradition and Precedent
|
||
|
||
A coordinator is not bound by the practices of predecessor or peers
|
||
beyond the scope of this document.
|
||
|
||
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.
|
||
|
||
3.8 Technical Management
|
||
|
||
The primary responsibility of any coordinator is technical
|
||
management of network operations. Decisions must be made on
|
||
technical grounds.
|
||
|
||
4 Network Coordinator Procedures
|
||
|
||
4.1 Responsibilities
|
||
|
||
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 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.
|
||
|
||
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 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.
|
||
FidoNews 10-13 Page: 33 29 Mar 1993
|
||
|
||
|
||
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.
|
||
|
||
It is also recommended, though not required, that you call a board
|
||
which is applying for a node number before assigning it a node
|
||
number.
|
||
|
||
You may not assign a node number to a node in an area covered by
|
||
an existing network. Further, if you have nodes in an area covered
|
||
by a network in formation, those nodes must be 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, then you can take whatever action you deem fit, according
|
||
to the circumstances of the case.
|
||
|
||
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 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.)
|
||
|
||
At your discretion, you may distribute a portion of this workload
|
||
FidoNews 10-13 Page: 34 29 Mar 1993
|
||
|
||
to routing hubs. In this case, you should receive the nodelists
|
||
from the Hub Coordinators within your network. You will need to
|
||
maintain a set of nodelists for each hub within your network, since
|
||
you cannot count on getting an update from each Hub Coordinator
|
||
every week. You should assemble a master nodelist for your network
|
||
every week and send it to your Regional Coordinator by the day and
|
||
time 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 Saturday, 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
|
||
net works, or to form new networks.
|
||
|
||
3) To assign network numbers to networks in the region and define
|
||
their boundaries.
|
||
|
||
4) To compile a nodelist of all of the networks and independents
|
||
in the region, and to send a copy of it to the Zone Coordinator
|
||
whenever it changes.
|
||
|
||
5) To ensure the smooth operation of networks within the region.
|
||
|
||
6) To make new nodelist difference files, Policies, and issues of
|
||
FidoNews available to the Network Coordinators in the region as
|
||
soon as is practical.
|
||
FidoNews 10-13 Page: 35 29 Mar 1993
|
||
|
||
|
||
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.
|
||
|
||
It is also recommended, though not required, that you call a board
|
||
which is applying for a node number before assigning it a node
|
||
number.
|
||
|
||
You should use network mail to inform a new 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, then you can take whatever action you deem fit, according
|
||
to the circumstances of the case.
|
||
|
||
If you receive a node number request from outside your region, you
|
||
must forward it to the most local coordinator for the requestor as
|
||
you can determine. If you receive a node number request from a new
|
||
node that is in an area covered by an existing network, then you
|
||
must forward the request to the Coordinator of that network instead
|
||
of assigning a number yourself.
|
||
|
||
If a network forms in an area for which you have independent nodes,
|
||
those nodes will be transferred to the local network as soon as is
|
||
practical.
|
||
|
||
5.3 Encouraging the Formation and Growth of Networks
|
||
|
||
One of your main duties as a Regional Coordinator is to 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. Refer to section 2.4. Note that
|
||
this is not intended to encourage the formation of trivial
|
||
networks. Obviously, one node does not make a network. The exact
|
||
number of nodes required for an effective network must be judged
|
||
according to the circumstances of the situation, and is left to
|
||
FidoNews 10-13 Page: 36 29 Mar 1993
|
||
|
||
your discretion.
|
||
|
||
5.4 Assigning Network Numbers
|
||
|
||
It is your responsibility to assign network numbers to new networks
|
||
forming within your region. You are assigned a pool 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 for your region.
|
||
|
||
First, you must maintain the list of independent nodes in your
|
||
region. You should attempt to implement name changes, phone number
|
||
changes, and so forth in this nodelist as soon as possible. You
|
||
should also on occasion send a message to every independent node
|
||
in your region to ensure that they are operational. If a node
|
||
turns out to be "off the air" with no prior warning, you can either
|
||
mark the node down or remove it from the nodelist. (Nodes are to
|
||
marked DOWN for a maximum of two weeks, after which the line should
|
||
be removed from the nodelist.)
|
||
|
||
Second, you must receive the nodelists from the Network
|
||
Coordinators within your region. You will need to maintain a set
|
||
of nodelists for each network within your region, since you cannot
|
||
count on getting an update from each Network Coordinator every
|
||
week. You should assemble a master nodelist for your region every
|
||
week and send it to your Zone Coordinator by the day and time
|
||
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 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.
|
||
|
||
If a network grows so large that it cannot reasonably accommodate
|
||
FidoNews 10-13 Page: 37 29 Mar 1993
|
||
|
||
traffic flow during the Zone Mail Hour, the Regional Coordinator
|
||
can suggest that the nodes consider the creation of one or more new
|
||
networks from that network.
|
||
|
||
It is your obligation as Regional Coordinator to maintain direct
|
||
and reasonably frequent contact with the networks in your region.
|
||
The exact method of accomplishing this is left to your discretion.
|
||
|
||
5.8 Making Available Nodelists, Policies, and FidoNews
|
||
|
||
As a Regional Coordinator, it is your responsibility to obtain the
|
||
latest nodelist difference file, network policies, and the latest
|
||
issues of FidoNews as they are published, and to make them
|
||
available to the Network Coordinators within your region. The
|
||
nodelist is posted weekly on Saturday by the Zone Coordinator, and
|
||
FidoNews is published weekly on Monday by node 1:1/23. 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 in your region as soon as is practical after you
|
||
receive them. The method of distribution is left to your
|
||
discretion. You are not required to distribute them to any
|
||
independent nodes in your region, though you may if you wish. You
|
||
are encouraged to make all these documents available for
|
||
downloading by the general public.
|
||
|
||
6 Zone Coordinator Procedures
|
||
|
||
6.1 General
|
||
|
||
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 Network 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, which is done by coordinating the activities
|
||
of the Regional Coordinators.
|
||
|
||
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 reviewing and approving any
|
||
geographic exemptions as described in section 5.6.
|
||
|
||
The Zone Coordinator is responsible for insuring the smooth
|
||
FidoNews 10-13 Page: 38 29 Mar 1993
|
||
|
||
operation of gates between that zone and all other zones for the
|
||
transfer of interzonal mail.
|
||
|
||
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 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.
|
||
|
||
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.
|
||
|
||
8.1 Initiation
|
||
|
||
A referendum on policy modification is invoked when 5% of the Net
|
||
Coordinators as determined from the first nodelist of a calender
|
||
year, petition the International Coordinator that they wish to
|
||
consider a proposed new version of Policy. Net Coordinators of
|
||
Networks formed after the first nodelist of the year may be
|
||
petitioners.
|
||
|
||
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 effective
|
||
FidoNews 10-13 Page: 39 29 Mar 1993
|
||
|
||
date for a new policy through announcement in the weekly nodelist
|
||
difference file. The effective date will be not more than one
|
||
month after the close of balloting.
|
||
|
||
8.3 Eligibility to Vote
|
||
|
||
Each individual FidoNet Sysop is entitled to one vote. (One
|
||
person, one vote.)
|
||
|
||
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
|
||
|
||
Given that Policy is intertwined and self referencing, a relatively
|
||
simple change may require several alterations of the document. In
|
||
order to simplify the process, balloting is done on choices between
|
||
whole documents, rather than individual amendments. In the
|
||
simplest case, this means voting yea or nay to a new document. If
|
||
a number of alternatives are to be considered, they must be
|
||
presented as whole documents, from which one is chosen.
|
||
|
||
8.6 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 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. "Abstain" is a valid vote in this case,
|
||
effectively being a vote for not changing the current policy as it
|
||
simply increases the number of votes required to ratify the
|
||
proposed change.
|
||
|
||
9 Resolution of Disputes
|
||
|
||
9.1 General
|
||
|
||
The FidoNet judicial philosophy can be summed up in two rules:
|
||
|
||
1) Thou shalt not excessively annoy others.
|
||
|
||
2) Thou shalt not be too easily annoyed.
|
||
FidoNews 10-13 Page: 40 29 Mar 1993
|
||
|
||
|
||
In other words, there are no hard and fast rules of conduct, but
|
||
reasonably polite behavior is expected. Also, in any dispute both
|
||
sides are examined, and action could be taken against either or
|
||
both parties. ("Judge not, lest ye be judged!")
|
||
|
||
The coordinator structure has the responsibility for defining
|
||
"excessively annoying". Like a common definition of pornography
|
||
("I can't define it, but I know it when I see it."), a hard and
|
||
fast definition of acceptable FidoNet behavior is not possible.
|
||
The guidelines in this policy are deliberately vague to provide
|
||
the freedom that the coordinator structure requires to respond to
|
||
the needs of a growing and changing community.
|
||
|
||
The first step in any dispute between sysops is for the sysops to
|
||
attempt to communicate directly, at least by netmail, preferably
|
||
by voice. Any complaint made that has skipped this most basic
|
||
communication step will be rejected.
|
||
|
||
Filing a formal complaint is not an action which should be taken
|
||
lightly. Investigation and response to complaints requires time
|
||
which coordinators would prefer to spend doing more constructive
|
||
activities. Persons who persist in filing trivial policy
|
||
complaints may find themselves on the wrong side of an 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 via netmail or voice conversation with the other
|
||
sysop.
|
||
|
||
If this fails to resolve the problem, you should complain to your
|
||
Network Coordinator and the other sysop's Network Coordinator. If
|
||
one or both of you is not in a network, then complain to the
|
||
appropriate Regional Coordinator. Should this fail to provide
|
||
satisfaction, you have the right to follow the appeal process
|
||
described in section 9.5.
|
||
|
||
9.3 Problems with your Network Coordinator
|
||
|
||
If you are having problems with your Network Coordinator and feel
|
||
that you are not being treated properly, you are entitled to a
|
||
review of your situation. As with all disputes, the first step is
|
||
to communicate directly to attempt to resolve the problem.
|
||
|
||
The next step is to contact your Regional Coordinator. If your
|
||
case has merit, there are several possible courses of action,
|
||
including a change of Network Coordinators or even the disbanding
|
||
FidoNews 10-13 Page: 41 29 Mar 1993
|
||
|
||
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 appropriate
|
||
Zone Coordinator.
|
||
Zone Coordinator decisions may be appealed to the International
|
||
Coordinator.
|
||
|
||
The International Coordinator will make a decision and communicate
|
||
it to the Zone Coordinator Council, which may reverse it by
|
||
majority vote.
|
||
|
||
If your problem is with a Zone Coordinator per se, that is, a Zone
|
||
FidoNews 10-13 Page: 42 29 Mar 1993
|
||
|
||
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.
|
||
|
||
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 returned to the local network or region to which they
|
||
geographically or technically belong.
|
||
|
||
9.9 Echomail
|
||
|
||
Echomail is an important and powerful force in FidoNet. For the
|
||
purposes of Policy Disputes, echomail is simply a different flavor
|
||
of netmail, and is therefore covered by Policy. By its nature,
|
||
echomail places unique technical and social demands on the net over
|
||
and above those covered by this version of Policy. In recognition
|
||
of this, an echomail policy which extends (and does not contradict)
|
||
general Policy, maintained by the Echomail Coordinators, and
|
||
ratified by a process similar to that of this document, is
|
||
recognized by the FidoNet Coordinators as a valid structure for
|
||
dispute resolution on matters pertaining to echomail. At some
|
||
future date the echomail policy document may be merged with this
|
||
one.
|
||
|
||
10 Appendices
|
||
|
||
10.1 General
|
||
|
||
The Appendices of this document are exceptions to the normal
|
||
ratification process. Section 10.2 can be changed by the
|
||
appropriate Zone Coordinator.
|
||
|
||
10.2 Timing of Zone Mail Hour
|
||
|
||
Zone Mail Hour is observed each day, including weekends and
|
||
holidays. The time is based upon Universal Coordinated Time (UTC),
|
||
also known as Greenwich Mean time (GMT). In areas which observe
|
||
Daylight Savings Time during part of the year, the local time of
|
||
zone mail hour will change because FidoNet does not observe
|
||
Daylight Savings Time. The exact timing of Zone Mail Hour is set
|
||
FidoNews 10-13 Page: 43 29 Mar 1993
|
||
|
||
for each zone by the Zone Coordinator.
|
||
|
||
In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to 1000
|
||
UTC. In each of the time zones, this is:
|
||
|
||
Eastern Standard Time - 4 AM to 5 AM
|
||
Central Standard Time - 3 AM to 4 AM
|
||
Mountain Standard Time - 2 AM to 3 AM
|
||
Pacific Standard Time - 1 AM to 2 AM
|
||
Hawaii Standard Time - 11 PM to Midnight
|
||
|
||
In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to 0330
|
||
UTC.
|
||
|
||
In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to 1900
|
||
UTC. In each of the time Zones involved this is:
|
||
|
||
GMT +12 Zone 6:00 AM to 7:00 AM
|
||
(New Zealand)
|
||
|
||
GMT +10 Zone 4:00 AM to 5:00 AM
|
||
(East Australia)
|
||
(Papua New Guinea)
|
||
(Micronesia)
|
||
|
||
GMT +9.5 Zone 3:30 AM to 4:30 AM
|
||
(Central Australia)
|
||
|
||
GMT +9 Zone 3:00 AM to 4:00 AM
|
||
(Japan)
|
||
(Korea)
|
||
(Eastern Indonesia)
|
||
|
||
GMT +8 Zone 2:00 AM to 3:00 AM
|
||
(Hong Kong)
|
||
(Taiwan)
|
||
(Central Indonesia)
|
||
(Philippines)
|
||
(Western Australia)
|
||
|
||
GMT +7 Zone 1:00 AM to 2:00 AM
|
||
(Malaysia)
|
||
(Singapore)
|
||
(Thailand)
|
||
(Western Indonesia)
|
||
|
||
10.3 Credits, acknowledgments, etc.
|
||
|
||
Fido and FidoNet are registered trademarks of Fido Software, Inc.
|
||
|
||
Index
|
||
|
||
-1/-1, 2.3
|
||
Additional mail events in local network 2.1.8
|
||
Address in message to request node 2.2
|
||
FidoNews 10-13 Page: 44 29 Mar 1993
|
||
|
||
Administrative Region 6.1
|
||
Advantages to network membership 2.2
|
||
Alteration of mail 2.1.5
|
||
Answering machine 2.3
|
||
Announcement of voting results 8.2
|
||
Annoying behavior 1.3.5, 1.4.8, 2.1.1, 2.1.2, 2.1.4, 2.1.6, 2.1.7,
|
||
2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
|
||
Appeal chain 9.5
|
||
Availability of NodeList 1.3.4
|
||
Balloting Period 8.4
|
||
Bombing run 4.2
|
||
BossNode 1.2.1.2
|
||
Boundaries 1.3.2
|
||
Business use of FidoNet 1.3.6
|
||
Calling areas 1.3.2, 5.6, 5.7
|
||
Chain of command 1.2.8
|
||
Changing node numbers 4.3, 5.2
|
||
Checks and balances 1.2.8
|
||
Commercial messages 1.3.6, 2.1.4, 4.2
|
||
Complaint (policy) 2.1.6.1, 9
|
||
Contributions to FidoNews 1.3.1
|
||
Current nodelist 2.1.11
|
||
Daylight Savings Time 2.1.14
|
||
Difference file 4.5, 5.8, 8.2
|
||
Disclosing private mail 2.1.6
|
||
Discussion period 8.2
|
||
Disputes 9
|
||
Distribution of ballots 8.2
|
||
Down 2.3, 4.4, 5.5
|
||
Downloading by users 3.6, 4.5, 5.8
|
||
EchoMail 4.2, 9.9
|
||
Effective date (policy change) 8.2
|
||
Election of coordinators 1.2
|
||
Eligibility to vote 8.3
|
||
Encryption 2.1.4, 4.2
|
||
Exceptions 5.6
|
||
Excessively annoying behavior 1.2.1.1, 1.3.5, 2.1.1, 2.1.2, 2.1.4,
|
||
2.1.6, 2.1.7, 2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
|
||
Exclusivity of Zone Mail Hour 2.1.8
|
||
Excommunication 2.1.12, 4.3, 5.2, 9
|
||
Exemptions, node location 1.3.2, 5.6
|
||
Familiarity with policy 2.1.2, 2.2
|
||
FidoNews 1.3.1
|
||
availability 3.1, 4.5, 5.8
|
||
FTSC 2.1.8, 2.1.9, 2.4
|
||
Gateway 2.1.3
|
||
Geography 1.3.2, 5.6
|
||
Glue 4.5
|
||
Guarantee of mail delivery 1.3.6
|
||
Hats 3.4
|
||
Host-routed mail 4.2
|
||
How to obtain a node number 2.2
|
||
Hub 1.2.3.1, 4.4
|
||
Illegal behavior 2.1.1, 9.6
|
||
Illegal mail 4.2
|
||
FidoNews 10-13 Page: 45 29 Mar 1993
|
||
|
||
In-transit mail 2.1.6.1
|
||
Independent node 4.2, 5.2
|
||
Inter-zonal questions 1.2.6
|
||
International Coordinator 1.4.1, 1.4.9, 7
|
||
Justification of private nodes 2.1.9
|
||
Language 1.0
|
||
Levels of FidoNet 1.2, 1.4
|
||
Local calling areas 1.3.2
|
||
Local policies 1.2, 3.3
|
||
Mail 1.2.3, 4.2
|
||
Mailer 2.2
|
||
Majority 8.6,
|
||
Member of area administrated 3.5
|
||
Modem 2.2
|
||
Modification of mail 2.1.5
|
||
National Mail Hour see Zone Mail Hour
|
||
Network
|
||
advantages 2.2
|
||
boundaries 1.3.2, 5.4
|
||
definition 1.2.3
|
||
forming 2.4, 5.3
|
||
hub 1.2.3.1, 4.4
|
||
numbers 2.2, 5.4
|
||
Network Coordinator 1.2.3
|
||
procedures 4
|
||
Network Mail Hour see Zone Mail Hour
|
||
New sysops 2.1.2, 3.6
|
||
Node numbers 4.3, 5.2
|
||
obtaining 2.2
|
||
Nodelist 1.3.4, 2.2, 4.4, 5.5
|
||
availability 3.1, 4.5, 5.8
|
||
changes 4.4, 5.2
|
||
current 2.1.11
|
||
definition 1.3.4
|
||
official 1.3.4
|
||
Nodes
|
||
definition 1.2.1
|
||
down 2.3
|
||
Observing mail events 2.1.8, 2.1.10
|
||
Obtaining a node number 2.2
|
||
Offensive messages 2.1.5
|
||
Orders (commercial) 1.3.6
|
||
Partial nodelist 1.3.4
|
||
Pirated software 2.1.1
|
||
Point of origin 2.1.3
|
||
Points 1.2.1.2, 2.1.3
|
||
Policy 3.1, 3.3, 4.5, 5.8
|
||
changing 8
|
||
complaint 2.1.6.1, 9
|
||
familiarity with 2.1.2, 2.2
|
||
local 1.2, 3.3
|
||
Precedent 3.7
|
||
Private messages 2.1.6
|
||
Private network 1.2.1.2
|
||
Private nodes 2.1.9
|
||
FidoNews 10-13 Page: 46 29 Mar 1993
|
||
|
||
Problem resolution 9
|
||
Protocol 2.1.8
|
||
Public BBS 3.6
|
||
Ratification 7.1
|
||
Redundant nodes 2.1.9
|
||
Referendum 1.2.7, 8
|
||
Regional Coordinator 1.2.4
|
||
procedures 5
|
||
Regions 1.2.4
|
||
Replacing services 3.4
|
||
Requirements to be in NodeList 1.3.4, 2.1.2, 2.2
|
||
Resolution of disputes 9
|
||
Results Announcement 8.2
|
||
Review of decisions 3.7
|
||
Review of routed traffic 2.1.4
|
||
Routing 2.1.4 - 2.1.7, 4.2
|
||
Routing Hub 1.2.3.1, 4.4
|
||
Rules 9.1
|
||
Speedy decision 9.7
|
||
Standards (FTSC) 2.1.8, 2.4
|
||
Statute of limitations 9.6
|
||
Submissions to FidoNews 1.3.1
|
||
Sysop procedures 2
|
||
System operator (sysop) 1.2.1
|
||
Three-tiered networks 1.2.3.1
|
||
Time limit on decision 9.7
|
||
Timing of Zone Mail Hour 2.1.13, 2.1.14, 10.2
|
||
Top-down 1.4.9
|
||
Tradition 3.7
|
||
Trivial network 5.3
|
||
Unattended systems 2.3
|
||
Updates to nodelist 3.2
|
||
User 1.2.1.1
|
||
User access during ZMH 2.1.8
|
||
Vacation 2.3
|
||
Voice telephone number 2.2
|
||
Vote 8
|
||
eligibility 8.3
|
||
ZMH see Zone Mail Hour
|
||
Zone Coordinator 1.2.5, 6
|
||
procedures 6
|
||
Zone Coordinator Council 1.2.6, 7.1
|
||
Zone Mail Hour 1.3.3, 2.1.8
|
||
timing 2.1.13, 2.1.14, 10.2
|
||
Zones 1.2.5, 1.3.2
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
========================================================================
|
||
Fidonews Information
|
||
========================================================================
|
||
|
||
FidoNews 10-13 Page: 47 29 Mar 1993
|
||
|
||
|
||
------- 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
|
||
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
|
||
FidoNews 10-13 Page: 48 29 Mar 1993
|
||
|
||
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.
|
||
|
||
Asked what he thought of Western civilization,
|
||
M.K. Gandhi said, "I think it would be an excellent idea".
|
||
-- END
|
||
----------------------------------------------------------------------
|
||
|