Volume 8, Number 17 29 April 1991
+---------------------------------------------------------------+
| _ |
| / \ |
| /|oo \ |
| - FidoNews - (_| /_) |
| _`@/_ \ _ |
| FidoNet (r) | | \ \\ |
| International BBS Network | (*) | \ )) |
| Newsletter ______ |__U__| / \// |
| / FIDO \ _//|| _\ / |
| (________) (_/(_|(____/ |
| (jm) |
+---------------------------------------------------------------+
Editor in Chief: Vince Perriello
Editors Emeritii: Thom Henderson, Dale Lovell
Chief Procrastinator Emeritus: Tom Jennings
Copyright 1991, Fido Software. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only.
For use in other circumstances, please contact Fido Software.
FidoNews is published weekly by and for the Members of the
FidoNet (r) International Amateur Electronic Mail System. It is
a compilation of individual articles contributed by their authors
or authorized agents of the authors. The contribution of articles
to this compilation does not diminish the rights of the authors.
You are encouraged to submit articles for publication in
FidoNews. Article submission standards are contained in the file
ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous
Mail system, available for network mail 24 hours a day.
Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, Box 77731, San Francisco CA 94107, USA and are
used with permission.
Opinions expressed in FidoNews articles are those of the authors
and are not necessarily those of the Editor or of Fido Software.
Most articles are unsolicited. Our policy is to publish every
responsible submission received.
Table of Contents
1. EDITORIAL ................................................ 1
Otto-Pilot ............................................... 1
2. ARTICLES ................................................. 2
2nd Democratic Election in Zone-4 ........................ 2
Looking for (Artificial) Intelligence .................... 4
Reply to Snooze 815 ...................................... 7
Your dog walks on water?!? ............................... 11
Z1EC Initial Report ...................................... 19
3. LATEST VERSIONS .......................................... 31
Latest Software Versions ................................. 31
4. NOTICES .................................................. 36
And more!
FidoNews 8-17 Page 1 29 Apr 1991
=================================================================
EDITORIAL
=================================================================
I'm not really here. I'm in Houston.
If you get to read this, it means that MY version of Honey was
able to put up with me and with a computing instrument other
than a Macintosh for long enough to create your newsletter.
She did it while I was screaming into the phone at her ("no, not
THAT button! The OTHER button!"), so please be forgiving if the
result is less than stellar.
Let me apologize in advance, though, if something you sent me
didn't get into the newsletter. She's doing a good job, but
fixing batch files and (more to the point) reformatting stuff
that MAKENEWS doesn't like is not her cup of tea. It will be
published next week.
All my best from (deep in the heart of) Texas,
Vince
-----------------------------------------------------------------
FidoNews 8-17 Page 2 29 Apr 1991
=================================================================
ARTICLES
=================================================================
Coordinator Elections in Zone-4
Elecciones de Coordinador en la Zona-4
Eleicoes de Coordenador na Zona-4
Next May 12th, Zone-4 Latin America will celebrate its second
birthday. I think this time is appropriate for me to resign as
Zone Coordinator and call for new elections to choose my
successor.
The process of election of the new Zone-4 Coordinator will be
identical to the one held in November 9th, 1990 in which I
was re-elected.
The procedures defined for the democratic election process are
the following:
- All the FidoNet members will be able to present themselves as
candidates to the zone coordinator position, by sending netmail
to Elecciones at node 4:4/444 until May 10th.
- On May 11th, the list of all candidates will be published
on the official echomail conference LATIN.SYSOP and on May 13th,
on NotiFido, the official Zone-4 sysops' electronic newsletter.
From then until the voting closes on May 31st, the candidates
will be able to debate ideas on the LATIN.SYSOP echo, as well
as on the other region and local sysops' echomail conferences.
- From May 11th until May 31st, all the members of FidoNet Zone 4
will be able to vote for their preferred candidate -voting for
someone that is not a candidate will void the ballot- for Zone
Coordinator. They will do so by sending a message to Elecciones
at node 4:4/444 (region-routing will be enabled to reduce the
cost of voting), whose subject will be a special "secret
password" and the text will indicate the sysop's choice. THE
VOTE IS SECRET, AND ITS CONTAINTS WILL NEVER BE REVEALED. This is
an example of how a ballot must be issued:
secret password
From: Jose Corzo Gomez (4:900/789) |
To: Elecciones (4:4/444) |
Subj: guantelimpio <---------------| text
|
ZC: Roque Santeiro <--------------------|
- The results from the election will be published on June 2nd
on the official echomail conference LATIN.SYSOP and on June 3rd
on NotiFido and FidoNews. A comprehensive list with every ballot
listed, to grant the accurateness of the results, will be posted
on June 2nd on the echomail conference LATIN.SYSOP. This is
an example of how a ballot will be published in the comprehensive
list:
FidoNews 8-17 Page 3 29 Apr 1991
Password ZC Status
------------------------------------------------
guantelimpio R.Santeiro OK(*)
(*) Will say "VOID" if the ballot is not correct
- The candidate with more votes will become the newly elected
Zone Coordinator and will take over his/her new position as
arranged with the current ZC.
Pablo Kleinman
Latin American FidoNet Coordinator
Buenos Aires, April 23, 1991
-----------------------------------------------------------------
FidoNews 8-17 Page 4 29 Apr 1991
Looking for (Artificial) Intelligence
Bill Keller 1:129/124.0
I guess I should begin this article by introducing myself
and stating my reasons for submitting this article.
My name is Bill Keller and I run a bbs called ShadeTree in
Pittsburgh, PA 15221 (412-244-9416). ShadeTree is
oriented solely towards artificial intelligence (AI).
Mostly, the people who log on are beginners or amatuers,
but they are all enthusiasts.
I originally got into AI by way of a "free" magazine.
I'm sure you've all received these type of offers, "Try our
magazine, the first issue for FREE, if you don't like it,
mark "cancel" on the invoice and send it back, there will
be no further obligation on your part". Sometimes, I felt
almost criminal (notice I said "almost") but it is a good
way to take a look at a new magazine before deciding to
subscribe. Anyway, the magazine ad I answered was one for
PC AI, one of the two big AI related magazines. The issue
I received was one of their first on neural nets.
Immediately, I was HOOKED!!
I started to look around for an inexpensive way to get
started in AI. What I found was over priced, over
complicated, over hyped programs. Knowing the computer
community, I figured that SOMEWHERE, there had to be either
shareware or public domain programs available to help me
get started. The quest started!
What I found was more than a little disheartening. There
was VERY little of either type of software out there. Oh,
I managed to locate a few expert system shells here and
there, and some other miscellaneous files, but there was no
CENTRAL place I could go to find the latest release of a
shareware program or a new public domain program that had
just been released or that maintained a large library of AI
oriented programs and files. It was at that point I
conceived of ShadeTree.
I had been using bbs's for several years, not a lot (I knew
from experience how addicting it can be!) but enough to have
a very general idea how it worked. One of the local Pgh
SysOps helped me get started with OPUS (a GREAT piece of
software) and to get my mail and echos set up. At this
point, I started searching very seriously.
There's the back ground, now for the reason or more
correctly, the request.
FidoNews 8-17 Page 5 29 Apr 1991
I am asking all the SysOps and users who read this
newsletter, to provide me with the following information:
1. What is your FIDONet address and any particulars about
your bbs, max baud rate, phone number, hours of
operation, city, state and zip code (no addresses unless
you want to provide it but with just the city and zip
code, many people will be able to tell how close they
are to your board), with this info I intend to compile
and distribute a file containing a list of boards
carrying the various AI related echos so that people
can find a bbs close to them
2. Do you participate in any other networks and if so,
which ones and what AI related echos are available on
that network, for example the RIME network, or RBBS,
etc
2. What FIDONet "backbone" AI related echos are you
receiving? (The only ones I am aware of are AI,
NEURAL_NET, ROBOTIX, if you are aware of any others,
please let me know)
3. What "local" AI echos do you have on your board and is
there a possibility of that echo becoming a "backbone"
echo or would you consider some alternative method of
allowing users from all over access to your echo
4. What AI related files do you currently have on your
board, please give the program name, author name,
version number, size in kb, and a brief description if
possible, I am interested in both text files, program
files, descriptive files, tutorial files, data files,
etc
5. Any of the following topics would be considered AI
(although some by only very loose standards):
Expert systems / inference engines
Neural nets / neural modeling
Problem solving
Natural language processing
Machine vision
Pattern processing
Decision analysis
Robotics
Machine learning / understanding
Logic and uncertainty / fuzzy logic
Genetic algorithms
LISP and all it's dialects
PROLOG and all it's dialects
SmallTalk and all it's dialects
Hypertext
Speech recognition
Speech to text translation and vice versa
This list should cover most of the major areas of
interest in AI but if you have a file that you're not sure
of, better to let me know than to not include it.
FidoNews 8-17 Page 6 29 Apr 1991
What I intend to do is start a consolidated repository of
AI related materials and keep them as up to date as
possible. This can only be accomplished with the help of
the network and the individual's willingness to contribute
a little time to initially get the project off the ground.
Evenutally, I hope to automate the process as much as
possible (after all, isn't that what computers are for?) and
use some sort of database to track version numbers and
releases, etc.
I can be reached at either my FIDONet address, 1:129/124.0
or via the U. S. Mail at:
ShadeTree BBS
c/o Bill Keller
417 Peebles Street
Pittsburgh, PA 15221
At this time, ShadeTree is only running from 8:30 PM until
8:30 AM and only at a maximum of 2400 buad. That is
another reason to suggest the regular mail as an
alternative.
I would like to thank you all, in advance of any assistance
rendered, for your help and participation in this project.
Bill Keller
-----------------------------------------------------------------
FidoNews 8-17 Page 7 29 Apr 1991
Garth Kidd
3:680/828@fidonet
[email protected]
Ages ago, I posted a few articles about POLICY, WorldPOL, and
whether Z3 should throw some kind of revolution and crawl out
from under Z1's wing.
This is *nothing* to do with them :-)
Well, ok, it is. It's also rather different. This is partially
because I'm talking about a few different items. The fact that
some rather nice people took the time to debate a couple of
issues with me probably helped, too. Thanks, guys. You know who
you are.
I digress.
===
AutoNews sounds interesting, Vince. Make sure you put in
something that'll flag suspiciously large articles, though. I can
just imagine some twit sending you 40k of ^g.
===
Bob, I like the idea. The main problem is that your proposal is
HUGE. It'd be really nice if you trimmed it down to something the
average human being couls sit down with, read and comprehend
within an hour or two. [Ideally, we should be able to reduce it
to "Act Sensibly" :-)]
I would have tried to make suggestions and comments on your
proposal, but it was simply too large to deal with. Apologies.
===
Alexander, the main problem with passing the ambiguity buck to
the ZCs is that it's exactly that -- passing the buck. Why not
correct the problems once now, rather than have to do it in each
Zone (or Region, or Net, or...)
===
Mike, just a point:
> WorldPol would have made it much easier to fix. WorldPol
> would have given the *Cs more reason to be responsive to
> the valid needs of a sysop.
FidoNews 8-17 Page 8 29 Apr 1991
To be a member of the *C structure, you need to have a fair bit
of time, expertise, and equipment you're willing to donate to the
cause. Unfortunately, there aren't a huge number of people who
have all the necessary elements handy. The result is a very small
number of people to choose from when having an election.
Now, when your city has an election, there are a huge number of
people who'd like to be the Mayor, and who have the necessary
equipment (that is, they're a citizen with spare time). This
means that you *can* pressure your Mayor with the threat of being
voted out next time 'round, because there are people available to
fill their place.
You can't so easily discard a *C. First, you have to find someone
with the technical nouse and spare time that's willing to take on
the job, and that's going to be fairly difficult in a lot of
places. It seems to me that a lot of *C's are going to be fairly
safe. Ergo, they're not going to be terribly more responsive.
===
Don, I couldn't agree more. For those who missed what he said,
here's perhaps the most important bit:
> In sum, I think that WorldPol could probably be reduced
> to a third of the current size, and we would end up with
> a smaller, more effective document. Take a few moments
> and look at WorldPol again. Ask yourself if each section
> is absolutely necessary to be controlled at the inter-
> national level? If not, why include it?
===
Dick, I know the feeling. Something's not working quite right. As
for the BOMBRUN kludge -- I like it! Take it to NET_DEV and see
how people react to it. I'd have a bash, but due to a feed
interruption of a strange nature [Paul, I'll netmail you as soon
as I've got the time and inclination, but I'll condense: your
netmail on the matter *NEVER REACHED ME*, reasons unknown :-(] I
won't be able to.
Main problem: too much exception handling :-) Also, until people
catch on to installing session passwords for anyone they connect
to on a regular basis, there's the potential for people to insert
fake BOMBRUN messages, which would be a Bad Thing.
===
Finally, Jack. Incidentally, yours was the article that prompted
me to start this multiple reply in the first place.
FidoNews 8-17 Page 9 29 Apr 1991
Agreed, we need to get some new software up and running, quick.
Correct me if I'm wrong, but it seems that this won't be able to
be quickly grafted on at the mail processor level, unfortunately
-- we'll need a couple of sneaky changes to the mailers
themselves (domain-style addressing, here we come! :-), and some
change to BBS software to handle the new-fangled ideas of fully
moderated conferences [*] and conference hierachies.
Unfortunately, even if you manage to implement a decent
replacement [**], you'll still have to get people to switch to it.
You don't need me to tell you that this isn't going to be the
easiest thing to accomplish.
> Trouble is, it seems that all the topics I am
> interested in fall into one of three categories: 1)
> There's no echo covering it, 2) There's an echo
> covering it but it's a dead (or nearly dead) echo, 3)
> There's an echo covering it but it's so large and has
> so many off-topic or "useless" messages that I just
> don't have the time to keep up with it.
Is there anyone here who *doesn't* have that feeling?
I like the method the USEnet uses to cope.
[Warning: this is from what I've seen only. I may have been
temporarily visually challenged at the time].
You have the comp.* groups, and various other "official"
conference trees. To create a new group in here requires a lot of
discussion and manoeuvering.
You also have the alt.* tree, in which you create a conference by
posting a message to it. All the systems who have the alt.* tree
enabled [***] [****] will get it, until they turn it off. I think
the software also automatically kills conferences that have been
dead for a sufficiently long time.
Just excuse me whilst I catch up on my footnotes.
===
[* Note to people who think that fully-moderated conferences mean
double the throughput: this is the case only if you're directly
between the moderator and the rest of the world, and the
moderator isn't all that choosy. For people at the far reaches,
the difference would be negligible, and probably advantageous.]
[** Even this is going to be near impossible. I was one of the
participants in a rather active discussion in NET_DEV about
potential Fido/3 technology. Unfortunately, I've suffered from a
"minor" feed cut. Ironically, one of the contributing factors
(apart from a rather badly timed and \extremely\ badly placed
argument I had with someone) was that transmission failures meant
that netmail and echomail warnings on the matter simply didn't
make it to my system.]
FidoNews 8-17 Page 10 29 Apr 1991
[*** Apart, that is, from the people who've disabled the part of
the tree you're in. Example: to create alt.swedish would be fine
as long as people didn't have it already in their kill file. Now,
creating alt.swedish.chef would be ok, but systems who'd already
turned off alt.swedish would never see the new subconference.
swedish.chef.bork.bork.bork would be for the true diehards :-) Oh
yeah; some people save lots of time and just kill alt.*]
[*** Apologies for all of these footnotes. I can't seem to get my
text in order these days.]
===
> But will our software authors ever be able to agree on
> any new standard that might be proposed along these
> lines?
I think not. At least, not in NET_DEV, from what I'd seen just
before I left. At the time the feed bottomed out, people were
still debating whether a timestamp should be stored as seconds
since 1970, a 32-bit bitmapped struct, plaintext, ISO, and if
anything remotely binary, which wordsex to use :-(
There is one way in which I think it could all be accomplished.
Unfortunately, it doesn't leave much of Fido standing :-(. Since
a change would be extremely difficult to orchestrate piecemeal,
it seems vaguely reasonable to start a new network with the new
technology and let it gradually "eat" FidoNet, gating the major
conferences and so on. Can anyone think of a better method?
Please?
That'll do for today. Have a nice day, all.
gk
-----------------------------------------------------------------
FidoNews 8-17 Page 11 29 Apr 1991
Jack Decker
1:154/8 Fidonet
YOUR DOG WALKS ON WATER?!?
Well, last week I tried out the AutoNews program that Vince
uses, by sending an article via netmail. It worked, but it
threw out the blank spaces that I had left between paragraphs.
I think that may have happened because my message editor only
put a single <CR> after each line, no <LF>'s anywhere, so this
week I'll try manually creating the message to make sure that
each line terminates with a CR/LF and see if that helps. In
the meantime, Vince, you may want to see if AutoNews recognizes
two <CR>'s in a row as a blank line. However, for a first
attempt, the program worked admirably. [I spoke to the author
and he thanks you, both for your kind comments and for your
assistance in getting everything straightened out -- Vince]
Besides, I did want to make one little comment on Vince's
Editorial in FidoNews 8-16. In Vince's reply to Pablo
Kleinman, we see the following exchange:
[Begin quote:]
> I want to believe that Jack Decker's last article is really
> pessimistic and not the harsh reality of our network.
It's sort of redundant to call Jack a pessimist.
Can you see this?
Jack goes hunting with you. You shoot a duck. Your dog goes
after the duck. When it reaches the water, your dog walks on
top of the water, never even leaving a ripple. The dog gets the
duck and brings it back to you. Jack says nothing. This happens
twice more. You finally ask Jack if he has noticed anything
unusual. Jack says, "Yeah. Your dog can't swim."
[End quote]
What strikes me as amusing about this is that the other day I
happened to have the radio on when Rush Limbaugh was on, and he
made a comment to the effect that when liberals run out of
substance, they start in with personal attacks (for those
outside of the U.S.A., Rush Limbaugh is a conservative radio
talk show host that is carried on well over 300 radio stations
in the U.S. for three hours a day, and who is most noted for
having an ego about the size of the planet Jupiter). Anyway, I
thinks to myself, that sounds a lot like Fidonet... when they
can't assail the logic of what you have to say, they start in
with the personal smears.
FidoNews 8-17 Page 12 29 Apr 1991
Actually, I realize that my messages may, if taken out of
context, sound a bit pessimistic. What I see is that we have a
potentially wonderful communications medium here... one that
allows people from all corners of the earth to converse with
each other with reasonable speed and at fairly low cost. Yet
there are problems and in some cases they need to be quantified
and solutions need to be found.
Consider what would have happened if the Ford Motor Company,
after having come out with the Model "T" had said "Now, you
folks have something that is better than the horse, and you can
afford to buy it, so you should be grateful and not ask for
anything more." Actually, from what I've read, that was
EXACTLY the attitude of some in that company (I believe it was
Henry Ford who said "they can have any color they want, as long
as it's black!"). Would anyone doubt that we are better off
now because some folks looked at the Model "T" and dared to say
"it's wonderful, but it can be improved upon"?
So it is with Fidonet... it is wonderful, but it can be
improved upon.
I have felt, and expressed on many occasions, that there are
about four basic things wrong with Fidonet:
First, it is too politically motivated. What folks like Vince
and some others seem to have a hard time grasping is that there
ARE people in the world who seek to acquire any sort of power
over others that they can get, and since there are only so many
countries in the world, not all of them can aspire to be world
dictators. Some will try and manipulate their way to the top
of the office political structure at their place of employment,
others will try and rise to the top of a local service club,
charitable organization, or political group, and still others
will try to cling to the top spot of a hobbyist group. Some of
these folks get into Fidonet and do manage to get a *C spot and
once they get there, they will oppose any policy change that
might lessen their supposed power. I think those who have
trouble understanding this have simply never been in an
organization where one person has clawed their way to the top
and then manipulated people like crazy to keep the top spot. I
have, and I can tell you that it's no fun to see an
organization disintegrate because the top person is driving
everyone away.
Second, it makes a god (small "g") out of geography. This is
out and out idiocy, when referring to an electronic network
(no, Vince, I can't vote in Duluth when I live in Sault Ste.
Marie... but Fidonet isn't providing my water, fixing my
streets, or regulating the zoning around my home. You can't
compare physical structures to a structure that can quite
reasonably exist in a configuration that pays little regard to
geography). (Side note to Pablo... no, I truly believe that
MOST common sysops in Zone 1 DON'T want geographic
restrictions... and that is EXACTLY why a few are so opposed to
WorldPol, because they will lose their enforced power base.
FidoNews 8-17 Page 13 29 Apr 1991
They know that if common sysops are given a vote on a Zone-wide
policy, they'll never vote for one that contains geographic
restrictions, and that scares a few of them to death).
Third, it is getting technically stagnant... Fidonet is SO
large that we find that we're unable to refine the system to
get rid of SEENBY's in messages, have true 5D addressing
instead of endless kludge lines, have truly moderated
conferences so that the signal-to-noise ratio of conferences
can be improved, communicate with the ubiquitous FAX machines
around us, enter non-text data in messages, and any of a
hundred other improvements that WILL come in time. Just as the
Model "T" owner might never have dreamed of having air
conditioning, a stereo audio system and cruise control, so we
can't imagine what future online communicators will be able to
do. The question is, will these advances come from within
Fidonet, or will those who want something better be forced into
other networks? And if the latter happens, will those in
Fidonet then stubbornly snub them and ignore what they're
accomplishing?
Fourth, it is intolerant of certain political viewpoints.
Vince at one point raised the specter of a "whites only" net
run by the KKK. Well, far be it from me to defend that group,
since I find their ideas repugnant, but since you're so
concerned about law, Vince, you ought to ask your lawyer
friends about the "slippery slope" principle. Basically, it
says that if you can deny any one group the right to be heard
(or, in this case, to freely associate) then you have set up a
principle that can be used against ANY group. So suppose you
write something into Policy that says that special interest
nets cannot be formed... not only are you attempting to
unreasonably limit freedom of association for no real good
reason, but any such policy could be used against groups you
might happen to AGREE with. Not only that, but you haven't
really stopped the subversive groups from operating - it is
very easy to set up and operate a private net using Fidonet
technology, that is totally invisible to Fidonet as a whole -
so now you've driven them underground where their activities
can't be monitored, and where they're less likely to be
influenced by those in the larger net that might be able to
explain to them and convince them of the error of their ways.
In the meantime, is it right to let our fear of extremist
groups cause us to set up a mechanism whereby those who hold
political viewpoints we find simply disagreeable may be
harassed or excluded?
I'm hoping for better things from Fidonet... but it's not going
to happen as long as we operate as though all that HAS been
achieved is all that CAN be achieved. We've come through the
Model "T" stage, but there are a lot of improvements that can
be made, both in the technology and the political structure of
Fidonet (and hopefully we can avoid the tailfins!).
FidoNews 8-17 Page 14 29 Apr 1991
*****
A couple of other notes only semi-related to the above: First,
Pablo mentioned Jason Steck, who was at one point working on
another Policy document. My impression is that Jason has
decided that his time would be better spent working in
MetroNet, an alternative Fidonet-technology network that's a
bit unique in some ways. For example, Jason tells me that they
have their own UseNet-MetroNet gateway and are the only
Fidonet-technology network other than Fidonet itself to have a
registered domain in the Internet (I hope I'm stating this
correctly, I'm repeating this from my memory of a phone
conversation). Also, I gather that the MetroNet folks are
working on a practical implementation of a new packet type that
will be backward compatible with existing Fidonet technology,
but that will offer several of the innovations that have been
suggested in various forums from time to time. In any event,
if you are interested in furthering the technology and are
running into roadblocks (political or otherwise) in Fidonet,
you might contact Jason Steck at Fidonet 1:104/424 and see what
they're up to (however, if you're the typical NET_DEV type that
like to argue about formats, structures, etc. ad nauseum but
never gets around to writing a line of code, don't bother... I
don't think they either need or want those types around!).
Second, I have to wonder why some of the sysops who believe in
carrying political discussions that cover all sides of the
political spectrum haven't asked for some political echoes to
balance out some of the echoes that are already carried.
Please consider that there are plenty of "issues oriented"
echoes such as ABORTION, ANIMAL_RIGHTS, BEYOND_WAR, ECOLOGY,
ECONET, ENVIRO, ENVIRON, FEMINISM, GAYLINK, GAYNEWS, ICGAL,
INDIAN_AFFAIRS ... and on and on, and if you understand the
difference between the political right and the political left,
you can easily see that Fidonet is pretty one sided (not
necessarily from the TITLES of some of the echoes, but from
their content). Now maybe this is intentional, but I certainly
hope not. So I'd like to suggest that maybe we should think
about having some echoes that might bring more of a political
balance to Fidonet. Here are some ideas I've had, you might
think of more:
EDU_CHOICE - For those who support the idea of parental choice
in education, and would like to discuss the reasons for it and
the ways in which it could be implemented.
PEOPLE_FIRST - An echo to keep track of and expose the
activities and motives of some of the fringe groups that
believe that humanity is a cancer on the planet (such as the
groups that believe that animal research is never justified,
even if it means we never find a cure for AIDS, etc.). In
other words, to count the cost to people and society if some of
the goals of the far left groups are achieved, without
necessarily having to rely upon their statistics.
FidoNews 8-17 Page 15 29 Apr 1991
DITTOS - an echo for listeners and fans of the Rush Limbaugh
radio talk show, for further discussion of issues that have
been raised on that program. Those who've heard the program
will recognize the significance of the tag. If we can have
echoes for fans of "Star Trek", why not one for fans of a
popular talk show host? (by the way, in case you're wondering,
no I do NOT agree with everything he says... but it's certainly
an INTERESTING show to listen to, when I get the chance).
My point is that if we are going to carry issue-oriented
political echoes, let's have them cover the whole political
spectrum and not be quite so one-sided. There ARE two (or
more) sides to most issues, after all.
Well, that's enough for one week. Let's see if Autonews eats
the blank lines in this article! [It did. I did a quick once-over
to put at least some of them back -- Vince]
--- via AutoNews 0.1
-----------------------------------------------------------------
FidoNews 8-17 Page 16 29 Apr 1991
"Ramblings of a Dictatorial Megalomaniac"
or "It's about time for Policy6, Godammit"
Luke Kolin, NC250
1:250/714@fidonet
"I thought it sucked, but Wayne here thought it sucked donkeys."
-- Dana Carvey, playing Garth on SNL's "Wayne's World"
Garth may be talking about movie reviews, but perhaps Worldpol
is also appropriate in this case. As a Zone 1 *C, I've been quite
offended by the rhetoric that's been floating around regarding
WorldPol, and I feel that it's time that I speak my two bits'
worth.
Before I begin, I want to state for the record that regardless
of wether WorldPol passes or fails, we will be planting the seeds
for future discontent within FidoNet. If it fails, it will be
widely perceived as yet another example of Zone 1 imposing its
will upon FidoNet. If it passes, it will be further proof that
the largest group of FidoNet sysops have been effectively disen-
franchised by a gerrymandered voting system. Net 250 is larger
than quite a few regions, but while they may have 2 to 4 votes,
we only have one. Is that fair?
So I think it's time to look beyond WorldPol. Because if we look
upon this vote as the be-all and end-all, there will be a lot of
po'd people in FidoNet. We got that with Policy4, and what came
out of that was Policy5, aka WorldPol. Documents created out of
resentment and frustration are inherently flawed, and unless we
look beyond WorldPol NOW, Policy6 will end up the same way.
For the record, I voted against WorldPol. I don't support making
a completely new policy. I believe that Policy4 can do the job,
with ammendments. Why start from scratch when we have the cumula-
tive efforts of many man-years lying around, only to be modified
as needed? Therefore, I support a Policy6 based on Policy4, with
the following fundamental changes. Call them a Sysop's Bill of
Rights.
o DEMOCRATIC ELECTION OF THE *C STRUCTURE. FidoNet's a hobby. Or
a club. And it only stands to reason that FidoNet sysops should
be able to choose their representatives. Therefore, Policy4 should
be ammended to ensure that NCs and RCs are elected by a vote of
all sysops within their respective Net/Region. ZCs will be elected
by a vote of all *Cs within their Zone.
o GEOGRAPHICAL NETWORK BOUNDARIES. Within Region 12, we have been
attempting to institute strict geographic boundaries for networks.
For people to say in FidoNews that geographic boundaries force
people to deal with bad *Cs is a blatant insult to the efforts of
the NCs and RCs of Region 12 since 1988. Allowing nodes to join
any network they wish only encourages the rise of cliques, and
networks based on politics and infighting. It encourages NCs to
discriminate on who they wish to accept into "their" Nets. If we
FidoNews 8-17 Page 17 29 Apr 1991
make georgraphy the sole criterion for network membership, we
make sure that FidoNet is accessible to all. Equally. If an NC
cannot live with that, he should be axed immediately.
o FIDONET IS FREE. Several previous articles in FidoNews have
mentioned several networks who charge an admissions fee to join.
No node should be forced to pay to join or remain in FidoNet, nor
should they be forced to pay for any mandatory echo conferences.
We are an amatuer network, accessible to all at least at a basic
level. That should be a fundamental right.
o A NEW AMMENDING FORMULA. There's a problem with the way FidoNet
is structured right now. Zone 1 has a grand total of ten regions
and six thousand people, while Zones 4 and 5 have regions that
are hard pressed to qualify as networks up here. So why should
they have the same voting rights? I think it's time for an
ammending formula that protects both minorities in FidoNet: a
minority of sysops outside Zone 1, and a minority of *C beings
inside Zone 1.
Let's keep the method of putting ammendments up for vote the
same. A lot of RCs are good people who'll support a vote even
if they are going to vote NO. However, when it comes down to the
actual vote, why don't we say that to pass, a policy must meet
with the approval of a majority of *Cs in each zone. To boot,
the NCs' votes must represent a majority of sysops in that zone.
That way, policies cannot be passed by the simple virtue that
one zone has a plethora of tiny zones.
So let's drop WorldPol. It reeks of an atitude saying, "Let's
make sure Zone 1 never screws us over again." Let's go back to
the time-honored method of taking what we have, and improving
it, to make something even better.
I also support the idea of condensing policy. For example, in
Net 250 I have published a little 2K guide to FidoNet. I don't
see why we should force all sysops to read the entire policy
document, when most of the time a little guide will do. To this
end, I propose two versions of Policy6. The first would be a
very short explanation of FidoNet to the new sysop, and the
second could be as large as you want. Since most sysops will
never read the second, it can be *C-oriented, taking into
account all facets of FidoNet. Rather than taking about demo-
cratic elections according to "western standards", let's write
a full elections policy. We have. Rather than making provisions
for zonal, regional, or network policies, let's just make one
broad-based one. If you follow the basic principles in it, and
the few specifics (like elections), the other stuff is up to
you.
WorldPol must fail. Much bitterness will be aroused pass or
fail, but I'd rather be bitter that a flawed document did not
pass. Let's start with Policy4 again, change it to reflect the
new FidoNet, and live with that.
FidoNews 8-17 Page 18 29 Apr 1991
-----------------------------------------------------------------
FidoNews 8-17 Page 19 29 Apr 1991
Tony Davis
Z1EC 1:1/200
After the first month of performing the duties of Zone One
Echomail Coordinator, I felt some information on how the system
is progressing was in order.
The first month has been extremely interesting. In the first 30
days, I have received in excess of 200 netmail messages
concerning policies, procedures, complaints, suggestions, adding
an echo to the backbone, removing an echo to the backbone,
moderators requesting links be cut, users requesting moderators
be replaced, etc. Very few (less then 5) actually concerned with
coordination of traffic flow.
One fact became the extremely clear. That was that in the
absence of a recognized, approved echo policy and no other
documentation; that I would be subject to making many judgement
calls. The only mathematical certainty is that if many judgement
calls are made, some will be incorrect. In an effort to remove
myself from the position of judge, jury, and executioner that
the numerous requests asked me to be and place me in the
position of administrator that I was elected to, I contacted all
the RECs and asked their guidance of exactly how they wanted me
to handle the position.
The general opinion that came from these discussions was that
the *EC structure did not have the right to dictate a mandatory
Echo Policy. It also became obvious that even if we could not
set a zone wide policy, that a document that described the
operation of the backbone, and explained to the general sysop
exactly what they could expect from the backbone was necessary.
A set of backbone procedures was written, and put up to a vote
of all RECs. The procedure were adopted by an absolute majority
of current RECs.
The document prepared is not intended to be a general echo
policy, it is designed as an informational document to explain
the self-imposed rules the Zone One Backbone will operate under.
If at any time, the net does adopt a general echo policy, the
net approved policy will either replace this Backbone Operation
Procedure document or changes in the document will be made for
it to comply with the general echomail policy.
The document lays out specific requirements that an echo must
meet in order for it to be distributed by the backbone, on the
balance side, it also lays out exactly how to remove the echo
from any restrictions the moderator of an echo feels the
backbone places on him (or her).
FidoNews 8-17 Page 20 29 Apr 1991
Any one that disagrees with any segment of that document, and
would like to see a change, deletion, or addition, please
contact your REC. The document itself was designed to be a
"living" document, and changes may be made to it quickly and
easily. The procedures to initiate changes are described in the
document itself.
One side note: The document was not authored by the ZEC, it is a
collection of parts supplied by different RECs. As ZEC, I
accepted the mandate of the RECs to implement the document.
Respectfully,
Tony Davis Z1EC
ZONE ONE BACKBONE OPERATION PROCEDURES
Revision: 1.01 Effective Date: May 1, 1991
PROLOGUE
This document sets forth procedures followed by the Zone One
Backbone Echomail System.
If any item in this document are in conflict with any existing
or subsequent General Fidonet Policy, then General Fidonet
Policy will be in effect.
This document addresses echomail at the zone level. It is not a
General Echomail Policy. This document makes no attempt to
address any issues below the "Backbone Level".
I. HISTORY
Echomail consists of the sharing of message bases or conferences
between various independent network addresses. The echomail
concept started with a series of programs by Jeff Rush. Since
the original implementation, many authors have written programs
improving on the original idea. In spite of worries that the
flow of echomail would increase netmail traffic to the point
that the network would collapse under its own weight, echomail
has been a success.
To simplify the distribution of echomail at the zone level, the
Backbone was formed. As a result of the growth of Fidonet and
the increase in the volume of echomail, it has become necessary
to set forth operational procedures to allow the general Fidonet
sysop to know what services he can expect from the Backbone.
FidoNews 8-17 Page 21 29 Apr 1991
II. DEFINITIONS
1. GENERAL FIDONET POLICY: The document which governs Fidonet
as adopted by Fidonet. The document as of this writing is
Policy 4 and is subject to change.
2. NODE: A Fidonet member, as per General Fidonet Policy.
3. ECHOMAIL: A form of mail in which message bases are shared
between independent systems with unique Net/Node addresses.
4. ECHOMAIL CONFERENCES: An echomail conference is a message
base or forum, distributed under a specified echomail conference
name, dealing with a defined area of interest. Echomail
conferences are hereafter referred to simply as conferences.
Examples include COMM, an inter-zone telecommunications
conference, and POLITICS, a zone level political conference.
5. ZONE ECHOMAIL COORDINATOR: This individual is responsible
for coordination of echomail at the zone level. The Zone
Echomail Coordinator is hereafter referred to simply as the ZEC.
6. REGION ECHOMAIL COORDINATOR: This individual is responsible
for coordination of echomail at the region level. The Region
Echomail Coordinator is hereafter referred to simply as the REC.
7. NET ECHOMAIL COORDINATOR: This individual is responsible
for coordination of echomail at the net level. The Net Echomail
Coordinator is hereafter referred to simply as the NEC.
8. ECHOMAIL HUBS: These are nodes who distribute echomail.
The Echomail Hubs are hereafter referred to simply as Hubs. The
Zone Hubs distribute echomail at the zone level. The Region
Hubs distribute echomail at the region level. The Net Hubs
distribute echomail at the net level.
9. CONFERENCE MODERATORS: These individuals preside over
conferences. Conference Moderators are hereafter referred to
simply as Moderators.
10. RESTRICTED DISTRIBUTION CONFERENCE: A restricted
distribution conference is one which is restricted only to
eligible recipients. Examples include MODERATOR, a pre-register
conference for Moderators, and MEADOW, a conference for Opus
Sysops.
11. ZONE ONE ECHOMAIL BACKBONE: The Zone One Echomail Backbone
consists of Zone Hubs (commonly referred to as "Stars") and the
Regional Hubs (who directly connect to the "Stars"). The Zone
One Echomail Backbone is hereafter referred to simply as the
Backbone.
FidoNews 8-17 Page 22 29 Apr 1991
12. ZONE ONE ECHOMAIL CONFERENCE LIST: The Zone One Echomail
Conference List identifies the registered zone level
conferences. The Zone One Echomail Conference List is hereafter
referred to simply as the Echolist.
13. ZONE ONE ECHOMAIL CONFERENCE LIST COORDINATOR: This
individual is responsible for the Zone One Echomail Conference
List. The Zone One Echomail Conference List Coordinator is
hereafter referred to simply as the Zone Echolist Coordinator.
14. ECHOMAIL GATEWAYS: These are nodes whose systems are used
to exchange mail with other groups. The term Echomail Gateway,
as used hereafter, shall include all forms of gating, including,
but not limited to, zone-gating, inter-network gating, and
domain-gating.
15. VOTE: Any vote shall be carried out in a fair and decent
manner. A good faith attempt shall be made to make all eligible
voters aware that a vote is about to occur and to make available
all necessary information. At a minimum, this notice shall be
posted in the REC conference 7 days prior to the start of the
voting period. The voting period shall be 7 days.
16. ABSOLUTE MAJORITY: The term absolute majority means more
than 50 percent of those eligible to vote.
III. DUTIES OF ZONE ECHOMAIL COORDINATOR, ZONE HUBS, ZONE
ECHOLIST COORDINATOR, REGIONAL COORDINATORS AND MODERATORS
1. DUTIES OF ZONE ECHOMAIL COORDINATOR: The ZEC shall
coordinate echomail distribution at the zone level. This
includes coordinating the transmission and routing of echomail
so that it is done in a manner so as to avoid creation of
duplicate messages within a conference.
The ZEC shall make available, to any region, any conference
which that region is eligible to receive. If for any reason the
ZEC does not have access via recognized distribution channels to
a specific conference, he can not be expected to provide it.
An exception is that the ZEC is not required to make available
any conference which routinely contains messages which are
encrypted or illegal.
Nothing in this provision requires that a ZEC or Zone Hub must
import any conference to the extent of adverse economic impact.
The ZEC shall recognize conferences at the zone level. The ZEC
shall maintain a list of available conferences at the zone level
as well as the requirements of each conference as supplied by
the Moderator (Echolist).
FidoNews 8-17 Page 23 29 Apr 1991
The ZEC shall appoint Zone Hubs (Stars) to distribute echomail
at the zone level. The ZEC may also serve as a Zone Hub, but is
not required to do so.
The ZEC shall make available a minimum of one connection to each
"Star", to each region. Each Region is not required to use all
available connections, but it is the ZEC's responsibility to
insure that the connections are available.
2. DUTIES OF ZONE HUBS: All systems designated as Zone Hubs
(Stars) by the ZEC will be required to allow a single direct
connection from each region as requested by the REC of each
region. Zone Hubs may act as Regional Hubs and/or File
Distribution systems only if such actions do not interfere with
the primary duties of Zone Echomail Distribution. Zone Hubs
will make any conference available that has been designated a
"Backbone Conference" by the ZEC. Zone Hubs will distribute a
text file named "FIDONET.NA" that is a list of all Conferences
available from the Zone Hubs.
3. DUTIES OF ZONE ECHOLIST COORDINATOR: The Zone Echolist
Coordinator shall compile and make available the Echolist. This
is a registry of zone level and inter-zone conferences, updated
monthly, and optionally, conferences at various other levels.
The content and format of the Echolist will be at the sole
discretion of the Zone Echolist Coordinator, except that it
shall include the conference name, the Moderator's name, a
netmail address listed in a publicly available nodelist of any
network where the Moderator may be reached, a general
description of the conference topic, eligibility requirements
for restricted conferences, network of origin for conferences
which originate outside of Fidonet, distribution plan if other
than via the Backbone, and rules for each conference.
4. DUTIES OF REGIONAL ECHOMAIL COORDINATORS: This Document
details the REC's duties in relationship to the Backbone, only.
The REC shall coordinate echomail distribution at the regional
level. This includes coordinating the transmission and routing
of echomail so that it is done in a manner so as to avoid
creation of duplicate messages within a conference.
The REC shall make available, to any net, any conference which
that net is eligible to receive. If for any reason the REC does
not have access via recognized distribution channels to a
specific conference, he can not be expected to provide it.
An exception is that the REC is not required to make available
any conference which routinely contains messages which are
encrypted or illegal.
FidoNews 8-17 Page 24 29 Apr 1991
Nothing in this provision requires that a REC or Regional Hub
must import any conference to the extent of adverse economic
impact.
The REC shall appoint Regional Hubs to distribute echomail at
the regional level. The REC may also serve as a Regional Hub,
but is not required to do so. The REC designates the systems
that will have the direct connections to the Zone Hubs. In the
event the REC feels his region needs more than one connection
per Zone Hub, he may request an additional connection. Any such
connection will be granted on a space available basis. Each
such request will be looked at on a case-by-case basis.
5. DUTIES OF MODERATORS: Moderators shall make, in good faith,
every reasonable effort to insure that their conferences do not
distribute or promote illegal activities or information as
defined in Section V, Paragraph 2.
Moderators shall publish the conference rules in their
conferences at least once a month.
Moderators shall be responsible for seeing that messages
contained in their conferences correspond to the conference's
theme.
Moderators shall not fail to perform their duties for a period
of more than 10 days without failing to designate proxies.
Moderators are encouraged to appoint Co-Moderators to assist
them in their duties. If the Moderator is not a member of
Fidonet, he must list an address in a publicly available
nodelist of any network, that he may be contacted if the need
arises.
Moderators shall report any violations of these procedures to
the proper Echomail Coordinators and lodge any appropriate
policy complaints as provided for in General Fidonet Policy.
If a Moderator believes that a Node is violating a conference
rule, he may authorize the feed to that Node be severed. This
authorization shall be made in direct written form (netmail), to
the Hub feeding the offending Node, with a copy to the offending
Node.
IV. SELECTION OF ZONE ECHOMAIL COORDINATOR, ZONE ECHOLIST
COORDINATOR AND MODERATORS
1. GRANDFATHER CLAUSE: The ZEC, Zone Echolist Coordinator and
Moderators currently holding these positions as of the date of
acceptance of this document shall continue to serve in said
capacity.
FidoNews 8-17 Page 25 29 Apr 1991
For the purpose of calculating the term of office, such term
will be deemed to have started on the date that this document
goes into effect.
2. SELECTION OF THE ZONE ECHOMAIL COORDINATOR: The ZEC shall
serve for a term of 1 year. He shall be elected as follows:
A) Upon resignation or replacement of the existing ZEC, the
Zone Coordinator (ZC) shall oversee the election of the new
ZEC.
B) After the nominees are selected, an election shall be
held. The ZEC will be elected by a absolute majority of the
RECs.
The current ZEC can be identified from the 1/200 listing in the
Nodelist.
3. REMOVAL OF THE ZEC: The ZEC may be removed from his
position by a absolute majority of the RECs. The ZC will
oversee the recall election in the same manner as prescribed for
electing the ZEC.
The ZEC may only be subject to recall for failure to properly
carry out his duties described above, or if he is no longer a
member of Fidonet. A promise of "free" echomail delivery from
another source is not considered an acceptable reason for
recall.
A ZEC may be removed by the ZC for continued violations of
policy or for gross misconduct.
4. SELECTION OF THE ZONE ECHOLIST COORDINATOR: The ZEC shall
appoint the Zone Echolist Coordinator.
The current Zone Echolist Coordinator can be identified from the
1/201 listing in the Nodelist.
5. SELECTION OF A MODERATOR: A Moderator shall be selected as
follows:
A) Upon formation of a conference, the person who forms the
conference is the Moderator.
B) Upon resignation or replacement of an existing Moderator,
the conference's rules shall define how the new Moderator is
selected.
A Moderator need not be either a sysop, or a member of Fidonet.
A Moderator must have an netmail address in a publicly available
nodelist where netmail concerning the conference may be sent.
FidoNews 8-17 Page 26 29 Apr 1991
V. STATEMENT OF POLICIES
1. BASIC ECHOMAIL POLICY: The basic policy of echomail is to
promote communication in conferences in a lawful, friendly
manner consistent with the general principles of Fidonet.
2. PROHIBITION ON ILLEGAL ACTIVITIES: Knowingly distributing,
or allowing to be entered into conferences, any messages
containing or promoting illegal activities or information, is a
serious violation of this document. As used in this paragraph,
"illegal activities" includes activities which are a violation
of civil law as well as activities which would result in
criminal prosecution.
3. CENSORSHIP: Removing a message from a conference, or
altering its contents, in the passing or distribution of
echomail, is considered a serious violation of this document.
An exception to this provision is the deletion of messages, by
any Node, which may lead to legal action against that Node.
Textual changes to such messages are not allowed.
An additional exception to this provision is the deletion of
messages, by any Node, which do not meet the echomail message
standards in Section V, Paragraph 13. Textual changes to such
messages are not allowed.
Under no circumstances shall echomail be modified in any manner
which could potentially cause duplicates.
4. COUNTERFEIT MESSAGES: Entering or knowingly distributing
counterfeit messages is a serious violation of this document. A
counterfeit message is defined as any message entered using
another person's name, handle or Node address with the intent of
deceiving others about the true author of the message. No
handles shall be used to enter messages to knowingly provoke,
inflame, or upset participants in a conference with the purpose
of deceiving others about the true identity of the author.
5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit
from the passing or distribution of echomail shall be deemed to
be excessively annoying and in violation of General Fidonet
Policy. Profit is defined as the charging for echomail
distribution in excess of the actual cost to obtain and
distribute the echomail over a sustained period. The cost of
the equipment used to obtain and distribute echomail may only be
recovered on a strictly voluntary basis. Nodes who charge users
for access to their BBSs shall not be in violation of this
paragraph.
6. RESTRICTED DISTRIBUTION CONFERENCES: Participating Nodes
shall honor and support the restrictions placed upon restricted
distribution conferences. Violation of this restriction by
individual Nodes is a violation of this document and shall
result in suspension of that Node from the violated echo in
accordance with Section III.
FidoNews 8-17 Page 27 29 Apr 1991
A violation of the restrictions placed on a restricted
distribution conference will be a violation of this document
only if the Moderator has posted the restrictions governing the
conference both in the conference and in the Echolist.
7. PATHLINE OPTION: The PATHline (as defined in FTS-0004), is
recommended for all Nodes, but is required for any node directly
connected to a Zone Hub (Star).
8. SEEN-BY LINE: Under the current technology and topology
(the routing structure of echomail), SEEN-BY lines play an
important part in reducing duplicate messages. Tiny SEEN-BYs
will not be allowed until the ZEC feels that the topology allows
their use. The stripping of SEEN-BYs (except by Echomail
Gateways) is not allowed unless approved by the ZEC. Echomail
Gateways shall strip the SEEN-BYs of the exporting group to
reduce addressing conflicts.
9. ECHOMAIL SOFTWARE: using echomail software which does not
conform to the minimum acceptable standards as defined by the
Fidonet Technical Standards Committee (FTSC), and by this
Section, is a violation of this document.
10. INTER-NETWORK CONFERENCES: It is the general policy of
Fidonet to encourage the development of Inter-Network
Conferences. Inter-Network Conferences shall conform to General
Fidonet Policy, as well as the provisions of this document, in
addition to any foreign network's provisions.
It shall be the duty of those providing the Inter-Network
Conference links to remove foreign network distribution
identifiers which will adversely effect the distribution of the
conference while in Fidonet. The Inter-Network Conference links
maintained in Fidonet shall be operated such that they do not
interfere with the foreign network's distribution of echomail.
Conferences which originate outside of Fidonet must be
designated as such in the Echolist.
Echomail Gateways must be able to pass netmail through the
Gateway into the other network, unless it is technically
impossible to do so.
12. ADDING OR REMOVING CONFERENCES FROM THE BACKBONE: A
conference may be added to the Backbone only at the request of
the Moderator. A conference must have a Moderator, be listed in
the Echolist, and its addition requested by two or more RECs,
before it is added to the Backbone by the ZEC.
The Moderator may, at his discretion, request that his
conference be removed from the Backbone. The ZEC shall honor
such requests.
FidoNews 8-17 Page 28 29 Apr 1991
A conference will be removed from the Backbone when fewer than 2
RECs carry it.
The ZEC may also remove a conference from the Backbone due to
lack of traffic (under 10 messages over a two month period).
A conference is subject to removal from the Backbone when the
Moderator fails to properly carry out his duties, as described
as described in Section III, or violates Section V.
A conference is subject to removal from the Backbone if its
listing in the Echolist is not current.
NOTE: To allow time for all existing Backbone conferences
to be listed in the Echolist, no such conference will be
removed from the Backbone for a grace period of 120 days
from the issuance of this document.
13. ECHOMAIL MESSAGE STANDARDS: Until the adoption of a
superseding standard by the Fidonet Technical Standards
Committee, the following echomail message standards are
recommended:
A) Eight-bit characters (ASCII 128-255) and non-printing
low-order codes (ASCII 2-31) are prohibited, except the use
of 8Dh(soft <CR> character) per FTS-0004. This is not
intended to discourage participation of foreign zones or
networks, which may permit said characters. Any echomail
processor should pass information exactly as it was
received, without stripping any non-standard characters.
B) There should be only one tear line in a message. Tear
lines should be limited to 25 characters including the
required "--- " lead-in. Tear lines should only contain
packer or editor program identification. Tear lines for
message editors are discouraged. If an editor adds a tear
line, it should also add an origin line, to avoid multiple
tear lines.
C) There should be only one origin line in a message, except
as noted in the next paragraph. Origin lines should be
limited to 79 characters including the required " * Origin:
" lead-in and ending of a proper network address (i.e.
Zone:Net/Node.Point with zone and point being optional),
enclosed in parenthesis.
D) "Extra" origin lines are allowed when a message is gated.
The original origin line's lead-in should be changed to " #
Origin: ", and the Echomail Gateway's origin line added.
There may be more than one extra origin line in the case
that a message passes through multiple Echomail Gateways.
FidoNews 8-17 Page 29 29 Apr 1991
The Echomail Gateway's origin line is limited to essential
information only. This consists of the required lead-in,
the network name, "Gateway", a proper Fidonet address (i.e.
Zone:Net/Node with zone being optional), enclosed in
parenthesis. Example: " * Origin: TComm Gateway
(1:372/666)".
E) SEEN-BY addresses should be in sorted order. AKA's are
not allowed in SEEN-BY lines unless you have more than one
address which processes mail. Or for one month during
change of an existing address (to avoid duplicates to the
previous address). Node 0 addresses should not be used for
echomail distribution.
F) All current FTSC specifications must be followed.
14. NETMAIL ROUTING: It is important that users have access to
routed netmail in order to facilitate private replies to
echomail messages. This helps reduce overall echomail message
volume by allowing off-topic replies, flames and other types of
messages which don't belong in the conference, to be sent via
routed netmail.
Until such time as a new General Fidonet Policy is adopted which
defines and codifies the routed netmail scheme, the following
shall be in effect:
A) Zone Hubs and Regional Hubs shall accept routed netmail
from any Node or Hub who exchanges Backbone conferences with
them. Routed netmail may be routed along echomail paths, or
to a ZC, RC, or NC who has agreed to handle such mail. Any
netmail message with a valid Fidonet destination will be
accepted. Refusal of netmail based a non-Fidonet origin
will not be allowed.
B) At the present time, routed netmail is provided by both
the Coordinator and Echo Coordinator structures. The ZEC
shall cooperate with the Coordinators and the Echo
Coordinators in further developing and maintaining a routed
netmail scheme.
16. FEEDING SEVERED NODE: Knowingly feeding a conference to a
Node who has been severed for violations of this document or at
the request of the Moderator, where such feed is intended to
subvert either the provisions of this document or the authority
of the moderator, is considered a serious violation of this
document.
VI. ENFORCEMENT
FidoNews 8-17 Page 30 29 Apr 1991
Enforcement of this document shall be under the provisions of
General Fidonet Policy. Serious violations of these procedures
shall be considered excessively annoying under General Fidonet
Policy.
Complaints concerning violations defined under these procedures
may be filed by the aggrieved individual, the Moderator or by
any level of Echomail Coordinator to the appropriate IC, ZC, RC
or NC level. All complaints made pursuant to this document must
be made within 60 days of the date of occurrence or discovery.
Complaints shall be filed under the provisions of General
Fidonet Policy, with a copy to the ZEC or respective REC, as
appropriate.
Enforcement of these procedures are immediate, with any
currently existing software allowed 90 days to conform (from the
date this document goes into effect). 30 day extensions may be
granted solely at the discretion of the ZEC if efforts to bring
about compliance are clear. Continued use of aberrant software
after this period is a serious violation of this document.
VII. CHANGES
Future changes to these procedures may be proposed by any Node,
by submitting the proposal to any REC. The REC will then
determine if the proposal should be brought before the rest of
the RECs. If two RECs concur with the proposed change, the
change must be brought to a vote of all RECs.
A absolute majority vote of the RECs is required in order for a
change to be implemented.
-----------------------------------------------------------------
FidoNews 8-17 Page 31 29 Apr 1991
=================================================================
LATEST VERSIONS
=================================================================
Latest Software Versions
MS-DOS Systems
--------------
Bulletin Board Software
Name Version Name Version Name Version
DMG 2.93 Phoenix 1.3 TAG 2.5g
Fido 12s+ QuickBBS 2.66 TBBS 2.1
GSBBS 3.02 RBBS 17.3B TComm/TCommNet 3.4
Lynx 1.30 RBBSmail 17.3B Telegard 2.5
Kitten 2.16 RemoteAccess 1.00* TPBoard 6.1
Maximus 1.02 SLBBS 1.77A Wildcat! 2.55
Opus 1.14+ Socrates 1.10 WWIV 4.12
PCBoard 14.5 SuperBBS 1.10 XBBS 1.17
Network Node List Other
Mailers Version Utilities Version Utilities Version
BinkleyTerm 2.40 EditNL 4.00 ARC 7.0
D'Bridge 1.30 MakeNL 2.31 ARCAsim 2.30
Dutchie 2.90C ParseList 1.30 ARCmail 2.07
FrontDoor 1.99c Prune 1.40 ConfMail 4.00
PRENM 1.47 SysNL 3.14 Crossnet v1.5
SEAdog 4.60* XlatList 2.90 DOMAIN 1.42
TIMS 1.0(Mod8) XlaxDiff 2.35 EMM 2.02
XlaxNode 2.35 4Dog/4DMatrix 1.18
Gmail 2.05
GROUP 2.16
GUS 1.30
HeadEdit 1.18
IMAIL 1.10
InterPCB 1.31
LHARC 2.10
MSG 4.1
MSGED 2.06
MSGTOSS 1.3
Oliver 1.0a
PK[UN]ZIP 1.20
QM 1.0
QSORT 4.03
ScanToss 1.28
Sirius 1.0x
SLMAIL 1.36
StarLink 1.01
TagMail 2.41
FidoNews 8-17 Page 32 29 Apr 1991
TCOMMail 2.2
Telemail 1.27
TMail 1.15
TPBNetEd 3.2
TosScan 1.00
UFGATE 1.03
XRS 4.10*
XST 2.3e
ZmailH 1.14
OS/2 Systems
------------
Bulletin Board Software Network Mailers Other Utilities
Name Version Name Version Name Version
Maximus-CBCS 1.02 BinkleyTerm 2.40 Parselst 1.32
ConfMail 4.00
EchoStat 6.0
oMMM 1.52
Omail 3.1
MsgEd 2.06
MsgLink 1.0C
MsgNum 4.14
LH2 0.50
PK[UN]ZIP 1.02
ARC2 6.00
PolyXARC 2.00
Qsort 2.1
Raid 1.0
Remapper 1.2
Tick 2.0
VPurge 2.07
Xenix/Unix
----------
BBS Software Mailers Other Utilities
Name Version Name Version Name Version
BinkleyTerm 2.30b Unzip 3.10
ARC 5.21
ParseLst 1.30b
ConfMail 3.31b
Ommm 1.40b
Msged 1.99b
Zoo 2.01
C-Lharc 1.00
FidoNews 8-17 Page 33 29 Apr 1991
Omail 1.00b
Apple II
----------
Bulletin Board Software Network Mailers Other Utilities
Name Version Name Version Name Version
GBBS Pro 2.1 Fruity Dog 1.0 ShrinkIt 3.23*
DDBBS + 5.0 ShrinkIt GS 1.04
deARC2e 2.1
ProSel 8.66*
Apple CP/M
----------
Bulletin Board Software Network Mailers Other Utilities
Name Version Name Version Name Version
Daisy v2j Daisy Mailer 0.38 Nodecomp 0.37
MsgUtil 2.5
PackUser v4
Filer v2-D
UNARC.COM 1.20
Macintosh
---------
Bulletin Board Software Network Mailers Other Utilities
Name Version Name Version Name Version
Red Ryder Host 2.1 Tabby 2.2 MacArc 0.04
Mansion 7.15 Copernicus 1.0 ArcMac 1.3
WWIV (Mac) 3.0 LHArc 0.41
Hermes 1.5 StuffIt Classic 1.6
FBBS 0.91 Compact Pro 1.30
Precision Systems 0.95b* TImport 1.92
TeleFinder Host 2.12T10 TExport 1.92
Timestamp 1.6
Tset 1.3
Import 3.2
Export 3.21
Point System Software Sundial 3.2
PreStamp 3.2
Name Version OriginatorII 2.0
FidoNews 8-17 Page 34 29 Apr 1991
AreaFix 1.6
Copernicus 1.0 Mantissa 3.21
CounterPoint 1.09 Zenith 1.5
Eventmeister 1.0
TSort 1.0
Mehitable 2.0
UNZIP 1.02c
Zip Extract 0.10
Amiga
-----
Bulletin Board Software Network Mailers Other Utilities
Name Version Name Version Name Version
Falcon CBBS 0.45 BinkleyTerm 1.00 AmigArc 0.23
Paragon 2.082+ TrapDoor 1.50 AReceipt 1.5
TransAmiga 1.07 WelMat 0.44 booz 1.01
ConfMail 1.12
ChameleonEdit 0.10
ElectricHerald1.66
Lharc 1.30
Login 0.18
MessageFilter 1.52
oMMM 1.49b
ParseLst 1.64
PkAX 1.00
PolyxAmy 2.02
RMB 1.30
Roof 44.03
RoboWriter 1.02
Rsh 4.06
Skyparse 2.30
Tick 0.75
TrapList 1.12
UNZIP 1.31
Yuck! 1.61
Zippy (Unzip) 1.25
Zoo 2.01
Atari ST/TT
-----------
Bulletin Board Network Node List
Software Version Mailer Version Utilities Version
FIDOdoor/ST 2.2.3* BinkleyTerm 2.40l ParseList 1.30
QuickBBS/ST 1.02 The BOX 1.20 Xlist 1.12
Pandora BBS 2.41c EchoFix 1.20
GS Point 0.61 sTICK/Hatch 5.50*
LED ST 1.00
MSGED 1.96S
FidoNews 8-17 Page 35 29 Apr 1991
Archiver Msg Format Other
Utilities Version Converters Version Utilities Version
LHARC 0.60 TB2BINK 1.00 ConfMail 4.03
LHARC2 3.18* BINK2TB 1.00 ComScan 1.02
ARC 6.02 FiFo 2.1m* Import 1.14
PKUNZIP 1.10 OMMM 1.40
Pack 1.00
FastPack 1.20
FDrenum 2.2.7*
Trenum 0.10
Archimedes
----------
BBS Software Mailers Utilities
Name Version Name Version Name Version
ARCbbs 1.44 BinkleyTerm 2.03 Unzip 2.1TH
ARC 1.03
!Spark 2.00d
ParseLst 1.30
BatchPacker 1.00
+ Netmail capable (does not require additional mailer software)
* Recently changed
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
-----------------------------------------------------------------
FidoNews 8-17 Page 36 29 Apr 1991
=================================================================
NOTICES
=================================================================
The Interrupt Stack
12 May 1991
Fourth anniversary of FidoNet operations in Latin America and
second anniversary of the creation of Zone-4.
15 Aug 1991
5th annual Z1 Fido Convention - FidoCon '91 "A New Beginning"
Sheraton Denver West August 15 through August 18 1991.
8 Sep 1991
25th anniversary of first airing of Star Trek on NBC!
7 Oct 1991
Area code 415 fragments. Alameda and Contra Costa Counties
will begin using area code 510. This includes Oakland,
Concord, Berkeley and Hayward. San Francisco, San Mateo,
Marin, parts of Santa Clara County, and the San Francisco Bay
Islands will retain area code 415.
1 Nov 1991
Area code 301 will split. Area code 410 will consist of the
northeastern part of Maryland, as well as the eastern shore.
This will include Baltimore and the surrounding area. Area 301
will include southern and western parts of the state,
including the areas around Washington DC. Area 410 phones will
answer to calls to area 301 until November, 1992.
1 Feb 1992
Area code 213 fragments. Western, coastal, southern and
eastern portions of Los Angeles County will begin using area
code 310. This includes Los Angeles International Airport,
West Los Angeles, San Pedro and Whittier. Downtown Los
Angeles and surrounding communities (such as Hollywood and
Montebello) will retain area code 213.
1 Dec 1993
Tenth anniversary of Fido Version 1 release.
5 Jun 1997
David Dodell's 40th Birthday
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
FidoNews 8-17 Page 37 29 Apr 1991
-----------------------------------------------------------------
