Tillbaka till svenska Fidonet
English   Information   Debug  
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33888
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   24084
FIDONEWS_OLD1   0/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12852
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4386
FN_SYSOP   41678
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13598
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16069
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
IC   0/2851
INTERNET   0/424
INTERUSER   0/3
IP_CONNECT   719
JAMNNTPD   0/233
JAMTLAND   0/47
KATTY_KORNER   0/41
LAN   0/16
LINUX-USER   0/19
LINUXHELP   0/1155
LINUX   0/22089
LINUX_BBS   0/957
mail   18.68
mail_fore_ok   249
MENSA   0/341
MODERATOR   0/102
MONTE   0/992
MOSCOW_OKLAHOMA   0/1245
MUFFIN   0/783
MUSIC   0/321
N203_STAT   924
N203_SYSCHAT   313
NET203   321
NET204   69
NET_DEV   0/10
NORD.ADMIN   0/101
NORD.CHAT   0/2572
NORD.FIDONET   189
NORD.HARDWARE   0/28
NORD.KULTUR   0/114
NORD.PROG   0/32
NORD.SOFTWARE   0/88
NORD.TEKNIK   0/58
NORD   0/453
OCCULT_CHAT   0/93
OS2BBS   0/787
OS2DOSBBS   0/580
OS2HW   0/42
OS2INET   0/37
OS2LAN   0/134
OS2PROG   0/36
OS2REXX   0/113
OS2USER-L   207
OS2   0/4786
OSDEBATE   0/18996
PASCAL   0/490
PERL   0/457
PHP   0/45
POINTS   0/405
POLITICS   0/29554
POL_INC   0/14731
PSION   103
R20_ADMIN   1121
R20_AMATORRADIO   0/2
R20_BEST_OF_FIDONET   13
R20_CHAT   0/893
R20_DEPP   0/3
R20_DEV   399
R20_ECHO2   1379
R20_ECHOPRES   0/35
R20_ESTAT   0/719
R20_FIDONETPROG...
...RAM.MYPOINT
  0/2
R20_FIDONETPROGRAM   0/22
R20_FIDONET   0/248
R20_FILEFIND   0/24
R20_FILEFOUND   0/22
R20_HIFI   0/3
R20_INFO2   3203
R20_INTERNET   0/12940
R20_INTRESSE   0/60
R20_INTR_KOM   0/99
R20_KANDIDAT.CHAT   42
R20_KANDIDAT   28
R20_KOM_DEV   112
R20_KONTROLL   0/13255
R20_KORSET   0/18
R20_LOKALTRAFIK   0/24
R20_MODERATOR   0/1852
R20_NC   76
R20_NET200   245
R20_NETWORK.OTH...
...ERNETS
  0/13
R20_OPERATIVSYS...
...TEM.LINUX
  0/44
R20_PROGRAMVAROR   0/1
R20_REC2NEC   534
R20_SFOSM   0/340
R20_SF   0/108
R20_SPRAK.ENGLISH   0/1
R20_SQUISH   107
R20_TEST   2
R20_WORST_OF_FIDONET   12
RAR   0/9
RA_MULTI   106
RA_UTIL   0/162
REGCON.EUR   0/2056
REGCON   0/13
SCIENCE   0/1206
SF   0/239
SHAREWARE_SUPPORT   0/5146
SHAREWRE   0/14
SIMPSONS   0/169
STATS_OLD1   0/2539.065
STATS_OLD2   0/2530
STATS_OLD3   0/2395.095
STATS_OLD4   0/1692.25
SURVIVOR   0/495
SYSOPS_CORNER   0/3
SYSOP   0/84
TAGLINES   0/112
TEAMOS2   0/4530
TECH   0/2617
TEST.444   0/105
TRAPDOOR   0/19
TREK   0/755
TUB   0/290
UFO   0/40
UNIX   0/1316
USA_EURLINK   0/102
USR_MODEMS   0/1
VATICAN   0/2740
VIETNAM_VETS   0/14
VIRUS   0/378
VIRUS_INFO   0/201
VISUAL_BASIC   0/473
WHITEHOUSE   0/5187
WIN2000   0/101
WIN32   0/30
WIN95   0/4288
WIN95_OLD1   0/70272
WINDOWS   0/1517
WWB_SYSOP   0/419
WWB_TECH   0/810
ZCC-PUBLIC   0/1
ZEC   4

 
4DOS   0/134
ABORTION   0/7
ALASKA_CHAT   0/506
ALLFIX_FILE   0/1313
ALLFIX_FILE_OLD1   0/7997
ALT_DOS   0/152
AMATEUR_RADIO   0/1039
AMIGASALE   0/14
AMIGA   0/331
AMIGA_INT   0/1
AMIGA_PROG   0/20
AMIGA_SYSOP   0/26
ANIME   0/15
ARGUS   0/924
ASCII_ART   0/340
ASIAN_LINK   0/651
ASTRONOMY   0/417
AUDIO   0/92
AUTOMOBILE_RACING   0/105
BABYLON5   0/17862
BAG   135
BATPOWER   0/361
BBBS.ENGLISH   0/382
BBSLAW   0/109
BBS_ADS   0/5290
BBS_INTERNET   0/507
BIBLE   0/3563
BINKD   0/1119
BINKLEY   0/215
BLUEWAVE   0/2173
CABLE_MODEMS   0/25
CBM   0/46
CDRECORD   0/66
CDROM   0/20
CLASSIC_COMPUTER   0/378
COMICS   0/15
CONSPRCY   0/899
COOKING   32643
COOKING_OLD1   0/24719
COOKING_OLD2   0/40862
COOKING_OLD3   0/37489
COOKING_OLD4   0/35496
COOKING_OLD5   9370
C_ECHO   0/189
C_PLUSPLUS   0/31
DIRTY_DOZEN   0/201
DOORGAMES   0/2051
DOS_INTERNET   0/196
duplikat   6002
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
Möte FIDONEWS_OLD1, 49742 texter
 lista första sista föregående nästa
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)