F I D O N E W S -- Vol.10 No.12 (22-Mar-1993)
+----------------------------+-----------------------------------------+
| A newsletter of the | |
| FidoNet BBS community | Published by: |
| _ | |
| / \ | "FidoNews" BBS |
| /|oo \ | +1-519-570-4176 1:1/23 |
| (_| /_) | |
| _`@/_ \ _ | Editors: |
| | | \ \\ | Sylvia Maxwell 1:221/194 |
| | (*) | \ )) | Donald Tees 1:221/192 |
| |__U__| / \// | Tim Pozar 1:125/555 |
| _//|| _\ / | |
| (_/(_|(____/ | |
| (jm) | Newspapers should have no friends. |
| | -- JOSEPH PULITZER |
+----------------------------+-----------------------------------------+
| Submission address: editors 1:1/23 |
+----------------------------------------------------------------------+
| Internet addresses: |
| |
| Sylvia --
[email protected] |
| Donald --
[email protected] |
| Tim --
[email protected] |
| Both Don & Sylvia (submission address) |
|
[email protected] |
+----------------------------------------------------------------------+
| For information, copyrights, article submissions, |
| obtaining copies and other boring but important details, |
| please refer to the end of this file. |
+----------------------------------------------------------------------+
========================================================================
Table of Contents
========================================================================
1. Editorial..................................................... 2
2. Articles...................................................... 3
=== downLoad! === neurozine................................. 3
Policy 5 - Nice Try; but No Democracy Here.................. 4
NEW FidoNet Policy 5 DRAFT report!.......................... 8
Another view of Caller ID and BBS access.................... 39
Yet another Fidonet packet format proposal.................. 43
Caller ID and "The Right to Privacy"........................ 51
Original to: Zone 1 Sysops at 1:141/730.(Election results).. 52
3. Fidonews Information.......................................... 53
FidoNews 10-12 Page: 2 22 Mar 1993
========================================================================
Editorial
========================================================================
We were up all night because the cat, Binkley, was gone, so
we're writing quickly. i didn't know whether he had *decided* to
go away, which would be more or less ok, or if he had been
inadvertently shut outside during comings and goings of
visitors, which would be worry-making. This morning, he is here,
proud of whatever excursion he'd had. So-k.
This week there's another caller-id article, and an anonymous
refutation of a "policy five" proposal. i must apologize and
confess i haven't read the "policy five" document end to end. It
is VERY long. It might seem odd that the "policy five" document
follows its refutation; that's because we print the articles in
the order they're received <?>.
It's confusing that caller-id seems more of an issue than
message content. Is the identity of a person talking more
important than what gets said? Perhaps that is the real issue
.. real names are useful for controlling discussion. Is
preventing abuse of the medium more important than allowing
unfettered expression? It has been stated in several articles
that aliases are only required if the speaker has something to
hide. What never gets explained is why having something to hide
means that one has nothing useful to say? Much, including much
of importance, would never be said at all without the protection
from retribution afforded by privacy.
There is also the other side of the coin. We have heard
professional writers express a reluctance to publish
electronicly because the potential for loss of control, and loss
of copyright once things are on the net. Caller id could
rectify some of that. The entire issue requires more thought
and more balance. Simple polemic is not the answer.
Fidonet started as a grand experiment. Experimentation requires
anarchy ... too much rigour results in tunnel vision. Control
and vitality can been seen as opposite ends of the spectrum.
Quoting Mikael Cardell in the latest issue of "PRACTICAL
ANARCHY: "the idea is, therefore, to publish the texts under
copyleft instead of copy-right and allow copying. i mean,
copying is the way these texts are distributed in the first
place so there's no possibility to stop it".
Editor's note: In keeping with this philosopy, the above is
reprinted without permission.
Editor's P.S.: The Zone 1 election results came in at the last
moment, and are at the end of the issue.
FidoNews 10-12 Page: 3 22 Mar 1993
========================================================================
Articles
========================================================================
=== downLoad! === neurozine
=== downLoad! ===
neurozine
Call for contributions
downLoad!, a completely non-profit co=operative 'zine for your
neurons, is seeking contributions for our inaugral issue. Our
goal is to get information that's available on the net out on
paper so those here in Sydney who aren't hardwired in can
access it.
The general style of information we're looking for is ... well,
intelligent, quirky, progressive, weird, strange, paranoid,
oddball, serious, alternative, learned, left-wing, modern,
frivilous, postmodern, critical, structuralist, sub-genius,
anarchist, or irreverent.
The subject matter? That's for you to decide, but examples of
current articles include, an article about the unanswered
questions of the Jonestown "suicide"; speculation on UFOs (the
wierder the better here); virtual reality; CIA brainwashing
techniques & MK Ultra, the nature of the networks we use,
where their political power lies, what are the forces behind
their development; raves and dance parties; education,
television, and video games; pros and cons of smart drugs,
"extasy", and other popular designer drugs; electronic media
art; alternative culture on the net; and so on.
Length: generally under 1000 words. You should also state whether
you want your name credited, or whether we should use a handle of
some form, and what this is. downLoad! will be released in a no
copyright "ShareRight" form, that is, it can be freely reproduced
unless for profit.
We'll also accept stuff forwarded from netnews or echomail.
Please email your contributions to:
Scot Art 3:712/634@fidonet
[email protected]
You can also leave mail by using your computer and modem to call
System-X on +(61-2)361-4063.
or send an IBM or Macintosh formatted disk with your
contribution in plain ASCII text, Word for Windows, or Word 5 for
the Mac to me via snail-mail:
PO Box E253
FidoNews 10-12 Page: 4 22 Mar 1993
St. James
NSW 2000
Australia
And remember, "information wants to be free".
----------------------------------------------------------------------
Policy 5 - Nice Try; but No Democracy Here
Since the NY-NJ crowd introduced a Policy proposal (version 4.1C),
it seems that other people have jumped on the policy revision
bandwagon. Another NJ sysop named Bob Germer submitted a document
called Policy 5, and now we have another entry distributed by
Christopher Baker, RC18, ALSO called Policy 5. How we're going to
know which Policy 5 we're talking about should be interesting :)
The point of this article is to make a comparison between 4.1C
and the Policy 5 distributed by Baker. The FIRST Policy 5, (the
Germer version), doesn't even merit discussion IMHO.
The 4.1C proposal appears to very strong support in Zones around
the world, and very little support in Zone 1. This is probably more
due to the unpopularity of the authors of it with some Zone 1
coordinators, than the actual text of the document, or at least it
would seem so.
The Policy 5 distributed by Baker is brand new, and how it will
fare around the world remains to be seen, although in this author's
opinion, it probably won't get very far.
So we don't get confused with which Policy 5 we're talking about,
we'll refer to the one distributed by Baker as BAKERPOL.
Comparison of BAKERPOL with Draft Policy 4.1C
Quick Summary:
BAKERPOL 4.1C
NC,RC selection not specific, each net Democratic
has its own method elections
one sysop one
vote. Term is
No term two years
(The 4.1C proposal requires that all coordinators up to and including
Zone Coordinator be elected by majority vote of the SYSOPS of the area
involved, and places a two year term of office on the successful
candidate.
BAKERPOL is not specific. It does not incorporate a term of office, and
does not GUARANTEE the right of the sysops to vote. Nets, Regions and
Zones can have wildly differing election methods and terms of office,
IF any. BAKERPOL also does not REQUIRE elections.)
FidoNews 10-12 Page: 5 22 Mar 1993
IC selection ZC's by absolute ZC's 2/3rds
majority, else RC's
if ZC's "unable to"
(Policy 4.1C requires a 2/3 majority of the Zone Coordinators to elect
an Internation Coordinator. BAKERPOL requires just a majority of the
ZCs and give control of the election to the RCs if the ZCs can't seem
to come up with a winner.)
Replacement of By RC,ZC regardless 20% below can call
NC,RC of sysops a sysop election.
wishes. to replace, limited
(This is an important contrast. The Policy 4.1C proposal gives SYSOPS
the authority to recall or replace coordinators whom they feel are not
performing. BAKERPOL on the other hand, gives unlimited authority to
the RCs to replace an NC, and unlimited authority to the ZC to replace
an RC. Under BAKERPOL, all 2000 sysops in a Region could object to the
removal of their RC, yet the ZC would still have the authority to do
so.)
Local policies OK if "procedural" Can't contradict
like coordinator policy 4.1, uniform.
selection, excessively One network, one
annoying is a local policy.
definition (2.1.2)
(This is another sore point. The 4.1C proposal keeps a unified Fidonet
under one basic set of guidelines. It also provides for the
implementation of local policies provided that they are not more
RESTRICTIVE than 4.1C itself. BAKERPOL allows for local definition of
what should be net-wide. Like what "excessively annoying" is.)
Points Access can be refused no change from
existing
Excommunications Notice to next level no change from
required existing
Policy Ratification Can be selectively Whole document
changed by section. must be presented
(Fidonet has always adopted entire policy documents, not amendments by
section. The reasons why are even stated in current policy. The 4.1C
proposal doesn't change that. However, BAKERPOL would allow sections
of policy to be amended, and has no provisions for preventing approval
of an amendment that would clearly contradict another existing section.
If this were to happen, we could end up with a totally ambiguous
policy!)
Policy Ratification RC's must approve NC's must approve
to allow a vote to allow a vote
(A significant change in 4.1C over current policy is that it moves the
FidoNews 10-12 Page: 6 22 Mar 1993
level of approval of policy referendums DOWN a notch to the NC level.
BAKERPOL still gives complete control over policy referendums to the
RCs)
Excessively examples, including no change
Annoying defying a moderator
(4.1C doesn't change the current definition of excessively annoying.
The BAKERPOL proposal offers examples of what excessively annoying is,
by talking about disrupting a conference after the moderator has
ordered a link cut. However, the document doesn't define what a
conference is, or what a moderator is or how he gets to BE a moderator,
etc. The document uses echomail as a reference yet doesn't define it)
Examples removed removed
(Both documents have removed the case histories currently found in our
current policy)
Non-referenced three, a sample election none
Appendix "procedure",FTSC and standard
file names?
(There are three appendices; 2, 4 and 5 in BAKERPOL that are referenced
nowhere in the document. Appendix 5 talks about file naming conventions
and looks like it came from the Binkleyterm manual. Appendix 2 gives a
SAMPLE election procedure, and note that its a sample so it therefore
isn't binding. And Appendix 3 talks about Fidonet Technical Standards.
Again, these appendices are referenced NOWHERE in the policy itself!)
echomail separated from NETMAIL just a flavor of
links are consentual NETMAIL
(Again, BAKERPOL gives echomail as an example, and doesn't define it.
While No echomail policy can be recognized by Fidonet unless it is
ratified in a manner similar to the way our current policy was
ratified, it makes no sense at all to use echomail as an example when
you don't define what it is or what its rules are or how its
structured, etc.)
Detail:
Both version allows local procedures to be issued at every level
as long as there is no contradiction, however 4.1c requires
democratic elections, BAKERPOL allows any method. How local policy
comes into existence is not specified in BAKERPOL, yet the *C
structure is required to abide by it when judging "excessively
annoying". What is excessive in net 1234 may not be excessive in
net 6789. Multiple policies are unworkable.
BAKERPOL is not specific as to elections however it gives a "sample
procedure" whatever a sample procedure is good for. 4.1C requires
a vote of the sysops and the terms of the *C's are set at two
years. Under BAKERPOL the terms can vary at random. Imagine an
RC with 30 nets each having random terms and procedures. Then
FidoNews 10-12 Page: 7 22 Mar 1993
having to decide a controversy as to a "procedure" when 6 people,
each claim a different procedure.
The good ole boys network is still preserved at the ZC level. Only
NC's and RC's vote. In BAKERPOL there is warm and fuzzy language
asking the NC to poll the net. All in Zone one has witnessed the
recent 4 month fiasco, selecting a ZC.
Now, even if a net chooses an NC or RC, BAKERPOL allows the RC or
ZC to replace the person. Granted it references the
responsibilities in policy, but they can be interpreted. So the
NC the sysops elect may be replaced without their consent. 4.1C
requires a replacement election with 20% of those "below" and then
the sysops vote. To protect against harassment, only two of these
elections are allowed AND the replacement may not be replaced.
How is policy changed. 4.1C lowers the vote threshold to the NC's
and provided a 5% of the NC's may trip a referendum. BAKERPOL
still allows the RC's 50% control.
BAKERPOL has three appendices, which are not referenced in the
policy. One on a sample election procedure ????? another on FTS
standards and one on file names. They seem to be tacked on without
any reference as to use. (ref: appendix 2,4 and 5). BAKERPOL also
has a "sample" appeal process, but as a sample, its not binding.
Overall summary:
BAKERPOL introduces more uncertainty into Fidonet as there can be
as many "policies" on a local level as there are nets+regions+zones
and they may CONFLICT with each other. The is a reference to
"elections" but no REQUIRED specifics and then the *C above can
override the elected choice based on his/her opinion. There is no
appeal process indicated for this. (What policy allows can never
be annoying). Any small problems that BAKERPOL tries to solve will
be offset by the generalities introduced.
It seems that this document consolidates control at the RC level
even more than our existing policy does. And by allowing multiple
local policies which could conflict with each other, you'd find
that the "Fidonet rules" are different in any given place; it can
incite chaos.
If democratic reform is what you're looking for, its not here.
Elections aren't mandatory, and its perfectly OK to elect a
coordinator who serves for life and the sysops have no recourse.
No question that whoever wrote the Policy 5 that Chris Baker is
promoting, put some work into it. But is more of the same what we
really want?
FidoNews 10-12 Page: 8 22 Mar 1993
NEW FidoNet Policy 5 DRAFT report!
Christopher Baker
Rights On! 1:374/14
Here's a REAL Policy 5 Proposal
This article consists of the original Netmail message sent to all the
ZCs, the IC, the Zone 1 RCs and others concerning a new DRAFT proposal
for FidoNet Policy 5. It contains all the original text of that message
and the entire text of the DRAFT. [The margins have been changed to
accomodate FidoNews formatting and excess linefeeds have been removed
to make it as small as possible.] The message was also cross-posted to
the SYSOP, SYSOP18, Z1_ELECTION, and REGCON Echos for maximum
distribution. The DRAFT is available as DRAFT-P5 from 1:374/98 and from
1:374/14 for those who don't want to chop it out of FidoNews. [grin]
The editor and DRAFTScribe is Ken Tuley of 1:374/98. ALL comments and
suggestions should be sent to him via Netmail or in one of the afore-
mentioned Echos.
Msg # 155 Kill/Sent, Direct, W/File, $0.18
Date: 14 Mar 93 17:35:36
From: Christopher Baker on 1:374/14 Rights On! in Titusville FL
To: George Peace on 1:13/13 Backbone Collection in Bensalem PA
Subj: \mail\policys\draft008.zip
_______________________________________________________________________
CC: Matt Whelan, Ron Dwight, Gamey Garcia, Henk Wolsink
CC: Honlin Lue, David Garrett, Mark Lynch, Fred Ennis
CC: Bill Andrus, Tim Pearson, Marv Carson, D Dawson, Bob Satti
CC: B Davis, John Souvestre, Dave James, Steve Cross, Carl Neal
CC: Arthur Greenberg, Wes Cowley, Larry Squire, Bob Hirschfeld
CC: Al&Linda Thompson, Mike Riddle, Bob Germer, Bob Moravsik
CC: Rich Wood, Glen Johnson, Dan Buda, Ken Tuley
[This Netmail msg will be cross-posted in several Regional and FidoNet-
wide Echos for maximum effect and coverage. It may be further
distributed by anyone who wishes to do so to anyone they wish to send it
to without restrictions of any kind. It is not flagged Private nor
intended to be any kind of 'backroom' process.]
[This msg will also be sent to FidoNews as an article for next week's
edition along with the DRAFT text.]
[Coordinators are encouraged to forward this msg and the attached file
to the Coordinators below them in FidoNet and in the Echomail
Coordination structures. It has already been sent to all ZCs, Zone 1
RCs, the IC, and the Echomail Stars and ZEC1 and REC18 by direct
Netmail from this system.]
[Please Note: the word DRAFT is in caps intentionally. It is ONLY a
DRAFT and should not be considered anything else at anytime.]
Please find attached the DRAFT for a new FidoNet Policy version 5.
FidoNews 10-12 Page: 9 22 Mar 1993
This DRAFT was developed and edited by Ken Tuley at 1:374/98 [NC374]
with input from me [RC18] based on Policy4 and current FidoNet
practices.
It has been working for some time as you can tell from the version
number. [grin]
It addresses old and new concepts of FidoNet Policy and incorporates
much of the daily operation now practiced within FidoNet.
This DRAFT provides specific process and procedure that is lacking from
the recently circulated policy drafts from Bob Germer and
Wood/Johnson/Morasvik known as P5DRAFT and 4.1c, respectively.
This DRAFT also provides a new Appendix section with samples of
elections, Policy Complaint due process, FTSC Standards, standard magic
filename conventions and updating of the Zone Mail Hour chart to
include Zones 4, 5, & 6.
This DRAFT organizes and stipulates much of what is common practice and
provides structure for future changes lacking from other drafts.
Since several people have asked in various Echos and in Netmail what
kind of a Policy draft I would support, this is my answer.
Please read it at your convenience and distribute it among your fellow
Cs and/or contacts, as you please. It will always be available here as
DRAFT-P5. Only the magic name will be supported since the version
numbers will probably change as input comes in. [grin]
Major thanks to Ken Tuley for taking the time and interest to develop
this DRAFT and for accepting input and modifying it as we go along. All
input should be sent to Ken at 1:374/98 for consideration and
discussion.
We can utilize several Echos for discussion such as SYSOP or any other
ones appropriate to such discussion. I will apply to the Moderator of
Z1_ELECTION for permission to use that Echo during the next election
lull as well. He is cc:d on this send of the DRAFT and the msg.
We await your responses. You may route Netmail thru me for Ken since he
is a local call to me, if you wish, or you may use direct mail or
standard routing.
Thanks.
TTFN.
Chris
grunt Sysop
RC18
[in that order] [grin]
p.s. Region Coordinators may also be interested in looking at the
current Region 18 Policy DRAFT for future or current reference. It is
FidoNews 10-12 Page: 10 22 Mar 1993
available as R18DRAFT from here and from Ken Tuley [1:374/98].
C.
-----------------------------------------------------------------------
FidoNet Policy Document
Version 5
Draft 008
03/12/93
1 Overview
This document establishes the policy for sysops who are members of the
FidoNet organization of electronic mail systems. FidoNet is defined by
a NodeList issued weekly by the International Coordinator.
Separate policy documents may be issued at the zone, region, or net
level to provide additional detail on local procedures. Ordinarily,
these lower-level policies may not contradict this policy, but will add
procedural information specific to those areas, such as methods of
coordinator selection. However, with the approval of the International
Coordinator, local policy can be used to implement differences required
due to local conditions. These local policies may not place additional
restrictions on membership in FidoNet beyond those included in this
document, other than enforcement of local mail periods.
1.0 Language
To facilitate the largest possible readership, all international
Fidonet documents will be written in English. Translation into other
languages is encouraged.
1.1 Introduction
FidoNet is an amateur electronic mail system. As such, all of its
participants and operators are unpaid volunteers. From its early
beginning as a few friends swapping messages back and forth (1984), it
now (1993) includes over 20,000 systems on six continents.
FidoNet is not a common carrier or a value-added service network and is
a public network only in as much as the independent, constituent nodes
may individually provide public access to the network through their
systems.
FidoNet is large enough that it would quickly fall apart of its own
weight unless some sort of structure and control were imposed on it.
Multi-net operation provides the structure. Decentralized management
provides the control. This document describes the procedures which
have been developed to manage the network.
1.2 Organization
FidoNet systems are grouped on several levels, and administration is
decentralized to correspond to these groupings. This overview provides
a summary of the structure; specific duties of the coordinator
FidoNews 10-12 Page: 11 22 Mar 1993
positions are given later in the document.
1.2.1 Individual Systems and System Operators
The smallest subdivision of FidoNet is the individual system,
corresponding to a single entry in the nodelist. The system operator
(sysop) formulates a policy for running the board and dealing with
users if the sysop provides access to others through that node. The
sysop must mesh with the rest of the FidoNet system to send and receive
mail, and the local policy must be consistent with other levels of
FidoNet. BBS operation is not required to be a Fidonet sysop.
1.2.1.1 Users
The sysop is responsible for the actions of any user when they affect
the rest of FidoNet. (If a user is annoying, the sysop is annoying.)
Any traffic entering FidoNet via a given node, if not from the sysop,
is considered to be from a user and is the responsibility of the sysop.
(See section 2.1.3.)
1.2.1.2 Points
A point is a FidoNet-compatible system that is not in the nodelist, but
communicates with FidoNet through a node referred to as a bossnode. A
point is generally regarded in the same manner as a user, for example,
the bossnode is responsible for mail from the point. (See section
2.1.3.) Points are addressed by using the bossnode's nodelist address;
for example, a point system with a bossnode of 114/15 might be known as
114/15.12. Mail destined for the point is sent to the bossnode, which
then routes it to the point.
In supporting points, the bossnode may make use of a private net number
which should not be generally visible outside of the bossnode-point
relationship. Unfortunately, should the point call another system
directly (to do a file request, for example), the private network
number will appear as the caller's address. In this way, points are
different from users, since they operate FidoNet-compatible mailers
which are capable of contacting systems other than the bossnode.
Outside the local bossnode, a point may be refused access to other
Fidonet systems since points are considered users and sysops have full
control over users' access to their systems.
1.2.2 Networks and Network Coordinators
A network is a collection of nodes in a local geographic area, usually
defined by an area of convenient telephone calling. Networks
coordinate their mail activity to decrease cost.
The Network Coordinator is responsible for maintaining the list of
nodes for the network, and for forwarding netmail sent to members of
the network from other FidoNet nodes. The Network Coordinator may make
arrangements to handle outgoing netmail, but is not required to do so.
The Network Coordinator is selected by the nodes of that net. Nets are
encouraged to formulate policies regarding the mechanism for
FidoNews 10-12 Page: 12 22 Mar 1993
accomplishing this.
1.2.2.1 Network Routing Hubs
Network Routing Hubs exist only in some networks. They may be
appointed by the Network Coordinator, in order to assist in the
management of a large network. The exact duties and procedures are a
matter for the Network Coordinator and local policy to arrange, and
will not be discussed here, except that a network coordinator may not
delegate responsibility to mediate disputes.
1.2.3 Regions and Regional Coordinators
A region is a well-defined geographic area containing nodes which may
or may not be combined into networks. A typical region will contain
many nodes in networks, and a few independent nodes which are not a
part of any network.
The Regional Coordinator maintains the list of independent nodes in the
region and accepts nodelist segments from the Network Coordinators in
the region. These are compiled to create a regional nodelist, which is
then sent to the Zone Coordinator. A Regional Coordinator does not
perform message-forwarding services for any nodes in the region. The
Regional Coordinator may participate in netmail routing between the
coordinator levels, but is not required to do so.
Regional Coordinators are selected by the nodes of that region. Regions
are encouraged to formulate policies regarding the mechanism for
accomplishing this.
1.2.4 Zones and Zone Coordinators
A zone is a large geographic area containing many regions, covering one
or more countries and/or continents.
The Zone Coordinator compiles the nodelist segments from all of the
regions in the zone, and creates the master nodelist and difference
file, which is then distributed over FidoNet in the zone. A Zone
Coordinator does not perform message-forwarding services for any nodes
in the zone. The Zone Coordinator may participate in netmail routing
among the coordinator levels, but is not required to do so.
Zone Coordinators are selected by the Net and Regional Coordinators in
that zone as representatives of the nodes to whom they provide service
(see section 8.3).
1.2.5 Zone Coordinator Council
In certain cases, the Zone Coordinators work as a council to provide
advice to the International Coordinator. The arrangement is similar to
that between a president and advisors. In particular, this council
considers inter-zone issues. This includes, but is not limited to:
working out the details of nodelist production, mediating inter-zone
disputes, and such issues not addressed at a lower level of FidoNet.
FidoNews 10-12 Page: 13 22 Mar 1993
1.2.6 International Coordinator
The International Coordinator coordinates the joint production of the
master nodelist by the Zone Coordinators.
The International Coordinator acts as the chair of the Zone Coordinator
Council and as the overseer of Fidonet-wide elections -- arranging the
announcement of referenda, the collection and counting of the ballots,
and announcing the results for those issues that affect FidoNet as a
whole.
The International Coordinator is selected by the Zone Coordinators. See
section 7.2.
1.2.7 Top-down Organization. Checks and Balances.
These levels act to distribute the administration and control of
FidoNet to the lowest possible level, while still allowing for
coordinated action over the entire mail system. Administration is made
possible by operating in a top-down manner. That is, a person at any
given level is responsible to the level above, and responsible for the
level below.
For example, a Regional Coordinator is responsible to the Zone
Coordinator for anything that happens in the region. From the point of
view of the Zone Coordinator, the Regional Coordinator is completely
responsible for the smooth operation of the region. Likewise, from the
point of view of the Regional Coordinator, the Network Coordinator is
completely responsible for the smooth operation of the network.
If a person at any level above sysop is unable to properly perform
their duties, the coordinator at the next level may replace them. For
example, a Regional Coordinator who fails to perform may be replaced by
the Zone Coordinator. Interim replacements will be appointed until
such time as a formal replacement can be selected under the local or
regional policies. Such appointments will be considered final in the
absence of such policies.
To provide for checks and balances at the highest level of FidoNet,
there is an exception to this top-down organization. The International
Coordinator is selected by a majority vote of the coordinators of the
Zone Coordinators (see section 7.2). Similarly, decisions made by the
International Coordinator can be reversed by the Zone Coordinator
Council. Decisions made by other coordinators are not subject to
reversal by a vote of the lower level, but instead are subject to the
appeal process described in section 9.5.
1.3 Definitions
1.3.1 FidoNews
FidoNews is a weekly newsletter distributed in electronic form
throughout the network. It is an important medium by which FidoNet
sysops communicate with each other. FidoNews provides a sense of being
a community of people with common interests. Accordingly, sysops and
FidoNews 10-12 Page: 14 22 Mar 1993
users are encouraged to contribute to FidoNews. Contributions are
submitted to the node listed in Fidonews and in the nodelist for that
purpose; a file describing the format to be used is available from that
and many other systems.
1.3.2 Geography
Each level of FidoNet is geographically contained by the level
immediately above it. A given geographic location is covered by one
zone and one region within that zone, and is either in one network or
not in a network. There are never two zones, two regions, or two
networks which cover the same geographic area.
If a node is in the area of a network, it should be listed in that
network, not as an independent in the region. (The primary exception
to this is a node receiving inordinate amounts of host-routed mail; see
section 4.2). Network boundaries are based on calling areas as defined
by the local telephone company. Even in the case of areas where node
density is so great that more than one network is needed to serve one
local calling area, a geographic guideline is used to decide which
nodes belong to what network. Network membership is based on geographic
or other purely technical rationale. It is not based on personal or
social factors.
There are cases in which the local calling areas lead to situations
where logic dictates that a node physically in one FidoNet Region
should be assigned to another. In those cases, with the agreement of
the Regional Coordinators and Zone Coordinator involved, exemptions may
be granted. Such exemptions are described in section 5.6.
1.3.3 Zone Mail Hour
Zone Mail Hour (ZMH) is a defined time during which all nodes in a zone
are required to be able to accept netmail. Each Fidonet zone defines a
ZMH and publishes the time of its ZMH to all other Fidonet zones. See
sections 2.1.8 and Appendix 1.
1.3.4 Nodelist
The nodelist is a file updated weekly which contains the addresses of
all recognized FidoNet nodes. This file is currently made available by
the Zone Coordinator not later than Zone Mail Hour each Friday, and is
available electronically for download or file request at no charge. To
be included in the nodelist, a system must meet the requirements
defined by this document. No other requirements may be imposed.
Partial nodelists (single-zone, for example) may be made available at
different levels in FidoNet. The full list as published by the
International Coordinator is regarded as the official FidoNet nodelist,
and is used in circumstances such as determination of eligibility for
voting. All parts that make up the full nodelist are available on each
Zone Coordinator's and each Regional Coordinator's system.
1.3.5 Excessively Annoying Behavior
FidoNews 10-12 Page: 15 22 Mar 1993
There are references throughout this policy to "excessively annoying
behavior", especially in section 9 (Resolution of Disputes). It is
difficult to define this term, as it is based upon the judgement of the
coordinator structure. Generally speaking, annoying behavior irritates,
bothers, or causes harm to some other person. It is not necessary to
break a law to be annoying.
There is a distinction between excessively annoying behavior and
(simply) annoying behavior. For example, there is a learning curve
that each new sysop must climb, both in the technical issues of how to
set up the software and the social issues of how to interact with
FidoNet. It is a rare sysop who, at some point in this journey, does
not manage to annoy others. Only when such behavior persists, after
being pointed out to the sysop, does it becomes excessively annoying.
This does not imply that it is not possible to be excessively annoying
without repetition (for example, deliberate falsification of mail would
likely be excessively annoying on the very first try), but simply
illustrates that a certain amount of tolerance is extended.
See section 9 for more information.
1.3.6 Commercial Use
FidoNet is an amateur network. Participants spend their own time and
money to make it work for the good of all the users. It is not
appropriate for a commercial enterprise to take advantage of these
volunteer efforts to further their own business interests. On the other
hand, FidoNet provides a convenient and effective means for companies
and users to exchange information, to the mutual benefit of all.
Network Coordinators could be forced to subsidize commercial operations
by forwarding host-routed netmail, and could even find themselves
involved in a lawsuit if any guarantee was suggested for mail delivery.
It is therefore FidoNet policy that commercial mail is not to be
routed. "Commercial mail" includes mail which furthers specific
business interests without being of benefit to the net as a whole.
Examples include company-internal mail, inter-corporate mail, specific
product inquiries (price quotes, for instance), orders and their
follow-ups, and all other subjects specifically related to business.
2 Sysop Procedures
2.1 General
2.1.1 The Basics
As the sysop of an individual node, you can generally do as you please,
as long as you operate a mailer compatible with FTS-0001
specifications, observe mail events, are not excessively annoying to
other nodes in FidoNet, and do not promote or participate in the
distribution of pirated copyrighted software or other illegal behavior
via FidoNet.
2.1.2 Familiarity with Policy
FidoNews 10-12 Page: 16 22 Mar 1993
In order to understand the meaning of "excessively annoying", it is
incumbent upon all sysops to occasionally re-read FidoNet policy. New
sysops must familiarize themselves with this policy and any applicable
local, regional or zone policies before requesting a node number.
2.1.3 Responsible for All Traffic Entering FidoNet Via the Node
The sysop listed in the nodelist entry is responsible for all traffic
entering FidoNet via that system. This includes (but is not limited
to) traffic entered by users, points, and any other networks for which
the system might act as a gateway. If a sysop allows "outside"
messages to enter FidoNet via the system, the gateway system must be
clearly identified by FidoNet node number as the point of origin of
that message, and it must act as a gateway in the reverse direction.
Should such traffic result in a violation of Policy, the sysop must
rectify the situation as soon as notified.
2.1.4 Encryption and Review of Mail
FidoNet is an amateur system. Our technology is such that the privacy
of messages cannot be guaranteed. As a sysop, you have the right to
review traffic flowing through your system, if for no other reason than
to ensure that the system is not being used for illegal or commercial
purposes. Encryption obviously makes this review impossible. Therefore,
encrypted and/or commercial traffic that is routed without the express
permission of all the links in the delivery path constitutes annoying
behavior. See section 1.3.6 for a definition of commercial traffic.
2.1.5 No Alteration of Routed Mail
You may not modify, other than as required for routing or other
technical purposes, any message, netmail or echomail, passing through
the system from one FidoNet node to another. If you are offended by
the content of a message, the procedure described in section 2.1.7 must
be used.
2.1.6 Private Netmail
The word "private" should be used with great care, especially with
users of a BBS. Some countries have laws which deal with "private
mail", and it should be made clear that the word "private" does not
imply that no person other than the recipient can read messages.
Sysops who cannot provide this distinction should consider not
offering users the option of "private mail".
If a user sends a "private message", the user has no control over the
number of intermediate systems through which that message is routed. A
sysop who sends a message to another sysop can control this aspect by
sending the message direct to the recipient's system, thus guaranteeing
that only the recipient or another individual to whom that sysop has
given authorization can read the message. Thus, a sysop may have
different expectations than a casual user.
2.1.6.1 No Disclosure of in-transit mail
FidoNews 10-12 Page: 17 22 Mar 1993
Disclosing or in any way using information contained in private netmail
traffic not addressed to you or written by you is considered annoying
behavior, unless the traffic has been released by the author or the
recipient or is a part of a formal policy complaint. This does not
apply to echomail which is by definition a broadcast medium, and where
private mail is often used to keep a sysop-only area restricted.
2.1.6.2 Private mail addressed to you
The issue of private mail which is addressed to you is more difficult
than the in-transit question treated in the previous section. A common
legal opinion holds that when you receive a message it becomes your
property and you have a legal right to do with it what you wish. Your
legal right does not excuse you from annoying others.
In general, sensitive material should not be sent using FidoNet. This
ideal is often compromised, as FidoNet is our primary mode of
communication. In general, if the sender of a message specifically
requests in the text of the message that the contents be kept
confidential, release of the message into a public forum may be
considered annoying.
There are exceptions. If someone is saying one thing in public and
saying the opposite in private mail, the recipient of the private mail
should not be subjected to harassment simply because the sender
requests that the message not be released. Judgement and common sense
should be used in this area as in all other aspects of FidoNet
behavior.
2.1.7 Not Routing Mail
You are not required to route traffic if you have not agreed to do so.
You are not obligated to route traffic for all if you route it for any,
except as required of a Net Coordinator if you hold that position.
Routing traffic through a node not obligated to perform routing without
the permission of that node may be annoying behavior. This includes
unsolicited echomail.
If you do not forward a message when you previously agreed to perform
such routing, the message must be returned to the sysop of the node at
which it entered FidoNet with an explanation of why it was not
forwarded. (It is not necessary to return messages which are addressed
to a node which is not in the current nodelist.) Intentionally stopping
an in-transit message without following this procedure constitutes
annoying behavior. In the case of a failure to forward traffic due to
a technical problem, it does not become annoying unless it persists
after being pointed out to the sysop.
2.1.8 Exclusivity of Zone Mail Hour
Zone Mail Hour is the heart of FidoNet, as this is when network mail is
passed between systems. Any system which wishes to be a part of FidoNet
must be able to receive mail during this time using the protocol
defined in the current FidoNet Technical Standards Committee
publication (FTS-0001 at this writing). It is permissible to have
FidoNews 10-12 Page: 18 22 Mar 1993
greater capability (for example, to support additional protocols or
extended mail hours), but the minimum requirement is FTS-0001
capability during this one hour of the day.
This time is exclusively reserved for netmail. Many phone systems
charge on a per-call basis, regardless of whether a connect, no
connect, or busy signal is encountered. For this reason, any activity
other than normal network mail processing that ties up a system during
ZMH is considered annoying behavior. Echomail should not be transferred
during ZMH. User (BBS) access to a system is prohibited during ZMH.
File requests should not be honored during ZMH.
A system which is a member of a local network may also be required to
observe additional mail events, as defined by the Network Coordinator.
Access restrictions during local network periods are left to the
discretion of the Network Coordinator as defined in local policy.
2.1.9 Private Nodes
The rare exception to ZMH compliance is private nodes. Persons
requesting private nodes should be supported as points if possible. A
private listing is justified when the system must interface with many
others, such as an echomail distributor. In these cases, the exact
manner and timing of mail delivery is arranged between the private node
and other systems. Such an agreement between a private system and a
hub is not binding on any replacement for that hub. A private node must
be a part of a network (they cannot be independents in the region.)
Private listings affect each member of FidoNet, since they take up
space in everyone's nodelist. Private listings which are for the
convenience of one sysop (at the expense of every other sysop in
FidoNet) are a luxury which is no longer possible. Non-essential
redundant listings (more than one listing for the same telephone
number, except as mandated by FTSC standards) also fall into this
category. Sysops requesting private or redundant listings must justify
them with a statement explaining how they benefit the local net or
FidoNet as a whole. The Network Coordinator or Regional Coordinator may
review this statement at any time and listings which are not justified
will be removed.
2.1.10 Observing Mail Events
Failure to observe the proper mail events is grounds for any node to be
dropped from FidoNet without notice (since notice is generally given by
netmail).
2.1.11 Use of Current Nodelist
Network mail systems generally operate unattended, and place calls at
odd hours of the night. If a system tries to call an incorrect or
out-of-date number, it could cause some poor citizen's phone to ring in
the wee hours of the morning, much to the annoyance of innocent
bystanders and civil authorities. For this reason, a sysop who sends
mail is obligated to obtain and use the most recent edition of the
nodelist as is practical.
FidoNews 10-12 Page: 19 22 Mar 1993
2.1.12 Excommunication
A system which has been dropped from the network is said to be
excommunicated (i.e. denied communication). If you find that you have
been excommunicated without warning, your coordinator was unable to
contact you. You should rectify the problem and contact your
coordinator.
Systems may also be dropped from the nodelist for cause. See sections
4.3, 5.2, and 9.
It is considered annoying behavior to assist a system which was
excommunicated in circumventing that removal from the nodelist. For
example, if you decide to provide an echomail feed to your friend who
has been excommunicated, it is likely that your listing will also be
removed.
2.1.13 Timing of Zone Mail Hour
The exact timing of Zone Mail Hour for each zone is set by the Zone
Coordinator. See Appendix 1.
2.1.14 Non-observance of Daylight Savings Time
FidoNet does not observe daylight savings time. In areas which observe
daylight savings time the FidoNet mail schedules must be adjusted in
the same direction as the clock change. Alternatively, you can simply
leave your system on standard time.
2.2 How to obtain a node number
You must first obtain a current nodelist so that you can send mail. You
do not need a node number to send mail, but you must have one in order
for others to send mail to you.
The first step in obtaining a current nodelist is to locate a FidoNet
bulletin board. Most bulletin board lists include at least a few
FidoNet systems, and usually identify them as such. Use a local source
to obtain documents because many networks have detailed information
available which explains the coverage area of the network and any
special requirements or procedures.
Once you have a nodelist, you must determine which network or region
covers your area. Regions are numbered 10-99; network numbers are
greater than 99. Networks are more restricted in area than regions, but
are preferred since they improve the flow of mail and provide more
services to their members. If you cannot find a network which covers
your area, then pick the region which does.
Once you have located the network or region in your area, send a
message containing a request for a node number to node zero of that
network or region. The request must be sent by netmail, as this
indicates that your system has FidoNet capability.
FidoNews 10-12 Page: 20 22 Mar 1993
You must set up your software so that the from-address in your message
does not cause problems for the coordinator who receives it. If you
pick the address of an existing system, this will cause obvious
problems. If your software is capable of using address -1/-1, this is
the traditional address used by potential sysops. Otherwise use
net/9999 (e.g. if you are applying to net 123, set your system up as
123/9999). Many nets have specific instructions available to potential
sysops and these procedures may indicate a preference for the
from-address.
The message you send must include at least the following information:
1) Your name.
2) The phone number to be used when calling your system.
3) The name of your system.
4) The city and state where your system is located.
5) Your voice phone number.
6) Your hours of netmail operation.
7) The maximum baud rate you can support.
8) The type of mailer software and modem you are using.
Your coordinator may contact you for additional information. All
information submitted will be kept confidential and will not be
supplied to anyone except the person who assumes the coordinator
position at the resignation of the current coordinator.
You must indicate that you have read, and agree to abide by, this
document and all the current policies of FidoNet.
Please allow at least two weeks for a node number request to be
processed. If you send your request to a Regional Coordinator, it may
be forwarded to the appropriate Network Coordinator.
2.3 If You are Going Down
If your node will be down for an extended period (more than a day or
two), inform your coordinator as soon as possible. It is not your
coordinator's responsibility to chase you down for a status report, and
if your system stops accepting mail it will be removed from the
nodelist.
Never put an answering machine or any other device which answers the
phone on your phone line while you are down. If you do, calling systems
will get the machine repeatedly, producing large phone bills, which is
very annoying. In short, the only thing which should ever answer the
telephone during periods when the nodelist indicates that your node
will accept mail is FidoNet-compatible software which accepts mail.
If you will be leaving your system unattended for an extended period of
time (such as while you are on vacation), you should notify your
coordinator. Systems have a tendency to "crash" now and then, so you
will probably want your coordinator to know that it is a temporary
condition if it happens while you are away.
2.4 How to Form a Network
FidoNews 10-12 Page: 21 22 Mar 1993
If there are several nodes in your area, but no network, a new network
can be formed. This has advantages to both you and to the rest of
FidoNet. You receive better availability of nodelist difference files
and FidoNews, and everyone else can take advantage of host-routing
netmail to the new network.
The first step is to contact the other sysops in your area. You must
decide which nodes will comprise the network, and which of those nodes
you would like to be the Network Coordinator. Then consult your
Regional Coordinator. You must send the following information:
1) The region number(s), or network number(s) if a network is
splitting up, that are affected by the formation of your network.
The Regional Coordinator will inform the Zone Coordinator and the
coordinators of any affected networks that a new network is in
formation.
2) A copy of the proposed network's nodelist segment. This file
should be attached to the message of application for a network
number, and should use the nodelist format described in the
current version of the appropriate FTSC publication. Please
select a name that relates to your grouping, for example SoCalNet
for nodes in the Southern California Area and MassNet West for the
Western Massachusetts Area. Remember if you call yourself DOGNET
it doesn't identify your area.
Granting a network number is not automatic. Even if the request is
granted, the network might not be structured exactly as you request.
Your Regional Coordinator will review your application and inform you
of the decision.
Do not send a network number request to the Zone Coordinator. All
network number requests must be processed by the Regional Coordinator.
3 General Procedures for All Coordinators
3.1 Make Available Difference Files and FidoNews
Each Coordinator is responsible for obtaining and making available, on
a weekly basis, nodelist difference files and FidoNews.
3.2 Processing Nodelist Changes and Passing Them Upstream
Each coordinator is responsible for obtaining nodelist information from
the level below, processing it, and passing the results to the level
above. The timing of this process is determined by the requirements
imposed by the level above.
3.3 Ensure the Latest Policy is Available
A Coordinator is responsible to make the current version of this
document available to the level below, and to encourage familiarity
with it.
FidoNews 10-12 Page: 22 22 Mar 1993
In addition, a coordinator is required to forward any local policies
received to the level above, and to review such policies. Although not
required, common courtesy dictates that when formulating a local
policy, the participation of the level above should be solicited.
3.4 Minimize the Number of Hats Worn
Coordinators are encouraged to limit the number of FidoNet functions
they perform. A coordinator who holds two different positions
compromises the appeal process. For example, if the Network Coordinator
is also the Regional Coordinator, sysops in that network are denied one
level of appeal.
Coordinators are discouraged from acting as echomail and software-
distribution hubs. If they do so, they should handle echomail (or other
volume distribution) on a system other than the administrative system.
A coordinator's system should be readily available to the levels
immediately above and below.
Another reason to discourage multiple hats is the difficulty of
replacing services if someone leaves the network. For example, if a
coordinator is the echomail hub and the software-distribution hub,
those services will be difficult to restore when that person resigns.
3.5 Be a Member of the Area Administered
A coordinator must be a member of the area administered. That is, a
Network Coordinator must be a member of that network by virtue of
geography. A Regional Coordinator must be either a member of a network
in the region or an independent in the region. A Zone Coordinator must
be either a member of a network in the zone or a regional independent
in the zone. The International Coordinator must be a Fidonet sysop.
3.6 Encourage New Sysops to Enter FidoNet
A coordinator is encouraged to operate a public bulletin board system
which is freely available for the purpose of distributing Policy,
FidoNews, and Nodelists to potential new sysops. Dissemination of this
information to persons who are potential FidoNet sysops is important to
the growth of FidoNet, and coordinators should encourage development of
new systems.
3.7 Tradition and Precedent
A coordinator is not bound by the practices of predecessor or peers
beyond the scope of this document and other applicable net, region or
zone policies.
In addition, a new coordinator has the right to review any decision
made by predecessors for compliance with Policy, and take whatever
actions may be necessary to rectify any situations not in compliance.
3.8 Technical Management
The primary responsibility of any coordinator is technical management
FidoNews 10-12 Page: 23 22 Mar 1993
of network operations. Decisions must be made on technical grounds.
3.9 Review and Acceptance of Lower Policies
Individual regions and nets are encouraged to formulate policies to
deal with local issues not specifically covered in this document. It is
the responsibility of coordinators to review policies submitted from
lower levels for compliance with higher policies, and to support those
policies whenever possible in deciding matters related to those areas.
In the absence of procedures determined by local/regional policies, the
coordinator should attempt to act in accordance with the interests and
wishes of the majority of nodes in the affected area.
4 Network Coordinator Procedures
4.1 Responsibilities
A Network Coordinator has the following responsibilities:
1) To receive incoming mail for nodes in the network, and arrange
delivery to its recipients.
2) To assign node numbers to nodes in the network.
3) To maintain the nodelist segment for the network, and to send a
copy of it to the Regional Coordinator whenever it changes.
4) To make available to nodes in the network new nodelist
difference files, new issues of FidoNews, and new revisions of
Network Policy Documents as they are received, and to periodically
check to insure that nodes use up to date nodelists.
5) To make available to nodes in the network information regarding
Fidonet elections and referenda, to solicit input from those nodes
and to act as a representative of those nodes in such elections
when appropriate.
4.2 Routing Inbound Mail
It is your responsibility as Network Coordinator to coordinate the
receipt and forwarding of host-routed inbound netmail for nodes in your
network. The best way to accomplish this is left to your discretion.
If a node in your network is receiving large volumes of mail you can
request that the sysop contact the systems which are sending this mail
and request that they not host-route it. If the problem persists, you
can request your Regional Coordinator to assign the node a number as an
independent and drop the system from your network.
Occasionally a node will make a "bombing run" (sending one message to a
great many nodes). If a node in another network is making bombing runs
on your nodes and routing them through your inbound host, then you can
complain to the network coordinator of the offending node. (If the node
is an independent, complain to the regional coordinator.) Bombing runs
FidoNews 10-12 Page: 24 22 Mar 1993
are considered to be annoying.
Another source of routing overload is echomail. Echomail cannot be
allowed to degrade the ability of FidoNet to handle normal message
traffic. If a node in your network is routing large volumes of
echomail, you can ask the sysop to either limit the amount of echomail
or to stop routing echomail.
You are not required to forward encrypted, commercial, or illegal mail.
However, you must follow the procedures described in section 2.1.7 if
you do not forward the mail.
4.3 Assigning Node Numbers
It is your responsibility to assign node numbers to new nodes in your
network. You may also change the numbers of existing nodes in your
network, though you should check with your member nodes before doing
so. You may assign any numbers you wish, so long as each node has a
unique number within your network.
You must not assign a node number to any system until you have received
a formal request from that system by FidoNet mail. This will ensure
that the system is minimally operational. The strict maintenance of
this policy has been one of the great strengths of FidoNet.
You may not assign a node number to a node in an area covered by an
existing network. Further, if you have nodes in an area covered by a
network in formation, those nodes must be transferred to the new
network.
You should use network mail to inform a new sysop of the node number,
as this helps to insure that the system is capable of receiving network
mail.
If a node in your network is acting in a sufficiently annoying manner,
you can take whatever action you deem appropriate, according to the
circumstances of the case and due process. Notification must be given
to the Regional Coordinator if that action taken is excommunication of
a node.
4.4 Maintaining the Nodelist
You should implement name changes, phone number changes, and so forth
in your segment of the nodelist as soon as possible after the
information is received from the affected node. You should also on
occasion send a message to every node in your network to ensure that
they are operational. If a node turns out to be "off the air" with no
prior warning, you can either mark the node down or remove it from the
nodelist. (Nodes are to be marked DOWN for a maximum of two weeks,
after which the line should be removed from the nodelist segment.)
At your discretion, you may distribute a portion of this workload to
routing hubs. In this case, you should receive the nodelist segments
from the these hubs within your network. You will need to maintain a
set of nodelist segments for each hub within your network, since you
FidoNews 10-12 Page: 25 22 Mar 1993
cannot count on getting an update from each hub every week. You should
assemble a master nodelist segment for your network every week and send
it to your Regional Coordinator by the day and time designated. It is
suggested that you do this as late as is practical, so as to
accommodate any late changes, balanced with the risk of missing the
connection with your Regional Coordinator and thus losing a week.
4.5 Making Available Policies, Nodelists and FidoNews
As a Network Coordinator you should obtain a new issue of FidoNews and
a new nodelist difference file every week from your Regional
Coordinator. The nodelist difference file is currently made available
each Friday, and FidoNews is published each Monday. You must make these
files available to all nodes in the network, and you are encouraged to
make them available to the general public for download.
You should also obtain the most recent versions of the Policy documents
that bind the members of your network, and make those available to the
nodes in your network. Policies are released at sporadic intervals, so
you should also inform the nodes in your network when such events
occur, and ensure the nodes are generally familiar with the changes.
Policy, FidoNews, and the nodelist are the glue that holds us together.
Without them, we would cease to be a community, and become just another
random collection of bulletin boards.
5 Regional Coordinator Procedures
5.1 Responsibilities
A Regional Coordinator has the following responsibilities:
1) To assign node numbers to independent nodes in the region.
2) To encourage independent nodes in the region to join existing
networks, or to form new networks.
3) To assign network numbers to networks in the region and define
their boundaries.
4) To compile a nodelist of all of the networks and independents
in the region, and to send a copy of it to the Zone Coordinator
whenever it changes.
5) To ensure the smooth operation of networks within the region.
6) To make new nodelist difference files, Policies, and issues of
FidoNews available to the Network Coordinators in the region as
soon as is practical.
7) To make available to Net Coordinators and independent nodes in
the region information regarding Fidonet elections and referenda,
to solicit input from the independent nodes and to act as a
representative of those nodes in such elections when appropriate.
FidoNews 10-12 Page: 26 22 Mar 1993
5.2 Assigning Node Numbers
It is your responsibility to assign node numbers to independent nodes
in your region. You may also change the numbers of existing nodes in
your region, though you should check with the respective nodes before
doing so. You may assign any numbers you wish, so long as each node has
a unique number within your region.
You should not assign a node number to any system until you have
received a formal request from that system by FidoNet mail. This will
ensure that the system is minimally operational. The strict maintenance
of this policy has been one of the great strengths of FidoNet.
You should use network mail to inform a new sysop of the node number,
as this helps to insure that the system is capable of receiving network
mail.
If a node in your region is acting in a sufficiently annoying manner,
you can take whatever action you deem appropriate, according to the
circumstances of the case and due process. Notification must be given
to the Zone Coordinator if the action taken is the excommunication of a
node.
If you receive a node number request from outside your region, you must
forward it to the Regional Coordinator of the applicant's region. If
you receive a node number request from a new node that is in an area
covered by an existing network, then you must forward the request to
the Coordinator of that network instead of assigning a number yourself.
If a network forms in an area for which you have independent nodes,
those nodes will be transferred to the local network as soon as is
practical, unless those independent node assignments were made for
reasons of high volume or commercial traffic.
5.3 Encouraging the Formation and Growth of Networks
One of your main duties as a Regional Coordinator is to promote the
growth of networks in your region.
You should avoid having independent nodes in your region which are
within the coverage area of a network. There are, however, certain
cases where a node should not be a member of a network, such as a
system with a large amount of inbound netmail. See section 4.2.
If several independent nodes in your region are in a local area you
should encourage them to form a network, and if necessary you may
require them to form a network. See section 2.4.
5.4 Assigning Network Numbers
It is your responsibility to assign network numbers to new networks
forming within your region. You are assigned a pool of network numbers
to use for this purpose by your Zone Coordinator. As a part of this
function, it is the responsibility of the Regional Coordinator to
define the boundaries of the networks in the region.
FidoNews 10-12 Page: 27 22 Mar 1993
5.5 Maintaining the Nodelist
As a Regional Coordinator, you have a dual role in maintaining the
nodelist segment for your region.
First, you must maintain the list of independent nodes in your region.
You should attempt to implement name changes, phone number changes, and
so forth in this nodelist segment as soon as possible. You should also
on occasion send a message to every independent node in your region to
ensure that they are operational. If a node turns out to be "off the
air" with no prior warning, you can either mark the node down or remove
it from the nodelist segment. (Nodes are to marked DOWN for a maximum
of two weeks, after which the line should be removed from the nodelist
segment.)
Second, you must receive the nodelist segments from the Network
Coordinators within your region. You will need to maintain a set of
nodelist segments for each network within your region, since you cannot
count on getting an update from each Network Coordinator every week.
You should assemble a master nodelist segment for your region every
week and send it to your Zone Coordinator by the day and time
designated. It is suggested that you do this as late as practical, so
as to accommodate late changes, balanced with the risk of missing the
connection with your Zone Coordinator and thus losing a week.
5.6 Geographic Exemptions
There are cases where local calling geography does not follow FidoNet
regions. In exceptional cases, exemptions to normal geographic
guidelines are agreed upon by the Regional Coordinators and Zone
Coordinator involved. Such an exemption is not a right, and is not
permanent. When a network is formed in the proper region that would
provide local calling access to the exempted node, it is no longer
exempt. An exemption may be reviewed and revoked at any time by any of
the coordinators involved.
5.7 Overseeing Network Operations
It is your responsibility as Regional Coordinator to ensure that the
networks within your region are operating in an acceptable manner. This
does not mean that you are required to operate those networks; that is
the responsibility of the Network Coordinators. It means that you are
responsible for assuring that the Network Coordinators within your
region are acting responsibly.
If you find that a Network Coordinator within your region is not
properly performing the duties outlined in Section 4, you should take
whatever action you deem necessary to correct the situation, up to and
including removing the Net Coordinator from that position and having
the net membership select a replacement.
If a network grows so large that it cannot reasonably accommodate
traffic flow during the Zone Mail Hour, the Regional Coordinator can
direct the creation of one or more new networks from that network.
FidoNews 10-12 Page: 28 22 Mar 1993
These new networks, although they may be within a single local-calling
area, must still conform to a geographical basis for determining
membership.
It is your obligation as Regional Coordinator to maintain direct and
reasonably frequent contact with the networks in your region. The exact
method of accomplishing this is left to your discretion.
5.8 Making Available Nodelists, Policies, and FidoNews
As a Regional Coordinator, it is your responsibility to obtain the
latest nodelist difference file, network policies, and the latest
issues of FidoNews as they are published, and to make them available to
the Network Coordinators within your region. The nodelist is posted
weekly on Friday by the Zone Coordinator, and FidoNews is published
weekly on Monday by the node indicated in the Fidonews and nodelist.
Contact them for more details on how to obtain the latest copies each
week.
It is your responsibility to make these available to all Network
Coordinators and independent nodes in your region as soon as is
practical after you receive them. The method of distribution is left to
your discretion. You are encouraged to make all these documents
available for downloading by the general public.
6 Zone Coordinator Procedures
6.1 General
A Zone Coordinator for FidoNet has the primary task of maintaining the
nodelist for the Zone, sharing it with the other Zone Coordinators, and
ensuring the distribution of the master nodelist (or difference file)
to the Regions in the Zone. The Zone Coordinator is also responsible
for coordinating the distribution of Fidonet Policy documents and
FidoNews to the Regional Coordinators in the zone.
The Zone Coordinator is responsible for the maintenance of the nodelist
for the administrative region. The Administrative Region has the same
number as the zone, and consists of nodes assigned for administrative
purposes not related to the sending and receiving of normal network
mail.
A Zone Coordinator is charged with the task of ensuring the smooth
operation of the Zone.
If a Zone Coordinator determines that a Regional Coordinator is not
properly performing the duties outlined in section 5, whatever action
deemed necessary may be taken, up to and including removing the
Regional Coordinator from that position and having the nodes of the
region select a replacement.
The Zone Coordinator defines the geographic boundaries of the regions
within the zone and sets the time for the Zone Mail Hour.
The Zone Coordinator is responsible for creating new regions within the
FidoNews 10-12 Page: 29 22 Mar 1993
zone when regions become too large for efficient coordination by a
single Regional Coordinator.
The Zone Coordinator is responsible for reviewing and approving any
geographic exemptions as described in section 5.6.
The Zone Coordinator is responsible for insuring the smooth operation
of gates between that zone and all other zones for the transfer of
interzone mail.
The Zone Coordinators are responsible for the selection of the
International Coordinator.
6.2 Selection
The Zone Coordinator is selected by a majority vote of the Net and
Regional Coordinators within the zone, voting as representatives of
their nodes (see section 8.3).
7 International Coordinator Procedures
7.1 General
The International Coordinator has the primary task of coordinating the
creation of the master nodelist by managing the distribution between
the Zones of the Zone nodelists. The International Coordinator is
responsible for definition of new zones and for negotiation of
agreements for communication with other networks. ("Other network" in
this context means other networks with which FidoNet communicates as
peer-to-peer, not "network" in the sense of the FidoNet organizational
level.)
The International Coordinator is also responsible for coordinating the
distribution of Network Policies and FidoNews to the Zone Coordinators.
The International Coordinator is responsible for coordinating the
activities of the Zone Coordinator Council. The International
Coordinator acts as the spokesman for the Zone Coordinator Council.
In cases not specifically covered by this document, the International
Coordinator may issue specific interpretations or extensions to this
policy. The Zone Coordinator Council may reverse such rulings by a
majority vote. These extensions are valid until such time as a policy
referendum may be held to ratify or reject such extensions.
7.2 Selection
The International Coordinator is selected (or removed) by an absolute
majority vote of the Zone Coordinators with input from the Regional
Coordinators. In the event that the Zone Coordinators are unable to
select an International Coordinator by absolute majority, the
International Coordinator will be selected by a majority of the
Regional Coordinators.
8 Referenda
FidoNews 10-12 Page: 30 22 Mar 1993
The procedures described in this section are used to ratify a new
version of FidoNet policy, which is the mechanism by which policy is
changed. This procedure is also used to impeach a Zone Coordinator.
8.1 Initiation
A referendum on policy modification is invoked when a majority of the
FidoNet Regional Coordinators inform the International Coordinator that
they wish to consider a proposed new version of Policy.
8.2 Announcement and Results Notification
Proposed changes to Policy are distributed using the same structure
which is used to distribute nodelist difference files and FidoNews.
Results and announcements related to the referendum are distributed by
the coordinator structure as a part of the weekly nodelist difference
file. The International Coordinator provides copies to the editor of
FidoNews for inclusion there, although the official announcement and
voting dates are tied to nodelist distributions.
If it is adopted, the International Coordinator sets the effective date
for a new policy through announcement in the weekly nodelist difference
file and Fidonews. The effective date will be not more than one month
after the close of balloting.
8.3 Eligibility to Vote
Each member of the FidoNet coordinator structure at and above Network
Coordinator is entitled to one vote. In the case of the position
changing hands during the balloting process, either the incumbent or
the new coordinator may vote, but not both. If a person holds more than
one coordinator position, they still receive only one vote.
Network Coordinators are expected to assess the opinions of the members
of their network, and to vote accordingly. A formal election is not
necessary, but the Network Coordinator must inform the net of the
issues and solicit input. The Network Coordinator functions as the
representative of the rank and file members of FidoNet. Regional
Coordinators will fulfill this responsibility with regard to
independent nodes in their regions.
8.4 Voting Mechanism
The actual voting mechanism, including whether the ballot is secret and
how the ballots are to be collected, verified, and counted, is left to
the discretion of the International Coordinator. Ideally, ballot
collection should be by some secure message system, conducted over
FidoNet itself.
In order to provide a discussion period, the announcement of any ballot
must be made at least two weeks before the date of voting commencement.
The balloting period must be at least two weeks.
8.5 Voting on a whole Policy Document or Amendments
FidoNews 10-12 Page: 31 22 Mar 1993
Policy may be changed as a whole document or by section as required.
Sections changed must include all cross-references affected and the
corresponding changes to those sections.
Policy changes voted on as whole documents and approved will be
incremented to the next whole number from the previous version number.
Sectional changes (including multiple sectional changes approved in the
same referendum) will increment the policy number to the next tenth of
the current version number until nine tenths is reached. Sectional
changes that would go beyond nine tenths will increment to the next
whole number from the previous version number.
8.6 Decision of vote
A Policy amendment is considered in force if, at the end of the
balloting period, it has received a majority of the votes cast. For
example, if there were 350 eligible voters, 100 of which cast a vote,
then at least 51 affirmative votes would be required to declare the
amendment in force.
In the case of multiple policy changes which are considered on the same
ballot, a version must receive more than 50% of the votes cast to be
considered ratified.
8.7 Impeachment of a Zone Coordinator
8.7.1 Initiation
In extreme cases, a Zone Coordinator may be impeached by referendum.
Impeachment of a Zone Coordinator does not require a Policy violation.
An impeachment proceeding is invoked when a majority of the Regional
Coordinators in a zone request the International Coordinator to
institute it.
8.7.2 Procedure as in Policy Referendum
The provisions of sections 8.2 and 8.3 apply to impeachment referenda.
The definition of "majority" in section 8.6 applies. Only coordinators
in the affected zone vote.
8.7.3 Voting Mechanism
The balloting procedures are set, the votes are collected, and the
results are announced by a Regional Coordinator chosen by the
International Coordinator. The removal of the Zone Coordinator is
effective two weeks after the end of balloting if the impeachment
carries.
8.7.4 Limited to once per year
The removal of a Zone Coordinator is primarily intended to be a
mechanism by which the zone as a whole expresses displeasure with the
way Policy is being interpreted. At one time or another, everyone is
FidoNews 10-12 Page: 32 22 Mar 1993
unhappy with the way policy is interpreted. In order to keep the Zone
Coordinators interpreting policy as opposed to defending themselves, at
least one full calendar year must elapse between impeachment referenda
(regardless of how many people hold the position of Zone Coordinator
during that year.)
Should a Zone Coordinator resign during an impeachment process, the
process is considered null and void, and does not consume the "once per
year quota".
9 Resolution of Disputes
9.1 General
The FidoNet judicial philosophy can be summed up in two rules:
1) Thou shalt not excessively annoy others.
2) Thou shalt not be too easily annoyed.
In other words, there are no hard and fast rules of conduct, but
reasonably polite behavior is expected. Also, in any dispute both sides
are examined, and action could be taken against either or both parties.
("Judge not, lest ye be judged!"). It must be noted that it is
someone's "behavior" (action) that is subject to this policy. The
content of a person's words or opinions is not necessarily sufficient
to be considered annoying in this context.
Actions that would be considered excessively annoying behavior include
activities that willfully disrupt the operations of one or more Fidonet
systems; using non-existent or falsified node numbers with the intent
of disguising the origin of mail traffic or of intercepting mail
intended for the rightful owner of that node number; willfully
compromising the integrity of an echomail conference after having
direct links to that conference severed by the conference moderator;
or illegal activities that involve, pertain to or utilize Fidonet as
part of those activities.
The first step in any dispute between sysops is for the sysops to
attempt to communicate directly. Any complaint made that has skipped
this most basic communication step will be rejected.
Filing a formal complaint is not an action which should be taken
lightly. Investigation and response to complaints requires time which
coordinators would prefer to spend doing more constructive activities.
Persons who persist in filing trivial policy complaints may find
themselves on the wrong side of an excessively-annoying complaint.
Complaints must be accompanied with verifiable evidence, generally
copies of messages; a simple word-of-mouth complaint will be dismissed
out of hand.
Failure to follow the procedures herein described (in particular, by
skipping a coordinator, or involving a coordinator not in the appeal
chain) is in and of itself annoying behavior.
FidoNews 10-12 Page: 33 22 Mar 1993
9.2 Problems with Another Sysop
If you are having problems with another sysop, you should first try to
work it out directly with the other sysop.
If this fails to resolve the problem, you should complain to other
sysop's Network Coordinator. If that sysop is not in a network, then
complain to the appropriate Regional Coordinator. Should this fail to
provide satisfaction, you have the right to follow the appeal process
described in section 9.5.
9.3 Problems with your Network Coordinator
If you are having problems with your Network Coordinator and feel that
you are not being treated properly, you are entitled to a review of
your situation. As with all disputes, the first step is to communicate
directly to attempt to resolve the problem.
The next step is to contact your Regional Coordinator. If your case has
merit, there are several possible courses of action, including a change
of Network Coordinators or even the disbanding of your network. If you
have been excommunicated by your Network Coordinator, that judgement
may be reversed, at which point you will be reinstated into your net.
If you fail to obtain relief from your Regional Coordinator, you have
the right to follow the appeal process described in section 9.5.
9.4 Problems with Other Coordinators
Complaints concerning annoying behavior on the part of any coordinator
are treated as in section 9.2 and should be filed with the next level
of coordinator. For example, if you feel that your Regional Coordinator
is guilty of annoying behavior (as opposed to a failure to perform
duties as a coordinator) you should file your complaint with the Zone
Coordinator.
Complaints concerning the performance of a coordinator in carrying out
the duties mandated by policy are accepted only from the level
immediately below. For example, complaints concerning the performance
of Regional Coordinators would be accepted from Network Coordinators
and independents in that region. Such complaints should be addressed to
the Zone Coordinator after an appropriate attempt to work them out by
direct communications.
9.5 Appeal Process
A decision made by a coordinator may be appealed to the next level.
Appeals must be made within two weeks of the decision which is being
appealed. All appeals must follow the chain of command; if levels are
skipped the appeal will be dismissed out of hand.
An appeal will not result in a full investigation, but will be based
upon the documentation supplied by the parties at the lower level. For
example, an appeal of a Network Coordinator's decision will be decided
by the Regional Coordinator based upon information provided by the
FidoNews 10-12 Page: 34 22 Mar 1993
coordinator and the sysop involved; the Regional Coordinator is not
expected to make an independent attempt to gather information.
The appeal structure is as follows:
Network Coordinator decisions may be appealed to the appropriate
Regional Coordinator.
Regional Coordinator decisions may be appealed to the appropriate Zone
Coordinator. At this point, the Zone Coordinator will make a decision
and communicate it to all affected parties.
Zone Coordinator decisions may be appealed to the International
Coordinator. The International Coordinator will make a decision and
communicate it to all affected parties. Decisions of the International
Coordinator may be reversed by a majority of the Zone Coordinators.
If your problem is with a Zone Coordinator per se, that is, a Zone
Coordinator has committed a Policy violation against you, your
complaint should be filed with the International Coordinator, who will
make a decision and submit it to the Zone Coordinator Council for
possible reversal, as described above.
A sample process is described in Appendix 3.
9.6 Statute of Limitations
A complaint may not be filed more than 60 days after the date of
discovery of the source of the infraction, either by admission or
technical evidence. Complaints may not be filed more than 120 days
after the incident unless they involve explicitly illegal behavior.
9.7 Right to a Speedy Decision
A coordinator is required to render a final decision and notify the
parties involved within 30 days of the receipt of the complaint or
appeal.
9.8 Return to Original Network
Once a policy dispute is resolved, any nodes reinstated on appeal are
returned to the local network or region to which they geographically or
technically belong.
9.9 Echomail
Echomail is one of many uses of Fidonet. Echomail is treated as a use
of Fidonet structure and is covered by Policy only to the extent that
this use affects primary Fidonet operations. By its nature, echomail
places unique technical and social demands on the net over and above
those covered by this Policy. It should be noted that echomail
distribution is a separate voluntary arrangement between consenting
nodes and is distinctly different from the routing of netmail. In
recognition of this, an echomail policy which extends (and does not
contradict) general Policy, maintained by the Echomail Coordinators,
FidoNews 10-12 Page: 35 22 Mar 1993
and ratified by a process similar to that of this document, is
recognized by the FidoNet Coordinators as a valid structure for dispute
resolution on matters pertaining to echomail.
9.10 Case Histories
Some of FidoNet Policy is interpretive in nature. No one can see what
is to come in our rapidly changing environment. While the history of
previous complaints and decisions may be useful as guidance, each case
must be decided on its own merits in the time and circumstances under
which it occurs.
10. Credits, acknowledgments, etc.
Fido and FidoNet are registered trademarks of Fido Software, Inc.
Appendix
--------
The Appendices of this document are exceptions to the normal
ratification process and are included for information purposes.
Appendix 1 may be changed by the appropriate Zone Coordinator, and
other sections may be added or changed as needed by the International
Coordinator.
Appendix 1: Timing of Zone Mail Hour
Zone Mail Hour is observed each day, including weekends and holidays.
The time is based upon Universal Coordinated Time (UTC), also known as
Greenwich Mean time (GMT). In areas which observe Daylight Savings Time
during part of the year, the local time of zone mail hour will change
because FidoNet does not observe Daylight Savings Time. The exact
timing of Zone Mail Hour is set for each zone by the Zone Coordinator.
In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to 1000 UTC.
In each of the time zones, this is:
Eastern Standard Time (GMT -5) 4:00 AM to 5:00 AM
Central Standard Time (GMT -6) 3:00 AM to 4:00 AM
Mountain Standard Time (GMT -7) 2:00 AM to 3:00 AM
Pacific Standard Time (GMT -8) 1:00 AM to 2:00 AM
Hawaii Standard Time (GMT -10) 11:00 PM to Midnight
In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to 0330 UTC.
In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to 1900 UTC.
In each of the time Zones involved this is:
GMT +12 Zone 6:00 AM to 7:00 AM
(New Zealand)
GMT +10 Zone 4:00 AM to 5:00 AM
(East Australia, Papua New Guinea, Micronesia)
GMT +9.5 Zone 3:30 AM to 4:30 AM
(Central Australia)
GMT +8 Zone 2:00 AM to 3:00 AM
(Western Australia)
FidoNews 10-12 Page: 36 22 Mar 1993
In Fidonet Zone 4, Zone Mail Hour is observed from 0800 to 0900 UTC.
GMT -3 Zone 5:00 AM to 6:00 AM
GMT -4 Zone 4:00 AM to 5:00 AM
GMT -5 Zone 3:00 AM to 4:00 AM
In Fidonet Zone 5, Zone Mail Hour is observed from 0100 to 0200 UTC.
GMT +0 Zone 1:00 AM to 2:00 AM
GMT +1 Zone 2:00 AM to 3:00 AM
GMT +2 Zone 3:00 AM to 4:00 AM
GMT +3 Zone 4:00 AM to 5:00 AM
In Fidonet Zone 6, Zone Mail Hour is observed from 2000 to 2100 UTC.
In each of the time zones involved this is:
GMT +9 Zone 5:00 AM to 6:00 AM
(Japan, Korea, Eastern Indonesia)
GMT +8 Zone 4:00 AM to 5:00 AM
(Hong Kong, Taiwan, Central Indonesia, Philippines)
GMT +7 Zone 3:00 AM to 4:00 AM
(Malaysia, Singapore, Thailand, Western Indonesia)
Appendix 2: Sample Election Procedure
1. Qualifications and Terms
The Coordinator serves a term of one year and may serve any number of
consecutive terms. Any sysop listed in the appropriate segment of the
Fidonet Nodelist at the time nominations are opened is eligible to run.
A simple majority (50% + 1) of votes cast is required to elect a
Coordinator. In the event that no candidate received a majority of
votes, a run off election will be held between the two candidates with
the greatest number of votes.
2. Nominations
Nominations may be made either in a designated echo or by netmail to
the election coordinator. Any netmail nominations received by the
election coordinator will be cross-posted into the designated echo. Any
sysop listed in the appropriate segment of the Fidonet nodelist may
nominate any other eligible sysop for the position of Coordinator.
Nominees must announce their consent to serve in order to be considered
candidates in the election, and are encouraged to be available for
discussion during the election process.
A minimum of two weeks will be allotted for the nominating process.
3. Election Coordinator
At the start of the election process, the appropriate Coordinator will
appoint a non-candidate sysop as Election Coordinator. This sysop will
have several responsibilities:
FidoNews 10-12 Page: 37 22 Mar 1993
Collecting nominations, seconds and statements of consent to serve from
netmail and the designated echo and finalizing the election slate.
Posting the slate of candidates and the voting format instructions in
the designated echo at the close of nominations.
Submitting the slate of candidates and the voting format instructions
to the Coordinator for distribution via netmail to all Net and/or
Regional Coordinators.
Collecting and tabulating votes submitted.
Notifying the Coordinator of the election results and posting the
election results in the designated echo.
4. Discussion Period
Following the close of nominations and presentation of the slate of
candidates, a minimum of two weeks will be allotted for discussion
before voting begins.
5. Voting Procedures
Net Coordinators in each net will distribute the slate of candidates,
voting instructions and voting schedule to all members of their nets
via netmail.
Votes must be cast by the node sysops via netmail to the Election
Coordinator. Due to changing technology, the exact format and mechanism
of placing these votes will be determined by the Election Coordinator
at the time of each election. Once a vote has been received and
validated, it may not be changed.
The Election Coordinator will announce the final counts within seven
days of the close of voting.
Challenges to the accuracy or completeness of the announced results
must be placed via netmail to the Election Coordinator within seven
days of the announcement of the results. A successful challenge will
necessitate a new election to be initiated.
6. Installation of New Coordinator
The newly elected Coordinator will be installed in the nodelist as soon
as the transfer of control files and other necessary information can be
coordinated between the incoming and outgoing Coordinators, but not
later than two weeks from the announcement of final election results.
Appendix 3: Sample Process for Resolution and Appeal of Complaints
The process of complaint and appeal available to all Fidonet members,
as delineated in sections 9.1 through 9.8, follows a step by step
procedure from the point at which a complaint has been filed.
FidoNews 10-12 Page: 38 22 Mar 1993
1. Offender does something to warrant removal from Fidonet.
2. The Net Coordinator points out this activity to the offender
and offers the opportunity to refrain.
3. The Net Coordinator records the response of the offender.
4. If the offender desists, the case is over. Otherwise;
5. The Net Coordinator issues a final warning to the offender
stating that the nodelist entry will be removed permanently unless
immediate cessation of the offense(s) follows this final warning.
Repeating at a later date an offense for which a warning was
previously given may be considered refusal to comply.
6. If the offender desists, the case is over. Otherwise;
7. The Net Coordinator notifies the offender of removal from the
nodelist.
8. Net Coordinator records offender's final response (if any) and
removes offender's node number from the nodelist if no new
information is received.
9. Net Coordinator advises Regional Coordinator of complete
chronology with documentation and the case is closed, or;
10. The offender appeals to the Regional Coordinator and offers
other information contrary to the Net Coordinator's account and
requests intervention and/or investigation.
11. If the Regional Coordinator refuses the appeal, the case is
over. Otherwise;
12. The Regional Coordinator agrees to consider the appeal and
advises the Net Coordinator to refrain from removal pending
investigation of the appeal.
13. The Regional Coordinator finds appeal has no merit, advises
Net Coordinator to proceed with node removal, and advises offender
of finding and of the option to appeal to the Zone Coordinator,
or;
14. The Regional Coordinator finds appeal has merit and advises
Net Coordinator to retain the node's number and to appeal to the
Zone Coordinator if unsatisfied.
15. Steps 10 through 14 may be repeated at the Zone Coordinator
and International Coordinator levels if necessary.
Appendix 4: Fidonet Technical Standards
The Fidonet Technical Standards Committee (FTSC) is a deliberative body
charged with developing and maintaining technical standards for
operations in a Fidonet Technology Network (FTN). All software used in
FidoNews 10-12 Page: 39 22 Mar 1993
Fidonet communications must be in compliance with the appropriate
standards, which include:
FTS-0001 A basic Fidonet technical standard, R Bush
FTS-0002 (superseded by FTS-0005)
FTS-0003 (superseded by FTS-0006)
FTS-0004 Echomail specifications, B Hartman
FTS-0005 The distribution nodelist, B Baker, R Moore
FTS-0006 YOOHOO and YOOHOO/2U2, V Periello
FTS-0007 SEAlink protocol extension, P Becker
FTS-0008 Bark file-request protocol extension, P Becker
FTS-0009 Message identification and reply linkage, j nutt
Appendix 5: File Name Conventions
For those systems accepting file requests via Fidonet, it is generally
accepted practice that certain types of information will be available
under commonly known alias names. The following are common file
aliases:
FILES List of files available for file request
ABOUT Information about the individual system
NODELIST Current full Fidonet nodelist
NODEDIFF Current weekly Fidonet nodelist difference file
FIDONEWS Current weekly issue of Fidonews
POLICY Fidonet policy documents
-30-
Any typos should also be noted when responding with comments and
suggestions.
Thanks, for your consideration of and attention to this FidoNet
Policy DRAFT.
----------------------------------------------------------------------
Another view of Caller ID and BBS access
Jack Decker 1:154/8
Another view of Caller ID and BBS access
I just want to add a couple of comments to the controversy surrounding
the use of Caller ID for a BBS. First of all, let me start by saying
that the sysop of a BBS has no obligation to provide access to anyone
(unless he has accepted payment in return for access, but that's not
what's under discussion here). Frankly, when you use a BBS you are
essentially accessing someone's private computer system, and you can no
more demand entry to that system via the phone lines than you could
knock on the sysop's front door and demand to use his or her computer.
When a sysop joins Fidonet, he does agree to accept incoming mail from
all comers, especially during Zone Mail Hour, and at any other time of
day IF he is listed as a crashmail system (we won't discuss the case
FidoNews 10-12 Page: 40 22 Mar 1993
where a particular system has had access denied for cause; that's an
exception situation that has no relevance to what we're discussing
here). It would not be proper to deny incoming mail calls based solely
on lack of Caller ID information. But from what I'm reading here, no
one is proposing to do that. The sysops who use this technology simply
want a way to identify calls from incoming USERS.
However, I assume that most sysops put up a BBS because they want to
provide a service. That is, no one (well, hardly anyone) puts up a BBS
with the idea of finding new ways to frustrate potential callers.
Callers are the life blood of a BBS... if you don't have any, you may
have BBS software on your system but you're not really "running a BBS."
Now, it is a given that the use of Caller ID can help eliminate abuse
by callers who are not who they claim to be. The question you should
ask yourself, however, is "Will using Caller ID frustrate connect
attempts by legitimate callers?" In other words, will you lose the
callers you might want to have because of Caller ID?
To some extent, I believe the answer is "YES". Now, let me say going
in that Caller ID is probably one of THE most hotly debated topics in
many conferences, such as the Internet comp.dcom.telecom conference (an
EXCELLENT conference for anyone interested in matters related to the
telephone system or telephony in general). So, there are as many
opinions about it as there are people to give them. But what I am
going to confine my remarks to is the possibility that a call you might
really want to receive will be rejected because you use Caller ID.
First, let's discuss technical problems. That is, let's suppose a
caller to your BBS (or even YOU if you are travelling away from home)
does nothing to block transmission of his number, yet it appears as
"private" on your display, indicating to you that transmission of the
calling number was actively blocked by the caller. This is, in effect,
erroneous information provided by your phone company. The question is,
does this occur frequently? The answer is, "it depends on where your
calls are coming from." If you never get long distance callers, this
may not be a problem for you. However, according to some messages that
have appeared on comp.dcom.telecom, some calls originating in the State
of California are being delivered with the "private" flag set, even
though California telcos are not offering Caller ID there!
Why does that happen? Well, it seems that the California Public
Utilities Commission told California telcos that they could offer
Caller ID _only_ if they offered both per-call and per-line blocking
AND made per-line blocking the default for anyone with an unlisted
number. In other words, they assumed (quite correctly in my opinion)
that anyone who cares enough to pay for an unlisted number probably
does NOT want their unlisted number delivered to anyone they might
call... after all, what's the point of paying for an unlisted number if
you're giving it out freely? But the California telcos (led by
Pac*Bell) balked, and in effect said that if they couldn't offer Caller
ID under their terms, they would pick up their ball and go home.
Ah, but there's a technical glitch. The same connections that make
Caller ID possible also make services like Call Trace and Call Return
FidoNews 10-12 Page: 41 22 Mar 1993
possible. And, the California telcos wanted to offer those services,
which meant that the calling number (used for those services as well as
Caller ID) had to be transmitted between switches. Now, since no one
in California can subscribe to Caller ID, that is not a problem for
in-state calls. But what about calls going out of state? They could
either not send the calling number at all, or they could send it with
the "private" flag set so that it wouldn't display on Caller ID units
in other states, but Call Trace and Call Return would still work.
Guess which route they chose!
So, when a Californian calls someone in another state who subscribes to
Caller ID, the only indication they get is that the call is "private".
Of course, there are still some older phone exchanges in California not
capable of transmitting the calling number, and some long distance
carriers don't yet transmit the calling number, so not all calls from
California will come through as "private". But many will. Some have
suggested that Pac*Bell is doing this deliberately in the hope that
folks will complain to the PUC when the can't get calls to complete,
and the PUC will relent and let Pac*Bell offer the service the way it
wants to (that is, with no protection for unlisted numbers). Now, who
would ever believe that Pac*Bell would be capable of such behaviour? ;-)
There are other states where Caller ID is banned because of privacy
concerns (Pennsylvania is one example) so it's quite possible that
calls from some other states may be affected in this way, though I
haven't personally heard of any.
Long distance carriers may present another problem. Some (especially
smaller carriers, and especially "data only" carriers with local
outdials such as Sprintnet's PC Pursuit) may transmit a number that is
totally erroneous... it's not the number of the caller, but rather of
an access line at the carrier's switch or modem pool. Of course, the
carrier may decide that they don't want incoming calls on their
outgoing trunks, so they may decide to block Caller ID on all outgoing
calls from their modem pool or switch.
I've also been told that Caller ID information may not be transmitted
from behind certain types of PBX or Centrex equipment. Let's say I
visit your town and try to do a little modeming from my motel room, but
the motel has per-line blocking on their outgoing lines. I wouldn't be
able to connect to your BBS.
And then there's the operator-assisted call... someone is having
trouble reaching you so he asks the operator to try. Sorry, but Caller
ID is almost never transmitted on operator-assisted calls, and
depending on the carrier, the call may show up as "private."
Note that in all of the above scenarios, the caller generally has NO
idea that his number is being blocked. In many cases he may be dialing
the call normally, but his local telco (or the long distance carrier)
might present the call as a "private" one.
Now let me say one other word, and that is about Bob Seaborn's comment
in last week's Fidonews (Hi, Bob!), in which he said "Furthermore,
while I can try to understand your reasons to hide your number, my gut
FidoNews 10-12 Page: 42 22 Mar 1993
feeling is that any time someone's hiding something, they're up to
something. And I don't want that something affecting me." Well, Bob, I
think your gut may be deceiving you a bit on this one! :-) To be
honest, I do not like to give my real name and number on the first call
to a BBS, unless I've seen it in operation before or know the sysop or
at least know something about the BBS. Why? Because I want to know a
little about the BBS before I register as a user. If the BBS carries
pornography or blatant computer cracking information, I do not want to
be listed as a registered user of that BBS! And what if the system is
run by a life insurance salesman (or some similar sales go-getter) who
sees ever caller as a potential prospect? Now, you do have the right
to not let me look around without giving you the information you want,
BUT I don't want you just taking that information from me before I'm
even connected to the BBS!
Now, if you really are running one of the types of BBS that I don't
want to be listed as a user of, neither of us have lost anything if I
can't connect. However, suppose your board caters to a different
clientele... maybe former computer newsletter editors! You might be
happy to have me on your system in that case, but you'll never know if
you reject me solely because my Caller ID doesn't come through.
You may not want to believe this, but the ONLY reason I personally
resist giving out my phone number to all and sundry is because of the
increasing level of telemarketing activity that has occurred in recent
years. Some sysops do operate businesses on the side, after all, and
maybe I really don't want them calling me up to solicit my business.
Now, as a sysop, maybe you're not doing anything like that, but my
point is that the caller doesn't know that until he's had a chance to
look over your board and get to know you a bit. In my opinion, both
caller and sysop should know a bit about each other before personal
information like voice phone numbers are traded (not everyone can
afford a separate data phone line for their modem excursions!). In
many cases I have given "-unlisted-" or "000-000-0000" for a phone
number in an initial questionnaire, and then, if I like what I see
during my initial access to the BBS, I'll leave a logoff message to the
sysop giving my real voice number (and yes, I've had a couple of sysops
drop me when they saw me entering the "000-000-0000." I figured if they
couldn't even bother to break in to chat mode to find out why I did it,
it was no great loss to either of us, and I didn't call back. There
are THOUSANDS of BBS's in North America, after all).
There is one final point I want to make about the pitfalls of misusing
Caller ID. Some sysops are getting real clever and using the caller ID
information to bypass the logon. At first blush this sounds great... I
call a BBS and it immediately throws me into the main menu because it
knows exactly who I am. The problem with this can be stated as follows:
CALLING NUMBER DOES NOT EQUATE TO A PARTICULAR PERSON!
Some of your users may wish to call from multiple locations, such as
home and office. Some callers may place calls on multiple lines, and
if calling from behind a PBX or some such equipment, may not even have
control over which line the call goes out on. And conversely, in some
homes or offices there may be more than one caller to your BBS sharing
FidoNews 10-12 Page: 43 22 Mar 1993
the same line (co-workers; husband and wife; siblings or combinations
thereof).
Last summer I visited a friend in Minnesota. While there, I called
several local BBS's from his home, with his permission. Suppose one of
those BBS's had been programmed to recognize his home phone number and
just assumed that it was him calling? I would have had total access to
his account... not that I would have abused it, but you can see that
this could cause unintended problems.
So what's my point? Basically, that if you do use Caller ID as a way
to screen callers, recognize that it's an imperfect tool. Please
consider offering some alternate form of access that can be made
available to callers whose numbers unintentionally display as
"private", at least until such time as the technology is perfected
(which will probably not occur for several years!). And keep in mind
that your users may sometimes wish to call in from locations other than
the ones they usually call from.
No, you aren't required to do any of this, and I know that a few sysops
delight in finding ways to make life hard for callers. I'm hoping that
you, the reader, aren't like that. And, if you have access to the
Internet and can receive either the comp.dcom.telecom newsgroup or the
Telecom Digest mailing list (same messages in different formats),
you'll be able to read a lot more about the Caller ID debate, and all
the reasons why one should/should not use it, ad nauseum. But you will
also learn that it's not quite the reliable service that your local
telco would like you to think it is.
As Caller ID usage expands, sysops need to be aware of the limitations
of this service, not just the supposed benefits. Please try to become
informed BEFORE you possibly seriously inconvenience some of your users
(or potential users).
----------------------------------------------------------------------
Yet another Fidonet packet format proposal
by Paul Martin
A previous revision of this proposal was posted to NET_DEV where it
received a mixed response. This proposal is put forward for wider
discussion amongst the general fidonet community as it differs radically
from any current packed message format, but encapsulates most of the
currently used "kludges" used in FTS-0001 Type 2 packets in a cleaner
format. It also opens Fidonet to more computer types, for example Unix
systems, as by being plain text it tries to remove the bias towards
IBM-PC compatibles. It is also easily extended to cope with the changing
needs of the Fidonet community.
I am very open to suggestions for change to this proposal. It is
important that any radical change to Fidonet's internals should be
discussed widely.
Any similarities to RFC-822 and the Internet SMTP protocol are
intentional -- a good concept should not be ignored just because you
FidoNews 10-12 Page: 44 22 Mar 1993
didn't think of it.
Document: FSC-????
Version: 001
Date: 19-Mar-1993
A proposal for a new Fidonet(r) packet format
Paul Martin
last revised 19 Mar 1993
Background:
~~~~~~~~~~
There is currently a great need within Fidonet and Fidonet Technology
Networks to allow proper interconnectivity. This is not currently
practicable with current packet formats.
This proposal is for a purely text-based packet format which should
address these shortcomings.
The proposal:
~~~~~~~~~~~~
A packet consists of a series of text strings terminated by a given
sequence, and its end is given by an empty string. Within a string,
paragraphs are the only division of the text, and an end of paragraph is
given by an ASCII CR character (13 decimal 0D hex). Within a packet, the
first string is the packet header, and subsequent strings are messages.
A message has two parts: first a header which ends at the first
zero-length paragraph, and following that the message body text.
The string terminator sequence is 0x0d, 0x2e, 0x0d (carriage return,
period, carriage return). Any part of a string which contains this
sequence shall have the period replaced by two periods. When dismantling
a packet, the sequence 0x0d, 0x2e, 0x2e, 0x0d shall be translated back
to 0x0d, 0x2e, 0x0d. (This paragraph assumes the C convention for
hexadecimal constants.)
A header consists of paragraphs containing fields describing the packet
or message to which the header applies. A header field consists of a
key, a colon, a space, and then the associated value. The case of the
key is not significant, except for the "FPKT" key which should always be
in upper case.
No limitation on the length of a message body is made by this document,
but a suggested minimum for compliance is 32k. A header paragraph,
however should not exceed 200 characters in length.
Defined header fields
~~~~~~~~~~~~~~~~~~~~~
FPKT: x
Packet header. Specifies revision of standard. This field should
be the first in the packet, and packets should be identifiable
by having the first four characters being "FPKT". The value is a
number. (Could be other information also here...)
FidoNews 10-12 Page: 45 22 Mar 1993
Origin: addr|addrpath[ brag]
Packet and message header. This identifies where the
packet/message originated. In the packet header the optional
brag portion is not allowed.
Destin: addr|addrpath
Packet header (compulsory). This identifies where the
packet is to be sent.
Product: hexnumber[ prodname[ version]]
Packet header (optional). This gives the 16 bit FTSC product
code of the program which generated the packet (expressed as a 4
digit hexadecimal number), and optionally the product's name and
version. If no product code has been assigned, a value of "FFFF"
should be used.
Date: YYYY-MM-DD HH:NN:SS[ [ZZZ]+HH[:MM]][ #id]
Optional in packet header, but compulsory in a message header.
It gives the date that the packet/message was created. Y=year in
Gregorian calendar, M=month, D=day of month, H=hour, N=minute,
S=second, Z=local time zone code (EST,EDT,GMT,BST,NZT), +HH:MM
is the displacement of your timezone from UTC, expressed as
local time-UTC. Western hemisphere timezones yield negative
displacements, and the sign should always be given. Note that
this differs from most compilers' ideas of how timezones work,
but is closer to the more usual formats of showing timezone
differences.
For duplicate checking, the field #number should make the date
field unique for all messages posted with the given origin
address. This number should, if present, be a small positive
integer.
Groupmail: conference_name
Packet header (optional). Indicates that all the messages in
this packet are for this groupmail conference. If this field is
present, the Destin: field of the packet header may be omitted.
Area: echo_name
Message header (optional). Indicates that this message belongs
to this echomail conference.
To: name[@addrpath]
Message header. The name of the intended recipient of the
message. The address part is only optional in echomail or
groupmail.
From: name[@addrpath]
Message header. The name of the person sending the message.
The address part is only optional in echomail or groupmail.
Subject: description
Message header. A short description of the contents of the
message.
FidoNews 10-12 Page: 46 22 Mar 1993
Via: addr[ YYYY-MM-DD HH:NN:SS[ [ZZZ]+HH[:MM]]]
Message header, netmail only (optional). These are placed in a
netmail messages by the mail processing programs which have
processed the message. Unlike all the other message header
fields, the order of these fields within the header should be
preserved.
File: filename
The file with this filename has been sent with this message.
Multiple "File:" lines are permissible. There is no obligation
for a bulletin board system to pass on to another system any
files that may be attached to a message which has been received.
Editor: name[ version]
Packer: name[ version]
Message header (optional). The editor is the program which
created the message, in whatever form. The packer is the program
which first placed the message into interchange (packet) format.
The editor broadly corresponds to what would go on a FTS-0004
tear line, and the packer broadly corresponds to what would go
in an FSC-0046 ^aPID kludge. Where the two fields would be the
same, one should be omitted. Once an Editor or Packer field has
been added to a message it should not be altered by any other
processing software.
Status: flaglist
Message header (optional). The status flags for this message.
Flags are three letters long, and the list is made up of flags
separated by spaces. An echomail message should not normally
have any status flags. The following flags are defined, and are
all upper case:
PVT private message
FLA file attached to message (filename in subject field)
(omitted if Files field is used)
RTQ receipt requested when this message is delivered
ADQ audit trail request -- each machine the message passes
through sends a receipt
RTA message is a delivery receipt
ADA message is an audit receipt
Further flags may be used internally by mail software, but they
should be lower case, and should never be placed in interchanged
mail. If they are ever encountered in a received packet, they
should be ignored. Suggested internal flags are:
imm send message immediately
dir send message directly to destination
hfp hold for pickup
frq file request
kst kill message after sending
snt message has been sent
lcl locally generated mail
Content-Type: id[,id[,id...]]
FidoNews 10-12 Page: 47 22 Mar 1993
Message header (optional). Various extra information about the
message.
eg. message,split=1/3,plainascii,richtext
(see Internet MIME spec for future ideas)
Content-Type: encrypted=pgp2.2
Sent-To: addr[ addr[ addr [...]]]
Message header (echomail only). In echomail messages, this is a
list of all addresses to which this message has been sent. This
is similar to the SEEN-BY lines that occur in FTS-0004 echomail,
except that the addresses are multi-dimensional. The list is
sorted, in order of significance, alphabetically by domain,
numerically by zone, then net, then node, then point. The most
significant components of an address may be omitted if the
previous address differs from it by only its least significant
components. This "stickiness" may not be carried from one
Sent-To line to the next. Point number components may be omitted
if they are zero. Point addresses may be omitted if the topology
allows this, eg. the point does not pass on the echomail to any
other system. Local topology may allow other details to be
omitted.
Path: addr[ addr[ addr [...]]]
Message header (echomail only). In echomail messages, this is a
list of all addresses which this copy of the message has passed
through. As with Sent-To most significant address components are
"sticky", but the address list must not be sorted. A system may
only add its own address(es) to the Path.
[The Sent-To: and Path: fields may be used for circular path protection.
Wherever possible, topologies should be star shaped, or triangular
fractal like.]
Other header fields may be defined in the future.
======
Value components
~~~~~~~~~~~~~~~~
An address has the following format:
<domain>#<zone>:<net>/<node>[.<point>]
<domain> has the following format:
<sub>[.<sub>[.<sub>[...]]]
<sub> is a string of up to eight characters, the first of which must be
alphabetic (a..z, A..Z), and the rest must be alphameric (0123456789-,
A..Z, a..z). Addresses should not be case significant. ie. Fidonet is
the same domain as fIdOnEt.
It should be noted that the leftmost sub-unit of the domain is the most
significant. The use of "org.fidonet" or "fidonet.org" is incorrect --
FidoNews 10-12 Page: 48 22 Mar 1993
only "fidonet" is correct.
The sub-units are intended for future use to subdivide domains (eg.
fidonet.na, fidonet.uk), but this document only notes this as an
extension to this proposal.
<zone>, <net>, <node>, and <point> are integers in the range 0..65535.
An address path has the format:
<otheraddress|address>*<address>
An <otheraddress> is
<domain>#<local>
The address in an address path specifies where the gateway which has
gatewayed, or is expected to gateway, this message from or to a
different network. An otheraddress is used where the message is to or
from a non-Fidonet technology network, and the local part may be
enclosed in double quotes ("), if the local part contains spaces or
other characters which might give problems.
Example addresses:
Paul Martin@fidonet#2:250/107.3
User name = "Paul Martin"
Domain = "fidonet"
Local = "2:250/107.3"
Paul Martin@ranet#73:7446/107
User name = "Paul Martin"
Domain = "ranet"
Local = "73:7446/107"
Paul Martin@Ranet#73:7446/107*fidonet#2:250/107
User name = "Paul Martin"
Domain = "ranet"
Local = "73:7446/107"
Gateway =
Domain = "fidonet"
Local = "2:250/107"
Comments: This message has passed through a domain gateway, or has a
suggested routing towards a possible gateway.
Paul Martin@uucp#"
[email protected]"*fidonet#2:250/107.3
User name = "Paul Martin"
Domain = "uucp"
Local = "
[email protected]"
Gateway =
Domain = "fidonet"
Local = "2:250/107.3"
Comments: This address be translated at a Uucp gateway from/to
Paul Martin <
[email protected]>
FidoNews 10-12 Page: 49 22 Mar 1993
Albert Ross@x400#"/ADMD=afsw/PRMD=iuoa/C=utopia/O=Widgets Corp./
OU=Marketing/"*fidonet#7:999/998
Comments: X.400 address, ficticious, word-wrapped for this document.
Example packets
~~~~~~~~~~~~~~~
Line feeds have been added for readability.
FPKT: 3
Origin: fidonet#2:250/107
Destin: fidonet#2:250/107.3
Product: 00D4 Stir /a
Date: 1992-08-06 19:57:26 BST+1
