FidoNews is published weekly by the International FidoNet
Association as its official newsletter. You are encouraged to
submit articles for publication in FidoNews. Article submission
standards are contained in the file ARTSPEC.DOC, available from
node 1:1/1.
Copyright 1988 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067. IFNA may also be contacted
at PO Box 41143, St. Louis, MO 63141.
Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and
are used with permission.
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them.
Everything here is subject to debate. We publish EVERYTHING
received.
Table of Contents
1. ARTICLES ................................................. 1
Proposal for (yet) another new net ....................... 1
Toward a Virus Free FidoNet .............................. 15
XlaxNode Version 2.10 Release Notice ..................... 17
2. NOTICES .................................................. 18
The Interrupt Stack ...................................... 18
FidoCon/Delta ticket giveaway ends soon! ................. 18
Latest Software Versions ................................. 18
FidoNews 5-29 Page 1 18 Jul 1988
Within the last few months, I've seen a few new nets form as
"alternatives" to Fidonet. The problem with many of these, in
my view, is that they are almost "special interest" nets... for
example, Alternet is the "burnouts" net with a medieval motiff
(some say "Dungeons and Dragons"). The "Good Egg Net" is for
those who want a return to the simpler days of Fidonet, and has
a "National Egg Commissioner" and various titles like that.
Personally, the thought of joining a net and having to refer to
those higher in the organization as the Duke or Duchess of
such-and-such, or Egg Inspector so-and-so, does not really
appeal to me. These games are fine for those who enjoy them
(and this is not a slam against those who do), but it's just not
my cup of tea. I'd guess I prefer a net that's run on a
slightly more businesslike basis.
At the same time, I see many problems in Fidonet that come about
because the workings of Fidonet are often based on assumptions
that are not totally valid, and policies that were formulated
back in the days before echomail even existed. For that reason,
I'd like to propose a new net to be called "LCRNET". LCR
Stands for "LEAST COST ROUTING" and describes the most basic
guiding principle behind this new net... namely, the primary
purpose of this net will be to enable sysops to move netmail and
echomail as inexpensively as possible. To this end, any
tradition or policy that interferes with the concept of Least
Cost Routing will be disposed of post haste.
In the next few paragraphs, I'd like to outline just a few
specifics of this proposal. I want to find out if anyone else
is interested in such a net, and if so, solicit ideas for the
best way to implement it.
HOW DOES LCRNET DIFFER FROM FIDONET?
LCRNET will make some major breaks with time-honored Fidonet
conventions, but where possible we want to retain enough
compatibility with Fidonet that we can still pass netmail and
echoes back and forth. Unfortunately, unless someone can come
up with a better idea, the only way that I can see to accomplish
this is to follow the precedent set by the other "alternative"
nets that have gone before, and assign LCRNET a separate "zone"
number. The reason for doing this is that echomail can then be
passed through "zonegates" which will have the capability to
produce echomail packets in a format acceptable to Fidonet
nodes, should any "conversion" be required.
FidoNews 5-29 Page 2 18 Jul 1988
NO REGIONS
Regions are a political division within Fidonet. They are not
used by any echomail or netmail processor for mail routing. It
appears that in Fidonet regional divisions have actually worked
against Least Cost Routing. The reason for this is that some
regional coordinators see their regions as sort of their own
little fiefdoms, and regard regional boundaries as sacred. But
for many sysops, the least expensive source for echomail may
well be on the other side of the artificially-created regional
boundary. Thus, I feel that regional divisions have proven to
be counter-productive to the efficient operation of the net, and
propose that the whole concept of Regions be done away with.
ZONES TO BE GATEWAYS TO OTHER NETS
Zones, even though on a higher level than nets, are still
basically artificial geographic divisions. I feel that
"zonegates" can be more useful as gateways to other nets
(Fidonet, Alternet, FamilyNet, Eggnet, etc.). However, this is
not cast in stone, and if anyone can provide compelling reasons
for duplicating Fidonet's zone usage in LCRNET, we can certain
consider that aspect of mail addressing. Please note that the
country in which a net is located can be determined from the net
number if the numbering plan described in the next paragraph if
adopted.
NET NUMBERS TO BE FOUR DIGIT NUMBERS
I have two reasons for this. One is that by using four digit
numbers for nets, it will make it much easier to interface
LCRNET with Fidonet, which generally uses three-digit zone
numbers. The other reason is that we can specify that the first
digits of the net number will duplicate the telephone country
code for the net where the country is located, thus giving us
some opportunity for deterining where a node is geographically
located should this become desirable. For example:
Net 1xxx = United States & Canada.... 1000 possible net numbers
Net 61xx = Australia.... 100 possible net numbers
Net 507x = Panama.... 10 possible net numbers
Net numbers ending in "99" (for countries with one digit country
codes) or "9" (for countries with two or three digit country
codes) will be reserved for point nets. These numbers will
never appear in the nodelist and thus can be reused for
different point nets at various locations throughout a country.
They are simply left unassigned as a convenience so that any
sysop can create a point net and assign a net number with the
assurance that this number will never be used by any "real" net.
NO GEOGRAPHIC RESTRICTIONS ON NETS
Normally, a net will encompass the local calling area of a city,
plus some outlying nodes that may or may not be able to call
into the city with a local call. But in LCRNET, the sysop of
FidoNews 5-29 Page 3 18 Jul 1988
any given node may join any net he chooses to, providing the net
host is willing to allow him in. Joining a net at some distance
away because it is a low-cost or no-cost call to that location
is specifically permitted, and even encouraged.
By the same token, there will be no prohibition against having
more than one net covering the same geographic area. LCRNET is
not a geographically-driven net... cost is the driving factor.
Nodes can even join nets in other countries if they wish (in
which case they will use the net number of their net host).
This is to avoid restricting a node that may have access to a
special calling service (for example, a foreign exchange line to
a distant city) from joining a net in that distant city, but it
is also designed to avoid the situation where a net host can
become overbearing on the nodes under him. There are no
monopolies in LCRNET, any node is free to join any net that will
take him in.
Net hosts in LCRNET should be willing to take in nodes outside
their local geographic area so long as it does not increase
their costs and so long as the node has a reasonably good reason
for wanting to join. A "personality conflict" with the local
net host *may* be considered good reason for him to join another
net, however, net hosts are not required to take in nodes that
have proven themselves to be "twits" in other nets.
SOFTWARE BREAKS WITH FIDONET
Certain assumptions that were considered valid in Fidonet are
specifically NOT valid in LCRNET. These include:
Invalid assumption #1: File attaches are never forwarded.
In LCRNET, a good sysop will try to provide a way to forward
file attaches (netmail messages with files attached) so long as
they do not increase his costs. In other words, file attaches
need not be forwarded if the sysop is paying a per-minute toll
charge to send netmail, but local file attaches (and those that
can be sent via PC Pursuit and similar services) SHOULD be
forwarded to the destination node. This may in some cases
require the use of software that is not yet available, so this
goal may not be attained immediately. Please note that just
because the capability to forward file attaches is present does
not mean it should be used. Anyone planning to forward a very
large file, or to forward files on a regular basis, should
probably obtain permission first from the sysops of the systems
through which such files will pass.
Invalid assumption #2: ARCA and ARCE are the "standard" ARCing
and deARCing programs.
ARCA and some versions of ARCE do NOT support "squashing" which
is the most efficient method of packing many netmail archives.
Therefore, in LCRNET the "standard" programs will be PKARC and
PKXARC. Some sysops may not be able to use PKARC during the
FidoNews 5-29 Page 4 18 Jul 1988
mail packing process so they may continue to use ARCA as an
interim measure, but they should at least try to use PKXARC to
unARC files. Many mail tossers now allow the option of using
PKXARC to unpack files, and conversion programs (e.g. ARC2PK)
are available for use with other systems (such as Opus 1.03b).
Programs that are totally incapable of at least unARCing
"squashed" archives shall be considered non-standard in LCRNET.
Invaild assumption #3: Netmail (or matrix mail, as it is
sometimes called) is always sent direct, or from net host to net
host. In LCRNET, it is considered desirable to send messages at
the lowest possible cost. Therefore, within the United States
all Net Hosts that are not themselves PC Pursuitable shall make
arrangements to "home" their mail traffic to a node in a PC
Pursuitable city (net hosts in other countries, particularly
those in Canada, may optionally elect to do this as well). When
this is done, the PC Pursuitable node to which netmail traffic
for this net can be routed should be listed under an AI: flag in
the nodelist comment field (see NODELIST FLAGS). Since LCRNET
attempts to route netmail messages over "no cost" routes, or at
very least along with regular echomail packets, the use of
software that allows "return receipts" to be generated shall be
considered a desirable feature.
One other break with Fidonet is that the use of "tiny" SEEN-BY
lines and tight control over network topologies will be
encouraged. Sending duplicate messages around the net shall be
considered an EXTREMELY undesirable action. Therefore, all
nodes carrying echomail shall, whenever possible, use software
that supports the ^APATH: line (e.g. ConfMail) so that the
source of duplicate messages can be easily determined. In
addition, NO NODE SHALL RECEIVE THE SAME ECHO FROM TWO DIFFERENT
FEEDS, unless he specifically informs BOTH feeds of what he is
doing and they BOTH authorize it, and steps are taken to avoid
the introduction of DUPE messages into the net.
POLITICAL BREAKS WITH FIDONET
I would like to leave politics out of LCRNET as much as
possible. This is one reason I advocate eliminating Regions, as
these simply create small fiefdoms that tend to give certain
individuals too much power. In addition, I advocate the
following breaks with Fidonet:
CONFERENCE MODERATORS TO BE SUPREME OVER THEIR CONFERENCES
In LCRNET, a conference moderator has more authority and more
responsibility than in Fidonet. In LCRNET, the moderator shall
try to keep an accurate topology map of his conference, and to
know at all times where a given node is receiving the conference
from, and who he is sending it to. The only exception to this
is that if one node is feeding the conference to other nodes in
a given net, the conference moderator need not be informed of
those who add and drop the conference within the net.
FidoNews 5-29 Page 5 18 Jul 1988
Any LCRNET node receiving a conference shall provide a comple
list of the nodes he is receiving the conference from, or that
he is sending the conference to, at the request of the
moderator.
The conference moderator may, for good cause, rename a
conference (to avoid name confusion with another conference, or
to facilitate merging the conference with another of the same
name) and/or direct that links to a particular node be cut.
Valid reasons for cutting nodes to a link could include any of
the following:
1) Messages originate from that node that contain foul language.
Those who believe in total freedom of speech and the right to
say anything, anywhere, at any time will NOT be happy in LCRNET
and are encouraged NOT to join. The intent is that LCRNET will
be more like Alternet than Fidonet in this regard. Profanity
and foul language shall normally be considered bad behaviour in
LCRNET unless a conference moderator specifically allows them in
a given conference. HOWEVER, no LCRNET node shall under any
circumstances be required to carry or pass along an echo in
which profanity or foul language are allowed.
2) Messages originate from a node that contain personal attacks
on others. It is one thing to disagree with someone else's
viewpoints, quite another to attack their intelligence or
background, etc. As with foul language, personal attacks shall
normally be considered bad behaviour in LCRNET, and no LCRNET
node shall under any circumstances be required to carry or pass
along an echo in which they are tolerated.
3) Messages originate from a node that consistently violate the
stated rules of an echo. Also, a conference moderator is not
required to put up with users that consistently "test the
limits" of the moderator's patience by trying to see how close
they can come to breaking a rule without actually breaking it
(for example, using "veiled" profainty in which the meaning is
fairly obvious, or "near" personal attacks).
4) Messages originate from a node that contain illegal
information (stolen credit card numbers, etc.), that are
patently obscene, or that contain remarks designed to stir up
hatred or advocate violence between people of different races,
religions, etc. These types of messages are specifically NOT
ALLOWED in LCRNET. Note that in regard to illegal information,
a message must actually CONTAIN illegal information to violate
this rule. For example, a message that states "I think everyone
ought to use stolen credit cards" would not violate THIS rule,
though it might violate a posted rule of the conference in
question. But a message that CONTAINED stolen credit card
numbers WOULD violate this rule.
5) In the case of religious or political echoes that are
intended as "meeting places" for people of like mind, links may
be cut to nodes that constantly allow messages that agitate
against these beliefs. For example, if a conference were set up
FidoNews 5-29 Page 6 18 Jul 1988
for the express purpose of discussing how best to implement the
Strategic Defense Initiative, a node that consistantly allows
messages to be posted discouraging the whole concept, advocating
a nuclear freeze, etc. could be cut from the conference. The
test here shall be whether the conference is set up primarily
for people of like mind to share thoughts and ideas, or whether
the conference is considered "open to unbelievers". However,
even in the latter case, a node may be cut for specific repeated
violations of conference rules.
6) Links may be cut to a node if the Sysop of that node refuses
the legitimate request of the conference moderator to provide a
list of nodes that he is receiving the conference from and
sending the conference to. The conference moderator must have
this information available in order to track down the source of
duplicate messages, or messages that consistently violate the
rules of LCRNET or of the echo itself. However, conference
moderators shall not pass out this information to others if the
Sysop requests that such information be kept confidential,
unless such disclosure is necessary to prove that a rule
violation has occurred when cutting links to that node.
ECHOES CARRIED ON LCRNET DO NOT AUTOMATICALLY BECOME "PUBLIC
DOMAIN"
The one and only purpose of this statement is to assure
conference moderators that they are allowed to pull their
conferences OFF of LCRNET should they feel the absolute need to
do so. We hope that the greater authority afforded to
moderators on LCRNET would never make this necessary, but a
moderator does have the right to do this if he or she feels it
necessary.
LCRNET echoes may NOT be carried by nodes belonging to any other
net (Star or backbone nodes in particular) unless they agree to
this condition.
ECHOMAIL HUBS MAY NOT CUT ECHO FEEDS FOR POLITICAL REASONS
In Fidonet the situation has sometimes come up where a node will
cut all echomail feeds to another node because of some
disagreement between the two sysops. Thus, control over
echomail feeds becomes a form of "blackmail" over another sysop.
This sort of thing is considered EXTREMELY bad behaviour in
LCRNET. Generally speaking, no LCRNET node is required to bring
any given conference into an area, but when it does bring in a
conference and offers it to other nodes, it must offer it on a
non-discriminatory basis. The only valid reasons for refusing
to send a conference to a node are as follows:
1) The conference moderator has directed that links to this node
for a particular conference be cut, as specified above.
2) Providing the conference would cause the node to incur
additional costs. Obviously, this is not valid if the
conference can be sent via a flat-rate medium such as PC
FidoNews 5-29 Page 7 18 Jul 1988
Pursuit, or if the receiving node offers to poll for the echoes.
3) Technical limitations... for example, a node is running Opus
software and is already sending a given echo to ten other nodes
(the maximum allowed in Opus). But if the node receiving the
request for a feed is the ONLY no-cost source for that echo
available to that node, some sort of arrangement should be made
to try and accommodate that node.
4) Technical problems at the receiving node... for example, no
one is required to provide feeds to a node that constantly
generates "dupe" messages.
Please keep in mind that the primary motivation of LCRNET is to
reduce costs for all involved. Therefore, if you are the only
no-cost source of an echo to a given node, and you refuse to
provide the echo to that node, you should have a VERY good
reason for the refusal.
PASSING ON COSTS
Nodes that wish to become Echomail hubs for a given area should
be prepared to absorb the expenses incurred in that operation.
This is not to imply that two or more nodes cannot share costs
incurred in bringing echoes into an area, but this should be
considered the exception rather than the rule.
If a node is using a flat-rate service such as PC Pursuit to
bring echoes into a given area and wishes to split the monthly
cost with other nodes, it shall be divided equally among all
nodes receiving the echoes. For example, if one node is
receiving echoes and distributing them to four other nodes, this
means that five nodes are benefiting from the echoes, so each
node should pay one-fifth of the monthly charge ($5 in the case
of PC Pursuit at $25 per month). Costs should not be assessed
on number of echoes received since this discourages nodes from
carrying new echoes. Again, however, this type of cost sharing
should be considered the exception rather than the norm
(primarily since the person holding the flat-rate account can
use it for non-BBS related activites, and thus derives greater
benefit from it). Cost sharing of non-flat-rate services (e.g.
regular long distance charges) is officially discouraged because
it almost invariably leads to arguments and hard feelings over
whether everyone is paying their "fair share".
NET HOSTS GOVERN AT THE PLEASURE OF THE NET SYSOPS
Despite the cries for a "democracy" in Fidonet, I don't feel
that net hosts should be subject to the necessity of
"campaigning" and running a "popularity contest" periodically.
Many sysops have stated they simply would not take a position
under such circumstances. However, nothing in the LCRNET rules
will PREVENT the formation of democratically-governed nets,
where the Net Host is elected by the sysops in the net, but in
such cases the rules for such elections shall be decided by the
FidoNews 5-29 Page 8 18 Jul 1988
net itself. Please keep in mind, however, that nothing in
LCRNET rules prevents the formation of two different nets that
cover the same geographical area. There are no monopolies in
LCRNET! Thus if a number of sysops feel that they cannot
function under the current net host, and he or she cannot be
persuaded to resign, those sysops are perfectly free to start
another net. However, things should not be allowed to
deteriorate to the point where this is necessary if at all
possible. LCRNET should be a net of cooperation, not
competition. Net hosts who feel the need to dictate many rules
or policies for their own net (in addition to those in this
document) might be happier in another net.
Above the Net level, there are no intermediates until you reach
the national/international level. I am open to suggestions for
the type of organization we should have there. However, any
positions at those levels will be unpaid, volunteer positions.
LCRNET will not hold conventions in fancy hotels, nor squander
money. There will be no "dues" to be in LCRNET, or any
organization connected with LCRNET. There will be no "poll tax"
to vote on any issue facing LCRNET. We do reserve the right to
ask for voluntary contributions should that become necessary,
but the word VOLUNTARY is emphasized... no coercion or pressure
shall be put on anyone to "contribute", and no disparaging
remarks shall be made about anyone because they did not
contribute.
In any vote held in LCRNET, the principle of "one person, one
vote" shall be strictly adhered to. That means that each sysop
listed in the LCRNET nodelist gets one vote, regardless of the
number of systems he may sysop.
THE NODELIST
The LCRNET nodelist will NOT be used as a political tool. NO
ONE shall be dropped from the LCRNET nodelist unless their node
goes offline or is consistantly unreachable during the Fidonet
Zone Mail Hour (which LCRNET nodes will be expected to observe
until or unless we adopt a different mail hour). A node shall
NOT be dropped from the nodelist because of a personality
conflict with someone else, however they may be dropped for
consistant and pervasive violations of the rules in this
document. What this means is that unless somebody is such a
blatent and obvious jerk that almost everybody in the net hates
his guts, he will not be dropped from the nodelist. Net hosts
should be aware that anyone dropped from their net is perfectly
free to apply to be included in another net.
Conversely, however, since nets are not strictly geographically
based, there will be no "independent" nodes in LCRNET. A node
that might be "independent" in another net should try to join a
net in a major city (in the United States it would be preferable
to join one based in a PC Pursuitable city). This also gives us
some control over "twit" sysops because if a sysop gains a
really bad reputation, chances are that no net host will take
FidoNews 5-29 Page 9 18 Jul 1988
him into his or her net (for very long, anyway). Of course, the
"twit" sysop can always start his own net, but a net by
definition consists of MORE THAN ONE node (controlled by more
than one sysop).
Once again, if a net host takes an action that will cost someone
else money (for example, dropping someone from a local net, thus
forcing them to call long distance to pick up mail from another
net) they should have a VERY good reason for doing so.
NODELIST FLAGS
We intend to expand the number of valid nodelist flags from
those allowed in Fidonet, and are open to suggestions. However,
LCRNET will allow a specific new flag, as follows:
AI:net[/node][,net[/node],net[/node]...]
The net/node(s) listed are alternate nodes to which inbound mail
can be sent. These are nodes which either the sysop or his net
host polls regularly. LCRNET net hosts located in the United
States but not in a PC Pursuit inbound area will be expected to
use this flag to indicate at least the PC Pursuitable node on
which they "home" for netmail traffic. If only a single number
is listed after the AI: designator, it will be taken as a net
number and netmail can be directed to the net host of that net
(net/0). For example:
AI:1234 is equivalent to AI:1234/0
Let's take a typical situation. Node 1777/80 and his net host,
1777/0 are in a non-PC Pursuitable city and in addition, 1777/0
is not a PC Pursuit user. However, he regularly picks up echoes
from 1876/0, who IS a PC Pursuit user and who regularly calls
1323/5 in a PC Pursuitable city to pick up echoes. Here's how
the AI: field might read for each of these nodes:
1777/80 - AI:1876,1323/5 - In this case, 1777/80 can receive
netmail sent to 1777/0 (his normal inbound host, which is
assumed), 1876/0, 1323/5, or 1323/0 (the net host for 1323/5).
1777/0 - Same as for 1777/80, since he can receive from the same
nodes.
1876/0 - AI:1323/5 - In this case, 1876/0 would list the PC
Pursuitable node that he polls regularly. Mail for him could be
sent to 1323/5 or 1323/0 (the net host for 1323/0).
1323/5 would not be required to use an AI: in the nodelist,
since he's in a PC Pursuitable city.
Now let's see how the actual routing of incoming netmail would
be handled. Let's assume a "worst case" situation, where a
piece of netmail intended for 1777/80 is sent to 1323/0.
1323/0 would have a statement in its routing control file
FidoNews 5-29 Page 10 18 Jul 1988
similar to this:
ArcCM 1323/5 1876/ALL 1777/ALL
This would route the mail for net 1777 to 1323/5.
1323/5 would have a statement in its routing control file like
this:
ArcHold 1876/0 1876/ALL 1777/ALL
This would route the mail for net 1777 to 1876/0.
1876/0 would have a statement like this:
ArcHold 1777/0 1777/ALL
This would send the mail for net 1777 to the Net 1777 host,
where it would finally get set to 1777/80.
Note that in this case, the mail could pass through several
systems before reaching its destination. This is why all net
hosts at least are encouraged to "home" directly on PC
Pursuitable cities whenever this can be done without incurring
additional expense.
In Fidonet, speed of mail delivery is considered of primary
importance, regardless of the expense. In LCRNET, cost is the
driving factor. This is one major difference between the two
nets. Of course, there is nothing to prevent an LCRNET sysop
from directly crashing messages to another system without
routing them, so really important messages can always be sent
immediately, albeit at higher cost.
MODEM TYPE FLAGS
The use of the following modem type flags will be specifically
allowed in the nodelist comment field:
HAY Hayes V series
HST USRobotics HST
MAX Microcom AX/9624c
PEP Telebit Trailblazer
MNP MNP error correction protocol available
Further suggestions are welcome.
CONTINUOUS MAIL
In LCRNET, the ability to send and receive continuous mail shall
be considered the norm (except where hours of operation are
given). Software that does NOT have this ability shall be so
indicated by the special nodelist flag NC (for Non-Continuous).
As an interim measure, the CM: flag may be used by all systems
that can receive mail continuously (24 hours a day) in order to
be compatible with existing nodelist processors. It is hoped
that new software can be written for use with LCRNET that will
recognize and properly process the new nodelist flags.
STATEMENT ON "POINTS" AND THEIR PURPOSE
FidoNews 5-29 Page 11 18 Jul 1988
In LCRNET, a "point" is a regular BBS user who calls into a BBS
using software that will pick up the echoes he wishes to read,
and allows him to read and reply to those echoes offline. The
main difference in LCRNET Is that here it is quite acceptable
for the BBS operator to make the outgoing call to the "point" on
a prearranged schedule, if by doing so a lower cost to the user
can be achieved. The BBS operator may recover any long distance
costs incurred in doing this from the "point" user.
BBS operators are never "points". If a BBS operator is unable
or unwilling to observe the Zone Mail Hour but would otherwise
qualify to be in the nodelist, he or she should be listed as a
private, unlisted node. No one who is running compatible
software shall be denied listing in the LCRNET nodelist just
because they are running a private node that is not available to
the general public.
INTERCONNECTIONS WITH OTHER NETS
The main purpose of LCRNET is to encourage communications at the
lowest possible cost. Therefore, interconnections with other
nets shall be encouraged. However, wherever possible these
shall take place through "gateway" systems wherever echomail is
involved (except for local or private conferences circulated to
a very small or tightly controlled group of nodes). There are
two reasons for this: One is to prevent "dupe" messages from
flowing from one system into another. If all messages between
the two nets pass through a single "gateway" system, then the
dupe killer at that system should prevent any duplicate messages
from entering the other net. The other reason is that should
the quality of the conference begin to deteriorate on the other
net to the point where messages coming from that net
consistantly violate LCRNET rules, or are mostly irrelevant to
the topic of discussion, the link can be easily cut (although
this is something that would NOT be done suddenly and without
warning).
It is realized that in the initial stages of setting up LCRNET,
most sysops will continue to get echo conferences through the
same Fidonet feeds that they always have. In keeping with the
spirit of LCRNET, no sysop will be forced to drop any
independent feed of an echo that he is getting from Fidonet or
any other net. He MAY be asked, however, not to feed this echo
to other LCRNET nodes, particularly where by doing so "dupe"
messages are being created. As always, cost will be the
motivating factor in deciding how echoes are distributed.
MESSAGE CONTENT (FLAMES, ETC.)
Most of the restrictions on message content have already been
covered. However, there are certain people who can't seem to
hold a discussion without resorting to FLAMES, personal attacks,
and so on. We would prefer these people NOT attemt to join
LCRNET, because we want to have a friendly, happy and sharing
FidoNews 5-29 Page 12 18 Jul 1988
net. If you are the type of Sysop who has been embarrassed to
let your family read the echomail areas on your BBS because of
some of the childish attitudes displayed there, you will
probably be welcome in LCRNET.
Because nets are not geographically restricted, and there are no
regional coordinators of any kind, much of the necessity for
FLAMES should be eliminated. If you have a problem with the Net
host, join another net, or form your own. If you have a problem
with the national leadership, tough toenails... there are other
nets around. In LCRNET we want to give everyone choices so that
if you find an individual particular abrasive, you can simply
ignore him (which will probably infuriate him more than flaming
at him anyway... such individuals usually crave attention, even
if it's negative). There are no monopolies in LCRNET. Most of
the power in LCRNET will rest with the net hosts. It's sort of
like choosing a hamburger joint for lunch... if you find the
people are consistantly rude in one, you find another. If the
other happens to be ten blocks farther away and charges 10 cents
more per burger, then you have to decide which is more
objectionable to you. What you don't do is stand outside of one
or the other and yell and scream and stomp and call the manager
names... that will get you nowhere fast... about as far as
FLAMES in LCRNET will get you.
We want LCRNET to be a nice, discussion oriented net, where
common courtesy and politeness are expected and practiced.
PRIVATE MESSAGES
The official position of LCRNET will be that LCRNET does *NOT*
support the transmission of "private" or "confidential" mail.
Mail may be intercepted at any point along its path and read by
persons other than the intended recipient. LCRNET should not be
used to transmit messages of a private or confidential nature.
TECHNOLOGICAL ADVANCES
We would like for LCRNET to be the network of choice for
innovators... those who don't feel constrained by the
established norms in software and hardware, for example. Of
course, if you are designing software for use in the net, you
should attempt to make it as compatible as possible with
existing software... after all, it wouldn't do to design a
program to toss echomail packets that no other program can read!
But it's also okay to make a new program that's "downward
compatible" with existing programs.
We'd also like to encourage the use of means of communications
other than standard telephone lines, especially those means that
can lower the cost of communications. We're waiting for the day
that all the echomail hubs can stick up a $100 Ku-band satellite
dish and simutaneously receive the "4 A.M. National Echomail
Feed" every morning. In the meantime, experiments with such
items as radio modems, microwave or infrared transmission,
FidoNews 5-29 Page 13 18 Jul 1988
direct tie-ins to packet networks, moon bounce, or anything else
folks might want to try are encouraged in LCRNET. You will not
find a "Technical Standards Committee" here telling you that
"you can't do that because it will obsolete the piece of
software I wrote three years ago." Again, this does not imply
that you should be TRYING to "break" existing software, but we
certainly are open to whatever you may be doing... particularly
if it will wind up saving money for sysops.
WANT TO JOIN US?
If you think you'd be interested in being part of LCRNET, please
send Netmail to Jack Decker at 154/8. Send flames to NUL. I
know some of you detest the formation of new nets, and frankly,
I couldn't care less. Fidonet long ago stopped being responsive
to the needs of the "average sysop", and recently seems to have
become a haven for petty self-appointed demagogues. We want to
provide an alternative to that sort of nonsense.
If enough interest is expressed, we will form this net and issue
a nodelist. If you'd like to be a net host in this net, please
so indicate and also indicate your choice for a net number
(remember that it must be a four digit number that begins with
your country's telephone country code).
Constructive suggestions and criticisms (other than "don't do
this"... if there's enough interest we will, if there's not, we
won't) will be welcome and will be considered! And if anyone
with writing skills would care to polish this document into a
basic LCRNET policy document, it would be very much appreciated.
Your input is welcomed. If you feel that we should go ahead
with this, then at this point I especially need input on what
sort of national leadership we should have. My own preference
is for a rather loose, informal organization at the top that
would perhaps only be responsible for getting out the nodelist
and mediating any disputes in regard to LCRNET rules, but I'm
certainly very open to other suggestions!
We have started an echo called LCRNET (naturally) which is
hubbed off of Fidonet node 154/7 (a PC Pursuitable node) for
further discussion. This echo is is just starting and if you
are interested in seeing this proposal inplemented and would
like to be part of such an echo, please send netmail.
One other point... I can almost bet that once this proposal hits
the wires, somebody's going to accuse me of trying to start my
own little fiefdom. Well, I'm not going to spend a lot of time
debating with such people, I will just simply say that it isn't
true, but you can believe it if you want to. You can also
believe the earth is flat if you want to. However, I do *not*
see myself in a leadership position in LCRNET... there are many
others who have much better organizational talents that could
probably do a much better job of running such an organization
(to whatever extent that it needs anyone to "run" it at all). I
have been around Fidonet long enough to realize that there's no
FidoNews 5-29 Page 14 18 Jul 1988
way I'm going to make this proposal without getting a few
personal attacks, but I would much rather see the debate center
on the actual proposal itself. And if anyone in Fidonet or any
other net would care to "borrow" any ideas from this document,
by all means please feel free to do so. If all this document
accomplishes is to give someone in another net some ideas for
their net, then it will have served a useful purpose.
Toward a Virus Fee FidoNet
by
Bob Hartman 1:132/101.1
In the interest of helping people make sure that the
programs which they use are free from viruses, I have made
the following list. This list is the output from PKARC
version 3.6 on various archives that I KNOW are virus free.
I know this because I was the person that created the
archives, and compiled the original programs within them.
The command used to create the list was:
PKARC V archive > output
I then edited the output to fit into FidoNews by
deleting some of the information which is unimporant (like
the method of archiving). If you do the same command, and
compare to the output below, be wary of any program which
does not match the numbers below EXACTLY! I would even
appreciate being warned of any such mismatches.
A file containing this article, including any updates
will always be requestable from 1:132/101 under the magic
filename "NO_VIRUS.CRC".
XlaxNode Version 2.10 is now available for general release.
XlaxNode is a high performance replacement for a number of
popular nodelist utilities. The raw nodelist is compiled
directly to Opus 1.0x, Opus 1.1x, Binkley, QuickBBS and/or Seadog
format in a single step. No intermediate files or programs are
needed. All sorts are internal.
Xlax_210.Arc (151K) is available for file request from the
following nodes. Unless otherwise noted, they are 2400 baud and
accept file requests from one hour after NMH to one hour before
NMH. All are Pursuitable via D/FLMIA.
135/4
135/8 HST-9600 Baud
135/10
135/11 Requests honored 0700-0100 EDT; HST-9600 Baud
135/27 1200 only
135/35 1200 only
135/41
XlaxNode emulates almost all of the functions of XlatList,
OpusNode, NLComp, PCPFix, PCPExch, PCPExch2, QNode and ParseLst.
XlaxNode also adds features not found in any of these programs.
Processing is typically two to five times faster than these
programs.
Users of previous versions will find a number of improvements.
Version 2.10 is smaller and, for many options, faster. A number
of bugs have been fixed. QuickBBS and Binkley NodeList.Ext
support has been added. One NodeList.Idx file can be shared by
all three data files. Any or all of the output files can be
created in a single pass.
The nodelists can be tailored, selecting the zones and nets
desired. Output can range from a single net to the entire
nodelist.
Support for multi-zone nodelists has been enhanced. The Opus
1.1x message and call cost fields are supported.
PC Pursuit processing can be enabled or disabled for individual
output files. 2400 baud script support has been improved.
The companion program, XlaxDiff, included in the archive, applies
the weekly NodeDiff update file.
The license permits a thirty day trial period, after which a $10
per node fee is required.
-----------------------------------------------------------------
25 Aug 1988
Start of the Fifth International FidoNet Conference, to be
held at the Drawbridge Inn in Cincinnati, OH. Contact Tim
Sullivan at 108/62 for more information. This is FidoNet's big
annual get-together, and is your chance to meet all the people
you've been talking with all this time. We're hoping to see
you there!
24 Aug 1989
Voyager 2 passes Neptune.
5 Oct 1989
20th Anniversary of "Monty Python's Flying Circus"
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
One free round-trip ticket from Delta Airlines to anywhere Delta
flies in the continental U.S. is about to be given away!
You can have a chance to win this ticket by registering for
FidoCon'88 in Cincinnati before the July 15th deadline!
Your chance to fly Delta free depends upon you! Just complete
the registration form found in FidoNews, from your Net host or on
1/88. If you mail your registration it should be postmarked no
later than July 15th. If you NetMail your registration it should
arrive at 1/88 no later than July 15th.
The winner will be announced at FidoCon. See you there!
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.
Ken Kaplan 100/22 Chairman of the Board
Don Daniels 107/210 President
Mark Grennan 147/1 Vice President
Dave Dodell 114/15 Vice President - Technical Coordinator
David Garrett 103/501 Secretary
Leonard Mednick 345/1 Treasurer
IFNA BOARD OF DIRECTORS
DIVISION AT-LARGE
10 Steve Jordan 102/2871 Don Daniels 107/210
11 Bill Allbritten 11/301 Hal DuPrie 101/106
12 Leonard Mednick 345/1 Mark Grennan 147/1
13 Rick Siegel 107/27 Brad Hicks 100/523
14 Ken Kaplan 100/22 Ted Polczyinski 154/5
15 Jim Cannell 128/13 Kurt Reisler 109/74
16 Vince Perriello 141/491 Robert Rudolph 261/628
17 Rob Barker 138/34 Greg Small 148/122
18 Christopher Baker 135/14 Bob Swift 140/24
19 Vernon Six 19/0 Larry Wall 15/18
2 Henk Wevers 2:500/1 Gee Wong 107/312
Rob Barker 138/34
Chairman, Elections and Nominations Committee
RULES AND PROCEDURES
The next two pages are your Official ballot for the Election of
the IFNA Board of Directors. The following are the few rules
which must prevail in this election:
1. You must send a legible copy of this ballot to the address
listed on the ballot or cast your vote in person at the
conference prior to the closing of the election Polls. It must
be signed and bear your current net/node number.
2. You may vote for any person in your Division for the position
of Divisional Director. This vote is to be cast in the LEFT
column of the ballot.
3. You may vote for any six people for the position of Director
at Large. These votes are to be cast in the RIGHT column of the
ballot.
4. Voting will continue until the end of the Conference
registration on the 25th of August, 1988. Ballots which are
mailed must reach the address listed below prior to Wednesday,
24 August 1988. The results will be read during the opening of
business meeting on the first day of the conference.
5. Write-in votes will be accepted and are requested during this
election.
DIVISION 10:
Jim Bacon 103/507 _____ _____
Courtney Harris 102/732 _____ _____
Steve Jordan 102/2871 _____ _____
DIVISION 12:
Bill Bolton 711/403 _____ _____
Leonard Mednick 345/1 _____ _____
FidoNews 5-29 Page 22 18 Jul 1988
DIVISION 14:
Glen Jackson 100/517 _____ _____
Ken Kaplan 100/22 _____ _____
DIVISION 16:
Vince Perriello 141/491 (1)
DIVISION 18:
Chris Baker 18/14 (1)
ADDITIONAL AT-LARGE
Steve Bonine 115/777 _____
Don Daniels 107/210 _____
Dave Melnik 107/233 _____
Robert Rudolph 261/628 _____
Greg Small 148/122 _____
________________ _________ _____
________________ _________ _____
________________ _________ _____
(1) This candidate has been elected to the office of Divisional
Director with no further voting procedure necessary as per By
Law #11.
"The Nominations and Elections Committee shall delete the name
of any nominee who mayt be ineligible for election and the name
of any who may withdraw by written communications. The
remaining names shall be listed on a ballot, in alphabetical
order. IF THERE BE BUT ONE ELIGIBLE NOMINEE, THE NOMINATIONS
AND ELECTION COMMITTEE SHALL DECLARE HIM ELECTED WITHOUT
BALLOTING BY THE MEMBERSHIP. (Emphasis added. -rb) If there be
more than one eligible nominee, then at least 45 days prior to
the Annual Meeting the Secretary shall send by mail to every
voting member, and publish in FidoNews, a ballot listing the
candidates for director. The ballot shall contain a copy of
the current voting rules."
Name ______________________________ Net/Node ___________
Signature______________________________ Date ___________
Please complete this and mail it to:
Rob Barker
IFNA Elections Committee
7406 - 27th Street West
Suite #7, Plaza West
Tacoma, Wa 98466
or bring it with you when you come to the conference in August.
Membership for the International FidoNet Association
Membership in IFNA is open to any individual or organization that
pays the annual membership fee. IFNA serves the international
FidoNet-compatible electronic mail community to increase
worldwide communications.
Name __________________________________ Date ___________________
Address _________________________________________________________
City ____________________________________________________________
State ________________________________ Zip _____________________
Country _________________________________________________________
Home Phone (Voice) ______________________________________________
Work Phone (Voice) ______________________________________________
Is this a new application? _________ a renewal? ________________
Are you a Sysop? _________ If so, for how long? ________________
Your BBS Info: (Non-Sysops enter info for your most-called BBS)
Zone:Net/Node Number ____________________________________________
BBS Name ________________________________________________________
BBS Phone Number ________________________________________________
Your Special Interests __________________________________________
_________________________________________________________________
_________________________________________________________________
In what areas would you be willing to help in FidoNet? __________
_________________________________________________________________
_________________________________________________________________
Are there any special resources that you could provide? _________
_________________________________________________________________
Regular Membership $25
Lifetime Membership $250
Send this form and a check or money order in US Funds to:
International FidoNet Association
c/o Leonard Mednick, CPA
700 Bishop Street, #1014
Honolulu, HI 96813 USA
IFNA is a general not-for-profit organization. Articles of
Association and By-Laws were adopted by the membership in January
1987. The IFNA Echomail Conference has been established on
FidoNet to assist the Board of Directors. We welcome your input
on this Conference.
The IFNA publications can be obtained by downloading from Fido
1:1/10 or other FidoNet compatible systems, or by purchasing
them directly from IFNA. We ask that all our IFNA Committee
Chairmen provide us with the latest versions of each
publication, but we can make no written guarantees.
System Enhancement Associates SEAdog $60.00 _____
SEAdog price as of March 1, 1987
ONLY 1 copy SEAdog per IFNA Member
Fido Software's Fido/FidoNet $100.00 _____
Fido/FidoNet price as of November 1, 1987
ONLY 1 copy Fido/FidoNet per IFNA Member
International orders include $10.00 for
surface shipping or $20.00 for air shipping _____
SUBTOTAL _____
HI. Residents add 4.0 % Sales tax _____
TOTAL _____
SEND CHECK OR MONEY ORDER IN US FUNDS:
International FidoNet Association
c/o Leonard Mednick, MBA, CPA
700 Bishop Street, #1014
Honolulu, HI. 96813-4112
USA
