informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido0741.nws
root@procul 278a90f7ce Initial commit
2021-04-15 13:31:59 -05:00

1790 lines
84 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Volume 7, Number 41 8 October 1990
+---------------------------------------------------------------+
| _ |
| / \ |
| /|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 1990, 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 the System Operators of the
FidoNet (r) International BBS Network. 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. ARTICLES ................................................. 1
EchoPol Revisited ........................................ 1
Conserve paper with 2 sided printing ..................... 14
Call New York Update #1 .................................. 16
General Elections in Zone 4 .............................. 17
Summary of FidoCon in Zone 5 ............................. 19
Home Schooling Echo on the Backbone ...................... 23
Loglan Language and Echo ................................. 24
MACINTOSH ALTERNATIVE CONNECTIONS LIST (MACLIST) - UPDA .. 26
OTHERNET NEWS ............................................ 29
2. LATEST VERSIONS .......................................... 30
And more!
FidoNews 7-41 Page 1 8 Oct 1990
=================================================================
ARTICLES
=================================================================
Introducing the Old Echomail Policy
George Peace
1:1/0
Many of us have seen the document. Many use it every day to help
us choreograph the flow of echomail. But until a real Echomail
Policy is enacted as a formal Zone 1 Policy, we're all simply
operating the backbone; moderating our conferences; and choosing
our Echomail Coordinators independently, inconsistently, and
without administrative support.
Echopol isn't perfection -- Policy never does seem to be. Some
parts of it give some of us heartburn while others evoke our
applause. What most of us do agree on is the need to enact an
Echomail Policy. The Zone 1 Region Echomail Coordinators have
banded together to offer the April 1989 Echopol to the Zone 1
Coordinator for adoption. I've joined them in this effort after
witnessing and even being part of situations that would have had
a much different outcome if we'd finished the job we started 18
months ago.
So what we've proposed is that the document be adopted as the
Zone 1 General Echomail Policy effective October 22, 1990. For
the first 60 days following its adoption, Zone 1 will operate
under that Policy. During that time, the Zone 1 RECs will accept
our constructive comments and requests for change. Comments and
RFCs will be accepted by any Zone 1 REC in a two part Situation /
Solution format that includes a proposed change to the Policy. At
the end of the 60 day period, the RECs will work with change
submitters, Conference Moderators, and NECs to determine which
solutions/changes will be implemented. A *C/*EC ratification
referendum for the revised EchoPol will be conducted between
January 15 and January 31. If that referendum fails, the Zone 1
Echomail Coordinator will coordinate efforts to submit another
document for ratification.
The document presented here is also available for file request
as ECHOPOL from 1:1/0, 1:157/200, 1:12/12, 1:13/13, 1:114/5,
1:322/1, 1:105/310+311+312, 1:151/1003, 1:382/1, and 1:396/1.
GENERAL ECHOMAIL POLICY 1.0
October 22nd, 1990
FidoNews 7-41 Page 2 8 Oct 1990
PROLOGUE
This document sets forth policy governing Echomail conferences
and their distribution.
If any item in this policy is in conflict with any existing or
subsequent General FidoNet Policy, then General FidoNet Policy
will be in effect.
This Policy applies to Zone One Backbone Echomail conferences and
to any other conferences for which the Moderator desires it to be
applicable.
Future changes to Echo Policy may be proposed by any FidoNet
Sysop by submitting the proposal to their REC. The REC will then
determine if the proposal should be brought before the rest of
the RECs. If an REC decides not to bring a proposed change
before the rest of the RECs, a message stating why must be sent.
If 10% or more of the NCs and NECs in a region request that a
proposal be brought before the RECs then that proposal must be
submitted to the RECs.
A majority vote of the Regional Echomail Coordinators is required
in order for a proposal to be formally voted on. If 10% or more
of the NCs and NECs in the Zone request that a proposal be
formally voted on, then that proposal must be formally voted on.
Those eligible to vote on any proposals made by the REC structure
will be the ZEC, RECs, NECs, NCs, RCs and ZC. Only one vote per
person is allowed. Adoption of changes will require a simple
majority of those voting to pass.
In this document, "a simple majority" means more than 50 percent
of those voting. A good faith attempt must be made to make all
potential voters aware that a vote is occurring and make
available all necessary information.
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, a
national Echomail Backbone formed whose primary purpose is the
distribution of Echomail at a national level. Of recent
introduction to the Backbone system has been the generous
contribution of the Echomail Stars. As a result of the growth of
Fidonet and the increase in the volume of Echomail, it has become
necessary to set forth a formal policy governing Echomail.
FidoNews 7-41 Page 3 8 Oct 1990
II. DEFINITIONS
1. ECHOMAIL: The process of sharing message bases between
independent systems with unique net/node addresses.
2. ECHOMAIL CONFERENCES: An Echomail conference is a message
base of forum design distributed under a specified conference
name dealing with a defined area of interest. Notable examples
include TECH, the National Technical Conference and COMM, the
National Telecommunications Conference.
3. MODERATED CONFERENCE: A moderated conference is an Echomail
conference for which a moderator has been appointed to supervise
the flow and content of the conference. All conferences carried
on the Backbone must be moderated.
4. SYSOP-ONLY CONFERENCE: A Sysop-Only Conference is one in
which the Moderator has decided that the conference will be made
available only to Sysops and not to users.
5. RESTRICTED DISTRIBUTION CONFERENCES: A restricted
distribution conference is one which is restricted only to
eligible recipients. Notable examples include REGCON, the
Regional Coordinators Conference, COORD, the National Echomail
Coordinators Conference, and MAGICK, a pre-register Echomail
Conference.
6. ZONE ECHOMAIL COORDINATOR (ZEC): This individual is
responsible for coordination of Echomail on a FidoNet Zone level.
7. REGIONAL ECHOMAIL COORDINATOR (REC): This individual is
responsible for coordination of Echomail within his region.
8. NET ECHOMAIL COORDINATOR (NEC): This individual is
responsible for coordination of Echomail at the Local Net level.
9. ECHOMAIL Backbone: The Echomail Backbone consists of
voluntary members who provide services to enhance the national
distribution of Echomail. The Backbone consists of nodes which
handle a high volume of Echomail traffic and are responsible for
distribution of Echomail down to the regional level.
10. NATIONAL ECHOMAIL LIST: The National Echomail List
identifies the available national conferences, the conference
moderator and requirements of the specified conference. The ZEC
will appoint the keeper of the National Echomail List.
11. AUTOMATED CENSORSHIP: The term Automated Censorship refers
to programs which cause messages to be removed from the intended
conference or have their content altered.
FidoNews 7-41 Page 4 8 Oct 1990
12. FIDONET POLICY: The document which governs Fidonet as
adopted by Fidonet. The document as of this writing is Policy4
and is subject to change. This policy is intended to become a
part of general Fidonet policy. Until it is incorporated into
General Fidonet policy, this document shall serve to define
policy violations occurring in Echomail.
13. OPEN ACCESS CONFERENCE: This is a non-restricted conference
open to all users who are willing to follow the posted conference
rules.
14. TERMINAL NODE: A system which does not process echomail for
pickup by another system.
III. DUTIES OF ECHOMAIL COORDINATORS
1. GENERAL: It is the duty of the *ECs to make available to any
Fidonet Sysop, any conference which the Sysop is not prohibited
from receiving by not meeting requirements as mandated by the
conference moderator. If for any reason the *EC does not have
access via recognized distribution channels to a specific
conference, they can not be expected to pass it on. If a *EC
fails to make available any conference to qualified lower
distribution levels, this shall be deemed to have violated the
outlined duties of the position held. Such violation is cause
for the removal as provided by this document. Nothing in this
provision requires that a *EC must import any conference to the
extent of adverse economic impact. It is recommended that cost
sharing arrangements be employed. Where financially feasible for
the supplier any conference on the Backbone must be made
available (other than restricted conferences) when requested.
An exception is when a *EC cuts a link to end unauthorized
distribution of a conference. In this case, some otherwise
authorized nodes may temporarily lose their link.
A *EC shall do everything in their power to insure that:
1. All downstream links are educated as to this policy.
2. Downstream links know how to properly link into
conferences.
3. Acceptable and unacceptable behavior in echomail
conferences is explained.
4. Downstream links are not engaging in topologies that
increase the risk of duplicate messages.
2. DUTIES OF ZONE ECHOMAIL COORDINATOR: It is the duty of the
ZEC to coordinate the connections between the Echomail Backbone
on both an inter-Zone and intra-Zone level as well as
coordination of inter-regional connections. The ZEC will
coordinate transmission of Echomail and to provide for routing in
a manner that will avoid the transmission of duplicate messages
FidoNews 7-41 Page 5 8 Oct 1990
within the same conference. It is also the duty of the ZEC to
monitor compliance with this policy on both a national and
international basis.
3. DUTIES OF REGIONAL ECHOMAIL COORDINATOR: It is the duty of
the REC to provide for regional Echomail distribution. In
addition, the REC will coordinate any inter-regional
cross-linking of conference feeds with the REC of the
participating region with the direct knowledge of the ZEC. The
REC will provide for transmission and routing of Echomail within
his/her region in a manner to avoid creation of duplicate
messages within the same conference. It is the duty of the REC
to monitor compliance with this policy at a regional level.
4. DUTIES OF NET ECHOMAIL COORDINATOR: It is the duty of the
NEC to coordinate the intra-net Echomail and to cooperate with
the REC and NECs of other nets to arrange for the inter-net
transmittal of echomail. The REC may require the NEC to provide
links for independent (regional) nodes. The NEC shall maintain a
list of available Echomail Conferences within the net as well as
the requirements of each Conference area as supplied by the
conference moderator (Echolist). The NEC shall also monitor
compliance with this policy at a net level.
5. DUTIES OF ECHOLIST COORDINATOR: It is the duty of the
Echolist Coordinator to compile and make available a listing of
national and international Echomail conferences and optionally,
conferences at various local levels. The content and format of
the Echomail listing shall be at the sole discretion of the
Echolist Coordinator, but shall include the conference name and
moderator for each conference. The Echolist Coordinator shall
also maintain a list of requirements applicable to each listed
conference.
6. DUTIES OF ECHOMAIL CONFERENCE MODERATOR: It shall be the
duty of the Echomail Conference Moderator to make in good faith
every reasonable effort to insure that the moderated conference
does not distribute or promote illegal activities or information
as defined below in Section V Paragraph 2. The Moderator shall
be responsible for insuring that messages contained in the
conference corresponds to the conference theme. The Moderator
shall report any violations of this policy to the proper Echomail
coordinators and lodge any appropriate policy complaints as
provided for in policy documents adopted by Fidonet. The
Moderator shall post the conference rules in the conference at
least once a month. The Moderator is to authorize the
disconnection of the conference feed. Any Sysop the moderator
believes is violating policy shall be reported to the offending
node's nearest local echomail coordinator (may be a NEC, REC or
in extreme situations a ZEC); and the moderator shall formally
authorize the feed to the offending node to be severed. The
conference moderator is the sole judge, subject to review only by
the ZEC (or his delegates), if a complaint is filed by the
banished party. The Moderator may request in direct written form
(netmail) that the *ECs disconnect a node from the conference
when that node refuses to follow the published conference rules
FidoNews 7-41 Page 6 8 Oct 1990
after at least 3 warnings. Knowingly feeding a conference to a
node that has been severed by the Moderator is considered a
violation of this echomail policy and is subject to suspension.
The length of this suspension will be determined by a joint
decision of the conference moderator and the nearest local echo
coordinator of the node illegally feeding the conference to the
original offending node or point.
Echo conference complaints from a Sysop should be filed at the
net level (NEC) or if the complaining party is an independent
node then with their REC. The NEC or REC receiving such a
complaint must take action in accordance with the provisions of
this echomail policy.
For severe or chronic infractions the NEC, REC or ZEC may file a
complaint under general Fidonet policy for excessively annoying
behaviour.
IV. APPOINTMENT AND ELECTION OF ECHOMAIL COORDINATORS AND
MODERATORS
1. GRANDFATHER CLAUSE: Those Zone, Regional, and Net Echomail
Coordinators and Echomail Coordinators currently holding these
positions as of the date of acceptance of this Echomail Policy
shall continue to serve in said capacity until resignation or
replacement under this policy.
2. ELECTION OF ZONE ECHOMAIL COORDINATOR: The ZEC shall be
elected as follows:
a) upon resignation or replacement of the existing ZEC,
the FidoNet Zone Coordinator (ZC) shall nominate at
least five individuals to be voted upon.
b) 10 days after the nominees are selected, an election
shall be held. The ZEC will be elected by a simple
majority of IC, ZC, RCs, NCs, RECs, and NECs in their
Fidonet zone. An individual holding more than one
position can only cast one vote. That is, if an
individual is both a NC and a NEC, they may cast only
one vote.
3. ELECTION OF REGIONAL ECHOMAIL COORDINATOR: The REC shall be
elected as follows:
a) upon resignation or replacement of an existing REC,
the ZEC shall nominate at least 3 individuals for
election.
b) 10 days after the nominees are selected, an election
FidoNews 7-41 Page 7 8 Oct 1990
shall be held. The REC will be elected by a simple
majority of the RC, NCs and NECs in their FidoNet
Region. An individual holding more than one position
may only cast one vote.
4. NET ECHOMAIL COORDINATOR: The NEC shall be appointed by the
FidoNet Net Coordinator (NC) or in such alternative manner as
determined by the NC. If a NEC is not appointed within 30 days,
the REC will appoint the NEC.
5. REMOVAL OF A *EC: A *EC may be removed from their position\
by a simple majority of those allowed to vote for their
successor. For a NEC, the members of the Net may vote by simple
majority to remove the NEC. The position directly above (in the
*EC structure) will oversee the recall election in the same
manner as prescribed for electing successors.
A *EC may only be subject to recall for failure to properly carry
out their duties described above, or if they are no longer a
member of Fidonet. A promise of 'free' echomail delivery from
another source is *not* considered an acceptable reason for
recall.
A *EC may be removed by the level above for continued violations
of policy or for gross misconduct.
6. RECOGNITION OF CONFERENCES: The *EC corresponding to the
appropriate level recognizes a conference at his level.
Examples: The NEC recognizes a conference as local. The REC
recognizes a conference to be regional. A ZEC recognizes a
conference to be zonal.
7. REMOVAL OF AN ECHOMAIL CONFERENCE MODERATOR: An Echomail
Conference Moderator may be removed from their position by a
three fourths (3/4) vote of the *EC structure voting. This vote
must be carried out in a fair and decent manner while giving at
least ten (10) days notice to the entire *EC structure of the
upcoming vote.
The ZEC shall notify the RECs who in turn shall notify the NECs
in their region of any upcoming vote. Notice must be given via
NetMail. Additional postings in such conferences as COORD and
regional conferences are encourgaged.
An Echomail Conference Moderator may only be subject to recall
for failure to properly carry out their duties described above or
continued pre-meditated violation of this documents section V.
Statement of Policies as seen below. Failing to perform the
above duties of a conference moderator for a period of 3 or more
months and/or failing to designate a proxy in his absence shall
be in violation of this policy and be subject to recall. A vote
may only be callable by the ZEC (or his delegate). This delegate
should not be from the region or net of the affected conference
moderator.
FidoNews 7-41 Page 8 8 Oct 1990
Membership in Fidonet need not be a paramount issue, but is
highly recommended.
V. STATEMENT OF POLICIES
1. BASIC ECHOMAIL POLICY: The basic policy of Echomail is to
promote communication in Echomail Conferences in a lawful,
friendly manner consistent with the general principles of
FidoNet.
2. PROHIBITION ON ILLEGAL ACTIVITIES: Any Node which knowingly
distributes or allows to be entered into echomail conferences any
messages containing or promoting illegal activities or
information shall be deemed to have violated general FidoNet
policy as being excessively annoying. 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. AUTOMATED CENSORSHIP: The use of Automated Censorship in the
passing or distribution of echomail will be considered a
violation of this policy and will not be tolerated. Disciplinary
action will be as referred to in General Fidonet policy as being
excessively annoying.
An exception to this provision shall be the deletion and not
censorship of messages by any Sysop which may lead to legal
action against that Sysop.
No echomail shall be modified in any manner which could
potentially cause duplicates.
4. INTER-NETWORK CONFERENCES: Inter-Net conferences shall
conform to general Fidonet policy as well as the provisions of
this policy document in addition to any foreign network's
provisions. Conferences which originate outside of FidoNet must
be designated as such in the list of conferences kept by the
Echolist Coordinator.
5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit
from the distribution (passing from system to system) of echomail
shall be deemed to be excessively annoying and in violation of
Fidonet policy subject to enforcement under existing Fidonet
policy. Profit as defined in this paragraph is the charging for
echomail distribution that exceeds 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. A Sysop that charges
users for access to their BBS shall NOT be in violation of this
paragraph.
FidoNews 7-41 Page 9 8 Oct 1990
Implementation of cost recovery plans may vary greatly. In
general cost recovery plans should not be overly restrictive.
6. RESTRICTED DISTRIBUTION CONFERENCES: Participating Nodes
shall honor and support the restrictions placed upon restricted
distribution conferences. Violation of this restriction by
individual nodes and points shall be a violation of this echomail
policy and result in suspension of the violated echo in
accordance with the above paragraph in Section III Duties of the
Echomail Conference Moderators.
A Sysop-only conference shall be made available only to the
Sysops or Co-Sysops of Fidonet or other nets with which inter-net
conferences exist.
A violation of the restrictions placed on a RESTRICTED
DISTRIBUTION CONFERENCE will be a violation of this policy if and
only if the moderator has posted and specified the restrictions
governing the conference.
7. PATHLINE OPTION: The PATHline (as defined in FTS-0004),
originally implemented by SEA in the MGM package, is recommended
for all nodes. If your current Echomail scanner supports the
pathline you should enable it. While the pathline does not
eliminate duplicate messages, it can be a very useful tool in
determining where a topology problem exists.
Systems operating as Echomail Stars, Backbone nodes, or Echomail
Hubs must implement the PATHline option (as defined in FTS-0004
within 30 days of adoption of this policy. Since these system
are operating beyond the scope of the typical FidoNet system,
they are required to implement features that are otherwise
optional.
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 respective ZECs feel topology will allow their
use. Nor will the stripping of SEEN-BYs (except Zone-Gates and
Inter-Network EchoGates) be allowed unless approved by the ZEC.
Violation of the above shall be excessively annoying behavior
enforceable under general Fidonet policy. Zone-Gates and Inter-
Network EchoGates SHOULD strip the SEEN-BYs of the exporting Zone
or Network to reduce addressing conflicts.
9. COUNTERFEIT MESSAGES: Entering or knowingly distributing
counterfeit messages shall be considered excessively annoying and
a violation of Fidonet policy enforceable under the terms of
Fidonet policy. As used in this paragraph, 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.
FidoNews 7-41 Page 10 8 Oct 1990
10. SYSOP'S RESPONSIBILITY: It is the responsibility of each
Sysop to make every reasonable effort to assure that the users on
his board conform to the provisions of this policy document. A
Sysop may be held responsible for the acts of his users unless
the Sysop can show that a reasonable attempt was made to conform
to this policy document.
11. ECHOMAIL SOFTWARE: Echomail software which does not conform
to the minimum acceptable standards as defined by the Fidonet
Technical Standards Committee (FTSC) shall lead to disciplinary
action as described previously in this document.
12. HOST ROUTING OF ECHOMAIL: Host routing of Echomail without
the prior consent of both the Sending and Receiving Hosts shall
lead to disciplinary action as described previously in this
document. See Section III.
13. INTER-NETWORK CONFERENCES: It is the general policy of
Fidonet to encourage the development of INTER-NETWORK
CONFERENCES. It shall be the duty of those providing the
INTER-NETWORK CONFERENCE links to remove foreign net distribution
identifiers which will adversely effect the distribution of the
Echomail Conference while in Fidonet. The INTER-NETWORK
CONFERENCE links maintained in Fidonet shall be operated in a
manner not to interfere with the foreign network's distribution
of Echomail. INTER-NETWORK CONFERENCE links maintained in
FidoNet must also conform to General FidoNet Policy.
14. DEFAMATORY POSTING: The posting of any DEFAMATORY MESSAGE
other than in conferences dedicated to this purpose (i.e. FLAME)
shall lead to disciplinary action as described previously in this
document. See Section III. The posting of substantiated facts
shall not be considered a violation under this section.
15. ADDING OR REMOVING CONFERENCES FROM THE BACKBONE:
A conference may be added to the Backbone only at the request of
the RECOGNIZED Conference Moderator. A conference must be
registered with the Echolist Coordinator before it can be added
to the Backbone.
A conference may be removed from the Backbone by lack of traffic.
The recognized conference moderator may, at their discretion,
request removal from the backbone any conference that same
moderator initially placed in backbone distribution.
16. TOPOLOGY and DUPLICATE MESSAGES: Cross Regional links
should be avoided as they increase the risk of improper linking
and generation of duplicate messages. Cross Regional links may
only be established with the knowledge of the REC in both
regions. The REC must be notified prior to or at the time of the
link being established. If an REC determines that a cross
regional link is contributing to the creation of duplicate
messages, the REC may request that the link be terminated.
FidoNews 7-41 Page 11 8 Oct 1990
The use of the PATHline option is required for all out of region
links.
If a sysop has a prior history of creating duplicate messages
because of out of region links, the REC may require prior
notification and approval before an out of region link can be
established.
Cross Regional links are permitted without notifcation if one of
those systems is a dead-end. Should the status of this link
change, then notification is required.
Each REC will do their best to make available high speed hubs,
out of state hubs, PC Pursuit hubs, etc, to facilitate the low
cost, efficient movement of mail within their respective Region.
Any Sysop who willfully and knowingly establishes links that
either create duplicate loops (topology that creates circular
feeds) or who refuses to break such links upon request by their
NEC, REC or ZEC shall be subject to disciplinary action as
described previously in this document. See Section III.
17. MESSAGE STANDARDS: Until the adoption of a superceding
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) Origin lines should be limited to 79 characters
including the required ending of a proper network
address (i.e. Zone:Net/Node.Point with zone and point
being optional).
c) Tear lines should be limited to 35 characters
including the required "--- " lead-in. These 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.
d) "Extra" origin lines (ZoneGating) are limited to
essential information only. This consists of the
required lead-in plus the network name "Gateway" and
optionally the software ID followed by a Zone:Net/Node
FidoNews 7-41 Page 12 8 Oct 1990
address. Example: " * Origin: FidoNet Gateway (TComm
88:372/666)"
e) SEEN-BY addresses should be in sorted order.
Multiple 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.
VI. ENFORCEMENT
Enforcement of this policy document shall be under the provisions
of General FidoNet policy. Complaints concerning Echomail
violations defined under this policy may be filed by the
aggrieved individual, the conference moderator or by any level of
Echomail Coordinator to the appropriate *C level. All complaints
made pursuant to this policy 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
respective *EC.
Enforcement is immediate, with any currently existing software
allowed 60 days to conform (from the date EchoPol1 goes into
effect). A 30 day extension 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
shall be deemed excessively annoying.
VII. ADOPTION OF POLICY
1. ADOPTION: This policy shall become effective upon
ratification by a simple majority of those voting. Those
eligible to vote shall be the IC, ZCs, RCs, NCs, ZECs, RECs, and
NECs. Those individuals holding more than one position can cast
only one vote.
2. GRANDFATHER CLAUSE: Within 60 days of adoption of this
policy, moderators shall be appointed for all existing Echomail
Conferences which do not now have a moderator. Moderators shall
be appointed by the ZEC from those volunteering as moderator or
if no volunteer is available then the ZEC shall request and
appoint a moderator for the conference. In the case where more
than one individual claims to be the conference moderator and no
agreement can be reached, the ZEC may order the conference
retired and ban the further use of the specific conference name.
Failure of the individuals to retire the conference name shall be
deemed excessively annoying behavior.
FidoNews 7-41 Page 13 8 Oct 1990
VI. BACKBONE STRUCTURE
This section is for information purposes only. It gives a plain
English description of the current structure and operation of the
Backbone. The ZEC may change this structure without amending
this document.
At the top of the Echomail distribution network, there are
systems commonly called Stars. These systems are usually
dedicated to passing Echomail. The stars operate at the
discretion and direction of the ZEC. At the time of this writing
there are 3 stars, each has a backup system/plan in the event of
a failure. In general, the Stars link to one another and feed the
RECs.
The RECs are then responsible for distribution of the echomail
within their Region. Normally, the REC will feed the NECs in
that region.
The NEC is responsible for distribution of Echomail to the
individual Sysops within a net.
Note that the RECs and NECs can appoint Hubs to help in the
distribution of Echomail. That is, they do not have to directly
feed the lower level.
This is the distribution GOAL. Because of less expensive phone
rates and other reasons, this distribution method is not followed
exactly. Any change to the above requires agreement of the *EC's
involved. All *ECs will use all the tools at their disposal,
such as hubs, high speed modems, ROA, Wide Area Calling plans, PC
Pursuit, corporate sponsorship, etc., to provide fast, efficient,
and cost effective movement of echomail.
Echopol Committee
Mike Ratledge
Norm Henke
Rick McWilliams
Barry Shatswell
-----------------------------------------------------------------
FidoNews 7-41 Page 14 8 Oct 1990
Dave "who likes to jump out of airplanes" Appel
Just a user on 1:231/30
[bych mode on]
Personally, I'm getting sick and tired of all the non-
computer-related articles appearing in FidoNews. Especially
the ones by the eco-freaks, the left-wing-commie-pinko-
conspiracy-theorists, either side of the abortion issue, and
30K .GIF files of some stranger's ugly mug. (However, an
occasional missing child announcement is fine by me.) If you
can't relate it to computers, or the network, find someplace
else to publish it, please. I even prefer bashing/defending
the editor about LHARC versus ARC than the completely off-topic
junk.
[bych mode off]
Well, here's how conservation CAN be applied by computer
users. Print on both sides of the paper.
As an arch-conservative anal-retentive capitalist pig I
see it as a way to save dollars on my paper costs. Bottom
line, you know. For you tree-hugging vegetarian
environmentally correct eco-geeks, you might even save a few
trees so you can continue your smug sense of moral superiority.
There are several utilities that are specific to certain
printers or to certain word processing packages. There are
even utilities to split text files into 2 files, one containing
odd-number pages, and the other containing even-number pages.
An example of such an "evironmentally conscious" (cost
conscious to me) utility is 4PRINT for the HP LaserJet. It
prints 4 66-line pages per sheet of paper, 2 each, front and
back. You have to run the paper through twice. It's shareware.
Some word processors such as XYWRITE have built-in macros
for printing odd and even pages.
The LaserJet IID prints on both sides of the paper, but
not many people have these printers. For the rest of us, we
need to print the odd pages, turn the paper around, feed it
back into the printer, then print the even pages.
The lazy way that I used to print documentation was to:
COPY myfile.DOC LPT1
Since I decided to do double sided printing, I always
bring the doc file into my word processor and print it from
there, where I have control over which pages to print.
MS-Word 5.0 doesn't have a built-in macro to do this so I
wrote my own. Here it is:
FidoNews 7-41 Page 15 8 Oct 1990
<Ctrl PgDn><up><up><Ctrl Esc>jp[SET lastpage = field]<Esc>
[ASK pageno=?Enter starting page]
[WHILE pageno <= lastpage]
<Ctrl Esc>po<down><down><down><down>p<right>[pageno]
<enter><enter>
[SET pageno=pageno+2]
[ENDWHILE]
You need to substitute the "[" and "]" symbols with the
chevrons by pressing Control-[ and Control-]. (The chevrons
are special characters, 174 and 175, that ARTSPEC.DOC says not
to include in FidoNews articles.) You can store this macro in
your macro glossary. Load your paper, run the macro, tell it
page "1", when the printing is done, reload the paper
backwards, run the macro, tell it page "2".
If you do everything right, and your printer doesn't jam,
you just cut your paper usage in half, with only about an extra
42.5 seconds of effort. If something goes wrong, like a
printer jam, or you re-edit the document in between printing
the two sides (thereby shifting the page breaks), you just
screwed up the whole thing, wasted even more time, and wasted
more paper than you were going to save in the first place.
Another benefit of two-sided printing is that when the
document becomes obsolete, you aren't tempted to keep it around
as clutter hoping to someday use the blank side as scrap paper.
You can chuck the whole thing with the satisfaction of knowing
that you squeezed every last use out of it, or you can even
(*gasp*) recycle it.
-----------------------------------------------------------------
FidoNews 7-41 Page 16 8 Oct 1990
Ronnie Toth
FidoNet 1:135/71
October 3, 1990
** CALLNY Update **
We've done it!
CALLNY is on the FidoNet backbone now and all you have to do is
pester your wonderful NEC to get it for you! He can then pester
his/her also wonderful REC and there you are! You can be in New
York too!
TAG: CALLNY
Topic: Anything New York
Moderator: Ronnie Toth FidoNet 1:135/71
We will be listed in ELIST011.
For those who called the two originating systems, thank you.
This should make it simple for all.
An official thank you goes to:
Ray Vaughan who started the whole ball rolling
Michele Hamilton who taught me how to go about echo-making and
assisted whenever needed. (Lots.)
Amnon Nissan who freely gave words of encouragement
John Cottrell More words of encouragement
Fabian Gordon More words of encouragement and the spreader
of the word up NY way
Roger Bonenfant Our first actual NY link, (even though he's
in NJ)
Thank you one and all. See ya in NY!
Ronnie
-----------------------------------------------------------------
FidoNews 7-41 Page 17 8 Oct 1990
Pablo Kleinman
FidoNet 4:4/0
General Elections in Zone 4
Elecciones Generales en la Zona 4
Eleicoes Gerais na Zona 4
As the result of an agreement reached by ZC4 and the rest of
Zone 4's coordinators, on November 9th 1990 the members of
FidoNet Zone 4 "Latin America" will be able to vote for the
renovation of the whole coordination structure of the zone, and
elect Network coordinators, Region coordinators and Zone
coordinator.
The procedures defined for the democratic election process are
the following:
- All the FidoNet members will be able to present themselves as
candidates to a single coordination position, by sending netmail
to Elecciones at node 4:4/444 until October 20th, stating the
position they intend to run for.
- On October 21st, the list of all candidates will be published
on the official echomail conference LATIN.SYSOP and on October
22nd, on FidoNews. From then until the voting closes on November
9th, 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 October 22nd until November 9th, all the members of
FidoNet Zone 4 will be able to vote for the different candidates
-voting for a someone that is not a candidate will void the
entire ballot- for the domain where the member is registered (for
example, a FidoNet member in Net 900 can vote for NC 900, RC 90
and ZC 4), and they will do so by sending a message to Elecciones
at node 4:4/444, whose subject will be a special "secret
password" and the text will indicate the different choices. 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: Pedro Picapiedras (4:900/789) |
To: Elecciones (4:4/444) |
Subj: piedradura <----------------| text
|
NC: Johny Tolengo <---------------------|
RC: Isidoro Canones
ZC: Juancho Lagarto
- The results from the election will be published on November
11th on the official echomail conference LATIN.SYSOP and on
November 12th on FidoNews. A comprehensive list with every ballot
listed, to grant the accurateness of the results, will be posted
on November 11th on the echomail conference LATIN.SYSOP. This is
an example of how a ballot will be published in the comprehensive
list:
FidoNews 7-41 Page 18 8 Oct 1990
Password NC RC ZC Status
-----------------------------------------------------------------
piedradura J.Tolengo I.Canones J.Lagarto OK
|
will say "VOID" if the ballot is not correct-----------|
- The newly elected coordinators will take over their new
positions with the nodelist update of November 16th.
Pablo Kleinman
Latin American FidoNet Coordinator
Buenos Aires, October 3, 1990
-----------------------------------------------------------------
FidoNews 7-41 Page 19 8 Oct 1990
Niel Uys
FidoNet 5:5/200
FIDOCON 1990 - ZONE 5
Held on 7 September 1990 to 9 September 1990
It is with great pleasure, that I will try and give you a
summary of what actually happened at FidoCon 1990! Yes, you
would ask, what was the fuzz all about, but let me tell you, it
was a great thrill to meet and actually see the faces behind the
messages, that we so often take for granted.
First and foremost, I would like to thank Grahamstown, and
particularly the Rhodes people, for their hospitality, and all
the arrangements they made, to please all the delegates, that
attended the convention...the very first held on the African
continent!
At 08:00, we all got registered for the convention, and everybody
start to take there seats, while the camera-man puts up his video
equipment to record everything to be said and done.
First of all, we had Henk Wolsink, our Zone 5 Coordinator,
opening the very first convention, in Zone 5. He introduced
himself, and mentioned the fact that two speakers couldn't make
it. They were Anthony Walker and Stephan Davies. Fortunately,
Anthony knew beforehand, that he would probably not make it, and
made a video tape, for all to watch, during the convention. He
was also the chairman for the first session till tea time.
He then talked a bit about the history of FidoNet, and particular
, how it started in Southern Africa. He also mentioned how
FidoNet grew throughout the world, and how it affected sysops in
Zone 5.
Then he introduced the Grand Daddy of FidoNet Zone5, Bryan
Haefele, who gave a thorough speech about the history of FidoNet
in the now called Zone 5 area. It is just a pitty that this
speech was not recorded properly, as the sound of the video
camera, was not on for this and the next session...but never the
less, the people that were there, would hopefully not forget the
history lesson.
Pat Terry, better known to his students as Professor Terry, gave
us a very in depth insight on UFGATE, and how the interfaces
between UNIX boxes and FidoNet works. He also talked about the
specific connections between zone 1 and zone 5, where Randy Bush
was providing the porting of UNIX networks to the zone 1
zonegate, then sending it to Rhodes, using the normal FidoNet
dial-up links.
FidoNews 7-41 Page 20 8 Oct 1990
Then we had tea...and I got lost while trying to find the lecture
room again :-)
After tea, and discovering that the camera failed to record sound
of the previous session, Pat Terry, the chairman of the second
session, introduced Randy Bush, the main speaker of the
convention.
Pat mentioned about his relationship with Randy, and how he got
stuck into Modula-2, first with the Apple II computers, and
later the bigger buggers.
Randy started off with, a bit of history (again:-) on FidoNet,
but talked about Tom Jennings, the father of FidoNet, and how
FidoNet started, with his program called Fido (because it was
such a dog of a program <grin>). Randy mentioned when he got
involved, and mentioned Ben Baker, also one of the pioneers of
the olden days.
He talked about how regions, and later zones started all over the
world, to reduce cost mainly as well as to make distribution more
effective. Echomail was also mentioned and how the first echo's
came about.
IFNA was also mentioned, and what the reason was, why it was
started. Echomail wars also started, and IFNA eventually
collapsed.
He then mentioned the fact that many non-clone machines were used
to port FidoNet software, and those users writing their own
software, etc.
Politics power and policy, is probably one of the biggest
problems in FidoNet, Randy mentioned. Zone 5 will have to get
more countries connected, so as to change perspective of the rest
of the FidoNet world.
He talked about all the various zones, and how they operated.
Also the fact that zone 3 will split up in to zone 3 and 6 in a
friendly manner, also to concentrate the mail links, etc. Zone 4
has a big problem financially, while zone 2 seems the most
organised.
He then also talked about various other networks, and the fact
that FidoNet addressing, were not very intelligent, compared to
UUCP, etc. For instance, sending a message to
USA.ORIGON.PORTLAND.RANDY would make more sense, than sending
it to 1:105/42! This makes sense to me, but might not to others,
etc.
Bitnet, was for instance based on the IBM proprietary protocols,
using 7 bit data bytes, etc. USENET is not a network, and all
networks receiving USENET news files, actually belongs to USENET,
like FidoNet!
FidoNews 7-41 Page 21 8 Oct 1990
Internet was also discussed, and RFC's a bit explained, as well
as the current FTS documents, which are to become RFC's
eventually.
Vic Shaw, of the FRD, was then summoned to give his talk on
Uninet. He explained, that the relation between Uninet and
Fidonet was excellent. Uninet's mission is to, development,
implementation and promotion of an academic and research computer
network in Southern Africa. This means, that it's intended for
use by Universities, and higher education institutions, etc.
This network, is of course sponsored by the FRD (Federation for
Research and Development).
He then gave credit to FidoNet, which made UNINET into what it is
today, although, FidoNet (Zone 5) got quite a few benefits,
financially, from Uninet as well.
Anthony Walker's tape was then played, where he gave us a chat
about his COMNET system, and how it is interfaced with BELTEL,
the local prestel dailup system, operated by the P&T.
We all, then partook in a general discussion, about FidoNet in
general, and ways and means in expanding FidoNet, to the lower
levels, like schools, etc.
Lunch was then served at the 1820 Settlers Monument building.
The Chairman for the afternoon, was Dave Pedler, who is the
region 49 Coordinator. He introduced himself, and talked about
how zone 5's *C sysops were elected and appointed, when Zone 5
got off the ground in September 1989, etc.
Henk Wolsink, our Zone 5 Coordinator, was then called to give his
talk about Zone 5, and how it started, etc. The discussion then
also turned to why and when points and super users (users using
Silver Xpress or XRS) are used, the pros and cons thereof.
I then stepped in to give a chat on how echomail links are
connected throughout Zone 5 and the rest of the world. We also
discussed a bit of history on Zone 5, and what made echomail to
be 'magic'.
All Zone 5 *C sysops then gathered at the Hotel (Not to drink
:-), but to discuss various aspects of the network, mostly
difficult to sort out over the network itself.
1. We basically decided that Henk should keep on being the ZC
for Zone 5 for another year, unless someone has a complaint
about him:-)
2. We also decided, not to allow a Beltel gateway for FidoNet,
FidoNews 7-41 Page 22 8 Oct 1990
unless it is going to be READ-ONLY on the BELTEL side.
3. Changing of echo tags like ECHOMAIL, which was always
confusing to users.
4. We also decided to follow Randy Bush's advice in changing
pick-up and poll times for echomail, excluding the zonegate.
This will have a drastic effect on the turnaround time of
all echomail in Zone 5.
We then drank ourselves, under the table, while the other crowed
looked at the Rhodes computer equipment, until the dinner in the
same Hotel. No, not really, we just sat there waiting for them
:-)
And so the day came to a halt? No, we still had a very nice
dinner, and it carried on till very late. We had some photo
sessions, we even had food! Very nice too, although, I can't
remember what we ate, as it was more interesting to chat to each
other, about...PC's and computers and FidoNet and BBS's...what
else? :-)
Anyway, to rap it up, I personally think it was a great success,
and I would like to thank each and everyone, attending FidoCon
1990. I sure hope to see you all, and many more, with the next
FidoCon.
Also great thanks to Rhodes, for hosting the convention, and for
the FRD, who sponsored Randy's visit to our Zone. Also many
thanks to Randy to take the trouble in getting the FidoCon...
great to have had you here, Randy!
-----------------------------------------------------------------
FidoNews 7-41 Page 23 8 Oct 1990
C.Lee Duckert & Bruce A. Casner
FidoNet 1:139/600
HOMESCHOOL - WHO WOULD DO THAT!
A Home Schooling Echo Conference (HOMESCHL) is available on the
backbone. There are many reasons for educating children at home.
In fact, there are more reasons for educating children at home
than there are parents.
Who teaches their children at home? There are families who
travel or are living overseas. Some think there is too much or
too little religion in the public schools. Some live too far out
even for school buses to reach them. Still others think that
learning and education are two separate activities. Large
families, families with an only child, single parents, the rich,
the poor, professors and high school drop-outs, atheists and fun-
damentalists, capitalists and socialists --- the only things
homeschoolers seem to have in common is a particularly strong
(but varying) view of the importance of their families and a com-
mitment to that oldest form of education - learning at home.
The laws regarding home schooling vary from state to state and
are always changing. Basically, it is legal. Some localities
require curriculum plans filed with school boards and overseen by
certified teachers. Others only require an attendance sheet
(after all, only school attendance is mandated). Alaska provides
home schools with materials and California provides assistance
from the local school district; but in most states, you are on
your own. Some states require testing or external evaluations.
Children who re-enter traditional schools have been doing quite
well.
This echo is available for all who wish to share ideas, support
one another, ask questions and answer them, adults and
"students". Child development issues, curricula and methods of
dealing with the legal requirements from state to state have all
come up for discussion. (Arguments about religion, politics not
relating to homeschool issues or the role of public education
already have their own echoes and need not call in here.) If you
have a child, may some day have a child, know a child or were a
child and ever learned or wished to learn anything, homeschooling
might interest you.
There have been several local echoes across the country dealing
with home schools and we are trying to unite them. Voice mes-
sages can reach us in the evening (Central Time) at (414)722-
4046.
-----------------------------------------------------------------
FidoNews 7-41 Page 24 8 Oct 1990
Rob Duff
FidoNet 1:153/713
Loglan Language, Loglan Echo
I recently became involved with learning the Loglan language
and I decided to support the Loglan Institute by submitting an
article about the language in FIDONEWS. James Cooke Brown, the
creator of Loglan has given me permission to upload the
following article. I have also created a one node ECHO for "lo
logli" (loglan people) called as you probably guessed LOGLAN. It
is available at 1:153/713.
I first heard of Loglan in R.A.Heinlein's book "The Moon Is
A Harsh Mistress". When I saw their advertisement in Scientific
American magazine, I immediately called the Institute and asked
for a price list. When the list came I sent away for just about
everything. I am now in the process of learning the language.
If you are interested in Loglan, please contact me or the
Institute.
Rob Duff 1:153/713
What is Loglan?[1]
Loglan[2] is a speakable, human language originally designed
to serve as a test of the Sapir-Whorf hypothesis that the
structure of local human languages places local constraints on
the development of human thought, and hence, on human cultures.
If this hypothesis is correct, a language which "lifted" those
constraints--that is to say, which reduced them to some formal
minimum--should in a certain sense "release" the human mind from
these ancient linguistic bonds and, in any case, have notable
effects on both individual thinking and on the development of a
global human culture.
Since its original development in the late 1950's and 1960's
Loglan has acquired certain other properties that make it
interesting to computer science, principally (1) its total
freedom from syntactic ambiguity. This feature of the language,
together with with (2) its audio-visual "isomorphism" (which
means that the Loglan speechstream breaks up automatically into
fully punctuated strings of separate words) and (3) its
borrowing algorithm (by which the International Scientific
Vocabulary goes into Loglan virtually ad libitum) makes it an
ideal medium for three uses: (i) for international information
storage and retrieval, (ii) for machine-aided translation
between natural languages, and (iii) for spontaneous
interaction between computer-users and their machines. Finally,
Loglan is (4) culturally and politically neutral in the sense
that its basic predicate vocabulary has been engineered to be
maximally memorable to speakers of the eight most widely spoken
languages: English, Chinese, Hindi, Russian, Spanish, French,
Japanese and German.
FidoNews 7-41 Page 25 8 Oct 1990
All these features taken together have suggested to many
loglanists that their adopted language is ideally suited to
become a second language for the world. For others, conducting a
scientific test of the Whorf hypothesis with Loglan has the
highest priority. For still others, its use at the
human/machine interface is the most challenging role for Loglan
in the years ahead.
[1] Reprinted with permission
[2] Loglan is a registered trademark of
The Loglan Institute, Inc.
Books, software, tapes, membership in the institute,
and other items are available from:
The Loglan Institute, Inc.
A Non-Profit Research Corporation
1701 Northeast 75th Street
Gainesville FL 32601
U.S.A
(904) 371-9574
-----------------------------------------------------------------
FidoNews 7-41 Page 26 8 Oct 1990
Ralph Merritt
1:269/102
Tom Heffernan
1:107/554
On October 27, 1989, a new, MacIntosh oriented network was
formed. Named the 'MacIntosh Alternative Connection List',
MACLIST was established in the last remaining single-digit
Zone address, Zone 6.
The current MACLIST nodelist is available to all interested.
Just file request 'MACLIST.ARC' from 1:107/554 or 1:269/102.
Why was MACLIST formed? There are several reasons we decided
to form the MacIntosh Alternative Connection List. Here are
some that inspired us to form MACLIST:
o The MacIntosh is rapidly entering the world of computer
networking. MacIntoshes are located in many different
networks, but how to find them? The MACLIST nodelist
is a centralized source for you to communicate with
other MacIntoshes - simply compile the MACLIST nodelist!
o The MacIntosh community has many unique aspects. The
MACLIST is a network for Mac sysops, and their users,
to join together and address MacIntosh issues that
affect us all, examine the technology, discuss topics
and disseminate information of interest to the
MacIntosh community.
o Need a MacIntosh echo connection? Files? Looking for
'Mac compatibility' (SEAlink transfer protocols and
WaZOO FREQs)? Check MACLIST for a system near you ...
the MacIntosh Alternative Connection, an independent
network on the move.
If you are running a MacIntosh system, or a system dedicated
to MacIntosh users (the MACLIST is not necessarily composed
100% of systems that are physically running on MacIntoshes,
but a member must have a system dedicated/oriented to the
MacIntosh user), and are interested in joining the MACLIST,
please contact one of us at our addresses listed below!
If you are interested in MACLIST, you might want to get a
MACSYSOP feed to keep in touch with other Mac sysops. In
the summer of 1990, MACSYSOP was added to the "Fidonet
Backbone", so it should be available in your local network.
If it is not, please contact one of us below and we'll help
you locate a source. You do not have to carry MACSYSOP to
be a member in MACLIST.
FidoNews 7-41 Page 27 8 Oct 1990
Here are our answers to some of the questions we have been
receiving:
Q: Why did you chose Zone 6 for MACLIST?
A: The Tabby mailer for the MacIntosh does not have the
capability to use two-digit zone addresses. We therefore
do not have a choice in Zone selection. Zone 6 is the
last remaining unoccupied single-digit Zone address, and
we do not wish to intrude on another network's Zone or
encounter the technical problems associated with a
'shared Zone'. It is our hope that 'Other Nets' will
respect our position and recognize why MACLIST is
occupying Zone 6. After Tabby 3.0 is released September
30th, 1990 and is being generally used, we will move to
another Zone as Tabby 3.0 supports zones up to 32767.
Q: What do I have to do to become a member of MACLIST?
A: Run a BBS/system that caters to the MacIntosh community
and is accessable via some form of mailer that is FTSC
compatible. It does NOT matter what hardware or software
you use as long as you support the Mac. Just send a
message to one of us at the addresses listed below.
Q: Is membership in MACLIST free?
A: Yes.
Q: If I do not join MACLIST will it be hard for me to get
some Mac echoes?
A: MACLIST does not have any echoes based in it. In other
words NOT being a member of MACLIST will NEVER stop you
from getting an echo. We believe that the MACLIST will
actually ASSIST you in finding systems that carry any or
all of the MANY currently existing MacIntosh echos.
Q: Will I have to use my MACLIST node number?
A: MACLIST is NOT a 'replacement' for other networks. You
do not have to use your MACLIST node number as a primary
node address. It does not have to even appear in your
origin line. As a matter of fact, you must have a
"primary" address in some other network (such as Fidonet
or Alternet) before joining MACLIST. You might want to
make MACLIST an AKA on your system.
Q: Will joining this network cause problems for me in any
other networks?
A: It should not, as there have been software and hardware
specific Networks for a long time with no problem, with
participants in multiple networks. DOS-based boards
have been using nets like this all along (for example,
PNET, QNET, RBBS-Net). Each is means of communication
and support for a particular interest group, just as
FidoNews 7-41 Page 28 8 Oct 1990
MACLIST is oriented to the MacIntosh community.
Q: Why have you added the MACSYSOP echo to the "Fidonet
Backbone" after so many months of successful distribution
off the backbone?
A: At the time MACLIST was formed in October of 1989, we chose
the MACSYSOP Echo rather than some other echo because at
the time MACSYSOP was not a Fidonet, Alternet (or any other
net) echo. After many requests by various Mac sysops, we
placed it on the backbone to make it more available to those
that wanted a link.
Looking forward to bringing the MacIntosh community
together,
Tom Heffernan Ralph Merritt
1:107/554, 7:520/554 1:269/102, 7:520/952
Rock Pile BBS Dragon's Cave BBS
(201)987-9232 (201)228-4708
24 Hours/HST 24 Hours/HST
-----------------------------------------------------------------
FidoNews 7-41 Page 29 8 Oct 1990
Ralph Merritt
1:269/111
OtherNet News - 10/05/90
Welcome to the third edition of the OTHERNET nodelist. As you may
have noted in OTHERNET.271, the 69LIST (Adult Links, Zone 69) and
OPCNLIST (Official Public Computer Network, Zone 11 segment) node-
lists were deleted from the OTHERNET Nodelist. GhotiNet (Zones
60-61) will not be included due to a request for permission for
inclusion being denied.
OtherNets will be added to OTHERNET.xxx on an on-going basis only
if permission is formally granted. Permission to continue to
include those OtherNets included in OTHERNET.271 will be sought.
I'm happy to say that as of OTHERNET.278, inclusion of MetroNet
(Zone 200) has been formally obtained. Thanks and hats off to
Jason Steck (MetroNet ZC) for his support and participation! ;-)
If it turns out that the OTHERNET nodelist is more hassle than it
is worth, or if someone begins to politicize this nodelist, I'll
simple pull it out of the public domain and consider it a dead
project. Hopefully this will not happen, as my netmail area has
been full of comments and congrats from people who find OTHERNET
to be very useful. Thanks to all for their supportive comments.
The OTHERNETS echo is well under-way, with thirteen systems linked
into 269/111. Hopefully there will be more interest generated,
and we can begin to submit the echo to those networks that have
"backbones" for a wider and more convenient distribution.
Thanks to all of you who have been supportive of the OTHERNET
nodelist, OTHERNETS echo, and have provided me with information
and nodelists. I appreciate it! We'll all benefit from the info
that is being shared about OtherNets.
Ralph Merritt
AKA 6:6001/2
7:520/953
8:950/14
26:1201/103
50:5013/111
99:9220/202
-----------------------------------------------------------------
FidoNews 7-41 Page 30 8 Oct 1990
=================================================================
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.5f*
Fido 12s+ QuickBBS 2.64 TBBS 2.1
Lynx 1.30 RBBS 17.3A TComm/TCommNet 3.4
Kitten 2.16 RBBSmail 17.3B* Telegard 2.5
Maximus 1.02* RemoteAccess 0.04a* TPBoard 6.1
Opus 1.13+ SLBBS 1.77* Wildcat! 2.15
PCBoard 14.5* Socrates 1.00 XBBS 1.13
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.20 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.11 Crossnet v1.5
SEAdog 4.51b XlatList 2.90 EMM 2.02
TIMS 1.0(Mod8)* XlaxDiff 2.35* Gmail 2.05
XlaxNode 2.35* GROUP 2.16
GUS 1.30
InterPCB 1.31*
LHARC 1.13
MSG 4.1
MSGED 2.00*
MSGTOSS 1.3*
PK[UN]ZIP 1.10
QM 1.0
QSORT 4.03
Sirius 1.0x
SLMAIL 1.36*
StarLink 1.01
TagMail 2.20
TCOMMail 2.2
Telemail 1.27*
TMail 1.15
TPBNetEd 3.2
TosScan 1.00
UFGATE 1.03
XRS 3.40
FidoNews 7-41 Page 31 8 Oct 1990
ZmailQ 1.12*
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.31
ConfMail 4.00
VP2 4.07*
oMMM 1.52
MsgEd 2.00*
LH2 0.50
PK[UN]ZIP 1.02
ARC2 6.00
Xenix/Unix
----------
BBS Software Mailers Other Utilities
Name Version Name Version Name Version
MaximusCBCS 1.02.Unix.B0 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
Omail 1.00b
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
FidoNews 7-41 Page 32 8 Oct 1990
Macintosh
---------
Bulletin Board Software Network Mailers Other Utilities
Name Version Name Version Name Version
Red Ryder Host v2.1b10 Tabby 2.2 MacArc 0.04
Mansion 7.15 Copernicus 1.0d* ArcMac 1.3
WWIV (Mac) 3.0 StuffIt 1.6b1*
FBBS 0.91* TImport 1.331
Hermes 0.88* TExport 1.32
Timestamp 1.6
Tset 1.3
Import 3.2
Export 3.21
Sundial 3.2
PreStamp 3.2
OriginatorII 2.0
AreaFix 1.6
Mantissa 3.21
Zenith 1.5
UNZIP 1.02b
Amiga
-----
Bulletin Board Software Network Mailers Other Utilities
Name Version Name Version Name Version
Paragon 2.06+ BinkleyTerm 1.00 AmigArc 0.23
TrapDoor 1.50* AReceipt 1.5*
WelMat 0.42 booz 1.01
ConfMail 1.10
ChameleonEdit 0.10
ElectricHerald1.66*
Lharc 1.10
MessageFilter 1.52*
oMMM 1.49b
ParseLst 1.30
PkAX 1.00
PK[UN]ZIP 1.01
PolyxAmy 2.02*
RMB 1.30
TrapList 1.12*
UNzip 0.86
Yuck! 1.61*
Zoo 2.00
Atari ST
FidoNews 7-41 Page 33 8 Oct 1990
--------
Bulletin Board Software Network Mailer Other Utilities
Name Version Name Version Name Version
FIDOdoor/ST 1.5c* BinkleyTerm 2.40* ConfMail 1.00
Pandora BBS 2.41c The BOX 1.20 ParseList 1.30
QuickBBS/ST 0.40 ARC 6.02
GS Point 0.61 FiFo 2.0b*
LHARC 0.60
Lharc 1.13
LED ST 0.10*
BYE 0.25*
PKUNZIP 1.10
MSGED 1.96S
SRENUM 6.2
Trenum 0.10
OMMM 1.40
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 7-41 Page 34 8 Oct 1990
=================================================================
NOTICES
=================================================================
The Interrupt Stack
4 Nov 1990
Area Code 214 fragments. Part will become area code 903.
6 Nov 1990
First anniversary of Van Diepen Automatiseert, 2:500/28
13 Nov 1990
Third anniversary of Fidonet in Austria (zone 2, region 31).
14 Nov 1990
Marco Maccaferri's 21rd Birthday. Send greetings to him at
2:332/16.0
1 Jan 1991
Implementation of 7% Goods and Services Tax in Canada. Contact
Joe Lindstrom at 1:134/55 for a more colorful description.
16 Feb 1991
Fifth anniversary of the introduction of Echomail, by Jeff Rush.
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 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
FidoNews 7-41 Page 35 8 Oct 1990
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
-----------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink