Text 3671, 327 rader
Skriven 2004-12-20 03:52:26 av FidoNews Robot (2:2/2.0)
Ärende: FidoNews 21:51 [03/09]: General Articles
================================================
=================================================================
GENERAL ARTICLES
=================================================================
What is a Bulletin Board?
Matt Mc_Carthy, 1:396/45.17
Way back in my military days, there were "Bulletin Boards" all over
most military bases.
There was a "Bulletin Board" in front of the Mess Hall which usually
listed the meals and serving times for the current day.
There was a "Bulletin Board" in front of the Headquarters Building
which usually listed the 'Orders of the Day', the 'Uniform of the
Day', which units were training on which areas of the base on
certain days, as well as listings of coming Parades, Ceremonies, and
hollidays.
There was a "Bulletin Board" in front of the Chapel which listed
Services and times for each of many denominations.
There was a "Bulletin Board" in front of the Exchange which listed
the hours of operation, specific uniform and dress codes required
for admittance, and dozens to hundreds of personal cards for
everything from 'Free Kittens' to 'baby sitting wanted', to cars and
other stuff 'for sale'.
The "Bulletin Board" in front of Headquarters, as well as the
"Bulletin Board" at the Mess Hall were 'Read Only' Boards in as much
as they were covered with glass doors that were kept locked.
The "Bulletin Board" in front of the Exchange and the Chapel were
'Read/Write' Boards, in as much as they were uncovered, and were
open for anyone to post personal notes and messages on.
In the late 1970's when computers began to catch on, several
programmers wrote electronic "Bulletin Board" programs which exactly
duplicated the functionality of the old manual "Bulletin Boards".
I built my own computer and started running a local club's BBS
program on it for the club. All of the functions _exactly_
duplicated the functionality of the manual "Bulletin Boards". I was
amazed that electronics could do that.
By 1983 I began hearing of something called 'Fido' which was
supposed to be a bunch of connected systems, or something like that.
The concept of 'network' still didn't exist. I went to a friend's
and viewed a "FidoNet" system in operation. Needless to say I was
less than enthused. It was NOT a BBS at all, merely a way to send
'private messages' to other friends who were also part of the same
system. Since I didn't know anyone who was in that system, the idea
of sending 'private messages' to an unknown person simply had no
appeal whatever.
During 1984 I heard that this "Fido" thing had begun 'Conferences'
which now closely duplicated normal "Bulletin Boards", and again I
had to take a look at it. _NOW_ Fido began to look like a real
"Bulletin Board" system; some conferences were 'closed', read only,
some were 'open', read-write.
That's _my_ definition of a BBS.
-----------------------------------------------------------------
GENERAL ECHOMAIL POLICY 1
February 1, 1989
PROLOGUE
This document sets forth policy governing Echomail conferences
and their distribution.
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 only
by a simple majority vote of the Regional Echomail Coordinators.
Those eligible to vote on any proposals made by the REC structure
will be the ZEC, RECs, NECs, NCs, RCs and IC. 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.
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.
12. FIDONET POLICY: The document which governs Fidonet as
adopted by Fidonet. The document as of this writing is Policy3
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 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
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 service 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:
--- Azure/NewsPrep 3.0
* Origin: Home of the Fidonews (2:2/2.0)
|