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

1233 lines
58 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

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

Volume 5, Number 50 12 December 1988
+---------------------------------------------------------------+
| _ |
| / \ |
| /|oo \ |
| - FidoNews - (_| /_) |
| _`@/_ \ _ |
| International | | \ \\ |
| FidoNet Association | (*) | \ )) |
| Newsletter ______ |__U__| / \// |
| / FIDO \ _//|| _\ / |
| (________) (_/(_|(____/ |
| (jm) |
+---------------------------------------------------------------+
Editor in Chief Dale Lovell
Editor Emeritus: Thom Henderson
Chief Procrastinator Emeritus: Tom Jennings
Contributing Editors: Al Arango
FidoNews is published weekly by the International FidoNet
Association as its official newsletter. You are encouraged to
submit articles for publication in FidoNews. Article submission
standards are contained in the file ARTSPEC.DOC, available from
node 1:1/1.
Copyright 1988 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067. IFNA may also be contacted
at PO Box 41143, St. Louis, MO 63141.
Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and
are used with permission.
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them.
Everything here is subject to debate. We publish EVERYTHING
received.
Table of Contents
1. ARTICLES ................................................. 1
The Revolutionization of Echomail ........................ 1
Recommendations on Current IFNA Bylaws Ballot ............ 6
An IFNA Executive Committee Statement of Direction ....... 10
2. NOTICES .................................................. 19
The Interrupt Stack ...................................... 19
New Medical Echo: MEDLIT -- Medical Literature Discussi .. 19
Latest Software Versions ................................. 19
3. COMMITTEE REPORTS ........................................ 21
Special Election For Bylaws Amendments ................... 21
FidoNews 5-50 Page 1 12 Dec 1988
=================================================================
ARTICLES
=================================================================
Everything You ever wanted in an Echomail
Processor but were afraid to ask for!
by Philip J. Buonomo
(1:107/583) or
(7:520/583) or
(9:807/1)
What would the 'dream' echomail processor be like? Well, what
causes most of the problems for sysops who want to process
echomail nowadays? Hmmm, how about DUPES, lost messages,
flaming, off-topic messages, lack of moderator control, relative
slowness of processing time, MEGA-bytes of disk space being taken
up by SOMEONE ELSE'S ARCmail...
The list goes on...
At FIDOcon '88, Butch Walker used a phrase several times that
caught my attention when talking to the software developers. He
said (paraphrased), "We'll tell you what we want, then you guys
can write it."
Well, here's what I would like to see. How about an echomail
processor that can guarantee NO dupes? And get RID of those
SEEN-BY, PATH, EID, etc. lines! They just take up desperately
needed disk space. (And who wants to look at 'em?)
While we're at it, why should I have to keep (in multiple
ARChives) copies of THE SAME CONFERENCES simply because they're
going to different systems? This seems like the biggest waste of
disk space going!
And speaking of wasted disk space, why do we ALWAYS have to read
those FLAMES and off-topic messages that seem to proliferate thru
the echos? Those don't just waste disk space, they cost MONEY,
as in phone bills sending that 'stuff' (insert four letter word
here) around the country! My 'dream' echomail processor will
HAVE to have some way to give the moderator COMPLETE control over
message content.
And another thing... I want my dream echomail processor to be
completely controlled from my end. I'm TIRED of having to wait
DAYS for some other sysop to have to link me into a conference
just because he's too lazy or too technically naive to set it up
for me!
There should be some way to password/protect conferences that are
secure. Let's face it, without full control by the moderator,
ANYone can get ANY echo if they really want it!
My dream echomail processor would also be the FASTEST available.
FidoNews 5-50 Page 2 12 Dec 1988
I want it to be able to process a 2 meg 'star bundle' and make it
available for others in SECONDS (yes, under 60, not 60 thousand).
I also want my dream processor to handle the necessary control
file for me (yes, I want a maximum of ONE), because I can't be
bothered setting up AREAS.BBS or ECHO.CTL or any of that
nonsense. I want to type something like "Add the TREK
conference", and expect to GET it next mail event!
And of course, my dream processor shouldn't CARE what's in a
message's Origin line, or tear line, or should even NEED any of
those! (Who was it that said that God wanted to create hot air so
he invented politicians? ;-)
This processor would have had to go thru extensive beta testing,
too. I'm tired of 'new' programs that appear on the market and
screw up my system for WEEKS.
And of course, it would have to be able to work with ANY BBS
software package available today that's already doing echomail.
Science fiction, right?
Still, wouldn't all that be swell?
(Music: "When you wish upon a star...")
You know what?
Sometimes dreams come true!
/ \
o o
|
\_/
FidoNews 5-50 Page 3 12 Dec 1988
INTRODUCING GROUPMAIL, a REVOLUTIONARY way of processing
conferences!
No, all that is NOT science fiction! Its here now, and it WORKS!
GROUPmail is the method by which ECHOmail should have worked in
the first place.
Here's a bit of history:
Echomail was invented by Jeff Rush as a conferencing system for
FidoNet mail systems (basically the Fido BBS program itself, at
that time). His programs became very popular, to the point where
almost all systems in the public amateur network were using it.
Later, Bob Hartman wrote his Confmail system, which was faster
than the original echomail programs, but which worked in
essentially the same manner.
Over time, as more and more systems tied into more and bigger
echomail conferences, several problems surfaced. For instance,
maintaining a good topology that will not cause duplicate
messages requires a high degree of knowledge and cooperation
between the various systems, and the continual unpacking,
recreation, and repacking of messages requires a great deal of
computer resources. Operating even a small echomail distribution
system (by today's standards) requires many megabytes of disk
space, much processor time, and quite a lot of human intervention
and maintenance.
Group mail has none of these problems, because it takes a
fundamentally different approach to conference distribution.
This basic difference can be summed up as follows:
With echomail, you tell your system where to SEND a conference.
With group mail, you tell your system where to GET a conference.
Echomail was based on the Fido network mail mechanism, and works
by creating network mail messages to other systems. As enhanced
by ARCmail (and as later incorporated into Confmail), it uses the
"file attach" mechanism to ship mail archives to other systems.
Group mail instead uses the "file update request" mechanism to
obtain mail archives from other systems.
Group mail is a "star-based topology", meaning that several
systems connect to one central (or "star") system. This star
system may in turn be one of several that connect to a higher
level star. The topology may be (and probably will be) different
for every conference.
The topmost star system in any given conference is the "top
star". A person using that system may then be the "moderator" of
that conference. All messages flow upward to the top star, and
FidoNews 5-50 Page 4 12 Dec 1988
then back down to the conference participants.
Since all messages MUST flow thru the top star before being
distributed to the participating nodes, the moderator has
COMPLETE control over the content of ALL the messages in the
conference. He can remove FLAMES, or off-topic messages BEFORE
they are distributed.
In any given conference, any star other than the top star is a
"middle star".
For any given conference that you connect to, if you are not the
top star then there is one system that you obtain the conference
from. That person is your "uplink".
Watch how this saves disk space:
Suppose, for example, that you are a middle-star receiving two
megabytes a day which you then pass on to fifty local systems.
How much disk space do you need?
With echomail the answer is 100 megabytes! In fact, to allow for
occasional glitches in distribution, you'll need more like 200
megabytes. With group mail you need two megabytes for every day
of traffic you retain. If you retain group mail archives for
three days, you'll need six megabytes.
How long will it take you to process those two megabytes? If
you're running echomail, I don't even want to think about it!
But with group mail it will take on the order of three seconds.
One aspect of echomail that is conspicuously absent from group
mail are the "vanity lines" (the tear line and the origin line at
the end of each message). Group mail does not require an origin
line because the original address is preserved in the message
header. Also, group mail does not use SEEN-BY lines or PATH
lines, so without an origin line there's no need to stick in a
tear line.
However, some folks really like those little taglines advertising
their system, so the developers made it possible to stick them in.
Whew! Enough for now! Let me just summarize by saying that all
that I described in the first part of this article is available
NOW. All you have to do is File REQuest from my system (or any
of my friends who also have a copy).
If you want to see the state of the art in GROUP Message
Conferencing, just pickup a copy of GROUP201.ARC from my system,
1:107/583 (in FIDOnet), 7:520/583 (in the Alliance), or 9:807/1
(in Phoenix/Net). Or you could just call 1-201-935-1485 and d/l
it directly. However you get it, GET IT, and ENJOY! (Yes, its
SHAREWARE, NOT FREEWARE...)
Thanks for your kind attention!
FidoNews 5-50 Page 5 12 Dec 1988
-----------------------------------------------------------------
FidoNews 5-50 Page 6 12 Dec 1988
Don Daniels
1:107/210
Recommendations on Current IFNA Bylaws Ballot
As the author of several of the proposed bylaws changes, a
Director of IFNA, and a member of the Bylaws committee that has
been working on these proposals, it is my belief that at the
present time I am as familiar with the bylaws and IFNA's needs as
anyone else. Accordingly, I have decided to provide the
following list of recommendations. Please note that this
information is MY OWN and does not necessarily reflect any
"official" view of those bodies referred to above.
Normally I'd prefer to take a more positive approach and indicate
which items to vote FOR. But as the majority of the proposed
changes are positive, I'll concentrate on the negative.
NAY Votes Recommended
=====================
DEF.01 - It is suggested that the term "IFNA Network" be kept to
refer to that entire group of Networks that communicate utilizing
the FidoNet protocol and that have entered into agreement with
IFNA (see the NEW amendment on Agreements near the end of the
list). Also, please read my article on IFNA direction for more
detail regarding this viewpoint.
DEF.02 - I originally wrote this amendment to bring the bylaws
into closer agreement with the contract that IFNA has with Tom
Jennings. However, with the spread of other nets and the
awarding of IFNA's 501c3 status, I now recommend against this
amendment. Again, see my article on IFNA direction.
DEF.04 - The International Coordinator is a FidoNet position.
Eventually, it is quite possible that OtherNets, all
communicating in the total FidoNet-protocol community, will also
have their own "International Coordinators." Hence, it makes
sense to omit this definition. The reference to the "election"
of an IC certainly has had no bearing in practice to date.
Eventually, this may all be subject to negotiated agreements
between IFNA and Network entities.
01.02 - This is an attempt to enfranchise ALL members of FidoNet
as members of IFNA. If FidoNet provides its own internal
democratic processes to cover its own operation and IFNA
restricts itself to the overall FidoNet protocol-using community,
there is no need for this. In addition, agreeements between IFNA
and all network entities may address this matter if it is needed.
01.03 - The same points made in the previous paragraph apply
against this amendment as well.
01.04 - Again, another attempt at the same thing. By making
FidoNews 5-50 Page 7 12 Dec 1988
membership in IFNA not be associated with any internal net
matters, the need for every sysop in a net to have voting rights
for operational matters no longer applies to IFNA.
01.05 - This amendment made some good attempts to work out a
compromise whereby all sysops could have a vote on operational
matters. However, despite its attempts to reduce costs, IFNA
would still have to bear a burden of administrative overhead
which is unfair. In any event, it and the three amendments that
precede it, are no longer relevant if we go the route of
establishing formal agreements between IFNA and network entities.
24.02 - I am very much in favor of International Representation
in IFNA. However, I suggest voting against this proposal because
it gives an unfair advantage to the Southern Pacific area. With
approximately 5% of the total nodes, they would have roughly 20%
of the Divisional Directors. This situation wherein the
percentages of constituents within the respective divisions is
constantly changing is a good reason to vote FOR 24.08, as
changing these ratios through by-laws amendment is impractical.
For instance, Europe has twice as many nodes as Division 12;
therefore IT should be considered as the one with an additional
representative, not zone 12.
24.06 - I have seen figures idicating that roughly 92 nodes exist
in AlterNet and GoodEggNet combined that are not also in FidoNet.
This is approximately 2% of the entire community. But Divisional
Directors are to represent roughly 9% of the community each.
Representation for nodes that cannot be represented through
existing means should be a matter of negotiated agreement between
IFNA and their network administration(s).
24.07 - See previous paragraph.
29 - This bylaw change, by REMOVING a provision, is an attempt to
separate IFNA from FidoNet operation. As it appears that that is
already an accepted direction and as it is a possibility that the
VP-TC might still be responsible for a Nodelist of the overall
IFNA Network (i.e., that network comprised of ALL FidoNet-
compatible technology that has entered into agreement with IFNA)
there is no compelling reason to remove this requirement at the
present time.
39 - This amendment removes the right to establish policy of
FidoNews from the IFNA Board of Directors, meaning such policy
could only be changed by the membership of IFNA as a whole. This
certainly seems to limit our flexibility, should there ever be an
instance where changes become necessary. It should be obvious
that even if the BoD ever did change policy in some unpopular
way, as unlikely as that may be, the membership would still have
the right to reverse them during the next election. So far, the
Board has shown no desire to change current policies, indeed, it
has reaffirmed them. Therefore, why should we reduce our
flexibility?
FidoNews 5-50 Page 8 12 Dec 1988
IMPORTANT YEAS
==============
To end this article on a positive note, I should like to make the
following points on some proposals for which I feel a "YEA" is
especially important.
24.08 - As FidoNet grows, the ratios of Divisional representation
to the number of constituents should remain constant across all
Divisions. As can be seen from all the amendments trying to make
adjustments, the present method of change is one which is
cumbersome at best. The Board of Directors should be given the
responsibility to maintain equal repesentation for all, so this
amendment should be accepted. However, there is a problem with
this amendment in that guidelines are not provided to the BoD to
ensure that they do such modifications within those bounds. This
amendment, if accepted now, will be worked on by the By-laws
committee so that such direction is included on the next ballot.
35.02 - This is an important protection to minority interests.
40.02 - As can be seen from this ballot, our bylaws are in
considerable need of work. To considerable extent, IFNA has
fallen into trouble on numerous occasions because the bylaws were
too inflexible, unclear, or impractical to follow. This
amendment is a workable compromise between giving the Board the
power to do what is necessary for IFNA to get its work done in
timely fashion, and for protection and direction from the
membership.
NEW-02 - This amendment provides IFNA with separation from
operational concerns, but directs it to provide various
services
such that those Nets will wish to become associated with IFNA.
By
providing formal agreements between IFNA and each network entity,
it can be assured that both side's interests are protected and it
can be a tremendous force toward reducing some of the squabbles
we have experienced.
NEW-03 - Note that the Grievance procedure applies ONLY to
internal IFNA matters and to such network entities as CHOOSE to
adopt it as part of a formal agreement. It is NOT being shoved
down anyone's throat; but it is there if the need is felt by
sysops of any particular net. It also serves as the basis for
conflict resolution BETWEEN nets which have opted to subscribe to
its principles.
NEW-04 - The States (and countries) are generally very backward
when it comes to including new technologies in business methods.
There really is no legal basis for doing business through such
means as EchoMail because the law has yet to catch up. We need
this bylaw to serve as a mandate for our use of such
technological advances, both as a protection against question,
and as a means to optimize our limited and scattered resources.
FidoNews 5-50 Page 9 12 Dec 1988
If you haven't taken the time to vote, why not do it right now?
-----------------------------------------------------------------
FidoNews 5-50 Page 10 12 Dec 1988
Don Daniels, Director
International FidoNet Association
1:107/210
Problems Between IFNA And FidoNet
...and a Potential Solution
For much of the last couple years I have heard a great deal to
the effect that IFNA doesn't listen to the sysops of the net.
I've always had cause to doubt this because during my term as
President, whether I agreed or not, I always tried to listen to
what sysops at all levels had to say and allowed their thoughts
to at least simmer in the back of my consciousness. Quite a few
of the Directors with whom I interacted also demonstrated this
trait. To some degree this must have worked because in the last
few months I have beeen hearing to greater degree that IFNA
should not pay as much attention to what sysops have to say and
that we should just get on with what we have to do.
This points out the first problem. The officials of IFNA
definitely consider themselves to be REPRESENTATIVES of the
sysops and users of FidoNet. After all, the reason they joined
IFNA in the first place was to promote FidoNet; not some abstract
idea. They all feel that it is their duty to represent, as best
they can, the wishes of their constituents. You would think
then, that more would have been done by IFNA, but that brings us
to the second problem.
As representatives of BOTH the membership of IFNA and also of the
Sysops and users of FidoNet, the directors are subject to too
many contradicting viewpoints. These contradictions have a
paralyzing effect on the directors who all feel strongly their
responsibilities to both sides. Contributing to this paralysis
is the fact that only a small percentage of all FidoNet sysops
have actually joined IFNA. By withholding their direct support,
these sysops send a message to the directors that they do not
support whatever it is that IFNA may be attempting to do. The
result is that IFNA directors find it difficult to feel a mandate
to make any major moves.
However it isn't even that simple; even within the membership of
IFNA, there are factions who feel strongly that IFNA is the
official head of FidoNet, while others feel just as strongly that
it should be more of a stand-alone service organization. IFNA at
least has mechanisms whereby it can poll its membership to see
what the majority want and to work toward that. But this still
isn't good enough because there is no existing mechanism in place
whereby the majority will of FidoNet as a whole may be easily
determined. What usually serves as the will of FidoNet tends to
be just the expression of a few individual voices.
There are several very real problems subject to this dichotomy
that is IFNA at present. What is IFNA to be? A service-only
organization, or the last word in FidoNet administration?
It is because IFNA has tried to be both, that so little progress
FidoNews 5-50 Page 11 12 Dec 1988
has been made. Imagine a train trying to head in both directions
at once and then judge how much progress it can be expected to
achieve. This dual-identity is the major problem that has
created so much ill-feeling between IFNA and sysops in the past
and that has resulted in so little positive results.
There have been quite a few problems identified besides this main
one of IFNA's primary direction. Should all members of FidoNet
automatically be members of IFNA? Is it right that sysops have
to "purchase" their right to vote on FidoNet issues by joining
IFNA? Is IFNA responsible to just traditional FidoNet or does it
also have a responsibility towards OtherNets? What is to be done
when there is a problem with the IC? What are the rights of our
Users? What if the *C structure does not appear to be providing
sufficient levels of complaint resolution and protection of
individual rights? How can we reconcile the existence of so many
commercial nodes in a supposedly amateur network? What if IFNA
did not exist at all - how would sysops expect to have any
democratic voice in the governing of FidoNet? In fact, how can
they have any even with IFNA, if there are no formally accepted
means for their wishes to be communicated from IFNA to the *C
structure?
When IFNA was formed, there only was one net, FidoNet, which
primarily existed in North America (yes, there were some nodes
overseas, but they were hardly the force that should be reckoned
with today). As a result, it made sense for there to be an
organization that allowed for pooling and sharing of resources,
provided corporate protection and U.S. tax shelters for these
resources, and which also gave all sysops an opportunity to
particpate in FidoNet operation and administration through
democratic processes.
Fortunately or unfortunately, times have changed. The network
has expanded considerably and matured in many areas. We now have
multiple Nets participating under an overall FidoNet protocol.
FidoNet has grown considerably overseas and operations there, due
to differences in their political and technical environments,
require somewhat different solutions than what may be ideal here
in North America. IFNA has finally been authorized by the IRS to
proceed as a 501c3 charitable organization, which presents a
great many new concerns in terms of opportunities as well as
limitations.
How then do we find a soution that will address all these
problems and questions?
I'm not sure that there is any ideal solution that provides ALL
the answers to every need. The right path has to be one that
follows a line of mutually acceptable compromise through a wide
range of variables. We are, for the most part, traveling in
uncharted territories; it is likely that what may even appear
right for the majority today may prove to need adjustment
tomorrow.
The following then is a plan that is not espoused to be perfect;
FidoNews 5-50 Page 12 12 Dec 1988
it is assumed that there are details that will need to be changed
as we look deeper into specific areas and as we attempt to
implement particular aspects. No doubt it will NOT be every
thing that you expect IFNA/FidoNet/OtherNets to be or have. But
when you consider its points, please do so in light of the
following questions? Does it offer opportunities for us to
progress in the general manner we ALL want? Is it better to
follow this path than to stay where we are now?
The Plan
To best understand how this should be approached, let's first
look at the IFNA Articles of Association:
"IV. The purposes for which our corporation is formed are the
following:
A) the promotion of interest in telecommunications and
experimentation;
B) the establishment of telecommunication networks to
provide publicly accessable and publicly available
electronic communications;
C) the furtherance of the public welfare;
D) the advancement of telecommunications art the
fostering of education in the field of electronic
communication;
E) the promotion and conduct of research and development
to further the development of electronic communication;
F) the dissemination of technical, educational, and
scientific information relating to electronic
communication;
G) the printing and publishing of documents, books,
magazines, newspapers and pamphlets necessary or
incidental to any of the above purposes..."
No where in the above is IFNA encouraged to operate or even
administrate any individual network. Lets look into the IFNA
Bylaws:
"IFNA NETWORK: The current set of systems which have been
certified as FidoNet compatible and conform to policies
established by the Board of Directors."
"29. The Vice President - Technical Coordinator shall:
a) be responsible for maintenance and distribution of the
master NODELIST;
b) creation and distribution of the weekly update file
for the master NODELIST;
c) ensuring the smooth operation of the IFNA NETWORK as
prescribed by the Board of Directors; ..."
These are the only statements in the Bylaws that really have any
bearing on what IFNA might be required to do relative to FidoNet.
Notice that they speak of the "IFNA NETWORK". Once it was very
FidoNews 5-50 Page 13 12 Dec 1988
easy to assume that that was "FidoNet" but is that still the
case? Doesn't "IFNA NETWORK" include AlterNet, EggNet or
AnyOtherNet running FidoNet protocol, assuming that both sides
wish that to be the case? The Articles call for IFNA's
"establishment of telecommunication network*S*..." [emphasis
added]; it seems clear that it is part of IFNA's mission to
assist in the establishment and promotion of such OtherNets.
One other document comes into play here. It is the contract that
was signed by Tom Jennings and IFNA:
"...To ensure the orderly growth of the publically available
and accessible electronic Bulletin Board Network Systems, which
have come to be known by TJ's "FidoNet" Trademark, utilizing
the products and services of TJ, as well as to assist in the
maintenance of the standards governing membership in "FidoNet",
TJ delegated, first to specific individuals and now solely to
IFNA, specific responsibilities, namely: to maintain, publish
and distribute the weekly updated listing of authorized
Bulletin Board Systems, hereafter "FidoNet Nodelist"; to assist
with the maintenance and expansion of the standards for the
products and services authorized to be associated with TJ's
marks; ... and to assist with the controlling and policing of
TJ's marks..."
This contract also predated the appearance of multiple networks
utilizing the FidoNet protocol. But from the document, it can be
seen that the intent was for IFNA to represent TJ's interests in
terms of all "publically... accessible...Network Systems, which
have come to be known by..."FidoNet"...". [It is probably
appropriate to state here that TJ is on record as stating that he
wishes to modify the agreement to meet various needs that have
evolved.] I know from discussions with Tom that he encourages the
concept of individual nets pursuing their own ideas of
innovation, while being able to maintain a common basis for
inter-communication.
Now, it should be clear from the documents above, that IFNA's
EXPLICIT requirement in terms of administration of any particular
network (with the exception of the phrase "ensuring the smooth
operation of the IFNA NETWORK") ends with that of producing a
master nodelist. However, in the past, a wide range of
additional tasks have been inferred, based on this one stated
requirement and the traditional tasks related to it. As for the
phrase, "ensuring the smooth operation of the IFNA NETWORK" this
plan assumes that that has to refer to the complete,
FidoNet-based inter-network, as opposed to any individual pieces
per se.
This plan calls for IFNA to do EXACTLY that which it's
controlling documents call for it to do, but no more, in a direct
sense, relative to administration of any one net. Indeed, there
is a very strong likelihood that should IFNA continue to maintain
any attempts to further a special relationship with traditional
FidoNet, it would put two major elements into jeopardy:
FidoNews 5-50 Page 14 12 Dec 1988
o IFNA's Position as FidoNet Protocol Protector for All - In
order to assure that IFNA maintains its responsibility for
the overall "IFNA NETWORK", it must do so equitably for all
comers.
o IFNA's 501c3 Status - In order to maintain its right to this
privilege, IFNA must ensure that its actions match those
purposes called for in the Articles of Association which it
submitted to gain this right.
So, if IFNA is not going to attempt to respond, again in a direct
sense, to calls for it to provide democratic and improved
jurisprudence and other administrative processes WITHIN
traditional FidoNet, who is going to fill this need? The answer
must be that either the basic existing *C structure be expanded
to better address these requirements, or that an additional
organization be formed that will address them.
Either of these approaches could provide the necessary base for
such action and it is not a matter for IFNA to directly declare
which should be chosen nor how it should be implemented. There
are certain advantages to both:
o Expanding the *C structure is the easiest and quickest way
to progress. There already is the existing operational
structure; it just needs to provide mechanisms whereby the
voices of ALL sysops within FidoNet may be better heard and
satisfied. In the past, the *Cs have maintained that it is
far better to work from a basis whereby *Cs are APPOINTED
instead of elected by democratic process. There has always
been a very good reason for this approach: the technical
aspects of getting the mail through have outweighed all
others. However, this is one area in which the network has
certainly matured. There are now many competent sysops who
can assure that the requirements of this function are met;
and, there are now more and more important issues of
administration that need to be dealt with for which the
input of the constituent sysops is required.
o Forming a new organization (or more than one) also makes
sense when considered in various lights. Establishing
present Zone 1 FidoNet as a TRUE hobbyist network, instead
of one that just plays lip service to this ideal, could
result in the split-off of those nodes that are commercially
oriented into their own Net. We have already seen the
formation of several special interest networks; it is only
likely that this will continue and we should not only
provide for this, but also encourage it (instead of the
impossible attempt to make FidoNet all things to all
people).
In fact, there is no reason why both of the above approaches
could not be undertaken; maintain the existing *C structure in
traditional FidoNet, while centering it on hobbyist activity
only. Concurrently, encourage the establishment of additional
networks that address other needs.
FidoNews 5-50 Page 15 12 Dec 1988
The key to this approach, of course, is that communication links
be established and maintained between all these networks.
Without a doubt, that is a primary thrust of IFNA's Articles of
Association and a basis for its 501c3 position. IFNA needs to
concentrate on these matters instead of being dragged down into
intra-FidoNet operational squabbles.
Once there is a division of responsibility between IFNA, which is
limited to general policy-making, umbrella financial, tax, and
representational support, and inter-net connections, and FidoNet
(and all OtherNets), which are responsible for all of their own
internal needs, quite a few of our persistent problems go away:
o Service vs. Operate? - These arguments become moot when
clear lines of responsibility are established.
o Who should join IFNA? - Under this approach there is no
reason for anyone to "HAVE" to join IFNA; it becomes an
all-volunteer organization as it should be to meet
requirements of it's 501c3 charter.
o No one has to "buy" their vote - As all sysops, by virtue of
their appearance in its Nodelist, would automatically be
members of the new FidoNet organization their vote on
operational issues would be assured.
o "Freeloaders" could not control of other's donations -
Because those who have demanded a right to vote on Net
operational concerns would have that outside of IFNA there
is no question of them voting on and controlling the
disposition of funds and resources which they have not
contributed.
o Differences in intra-Zone operational requirements may be
better resolved by the Zones themselves. Europe seems on
the way to establishing its own FidoNet Association. There
is no reason why it should not be self-governing, although
it will be in everyone's best interests for Zone 2 FidoNet
to enter into agreement with IFNA to maintain various
universal standards of operation.
o IFNA won't appear to be shoved down any Net's throat - With
sufficient operating distance established between IFNA and
the individual Nets there is room for both sides to maneuver
- and for the Nets and IFNA to approach each other out of
mutual desire to effect standards of operation and to share
in the promotion of FidoNet.
o Policy vs. Procedure - Under such an approach, IFNA becomes
clearly responsible for establishing high-level policies
that are then endorsed by the *C structure and the general
sysop body. The *Cs retain responsibility for implementing
these policies through various procedures and for adding
detail necessary to address requirements at the various
levels within the heirarchy.
FidoNews 5-50 Page 16 12 Dec 1988
Problems
Naturally, there are a few hurdles before such a plan can come to
full fruition. The Bylaws of IFNA will need quite a few changes.
Some of these changes are already on the ballot that IFNA members
should be casting by the middle of January. Of particular note
are Docket items NEW-02 and NEW-03 which, respectively, establish
a procedure whereby IFNA is to interact with Network Operational
Entities, and provide for the establishment of a Grievance
Procedure that has jurisdiction internally to IFNA and between
IFNA and such Nets as choose to subscribe to it. You should vote
YEA on these two issues to get a start on this plan. (Note that
this plan presently negates the need for docket numbers DEF.01,
DEF.02, DEF.04, 24.06, 24.07, and 29. It is recommended that you
vote NAY on these proposals).
The question of the make-up of the IFNA Board of Directors is one
which may likely have to be revised. It is possible that IFNA
Directors, in addition to being elected by IFNA members, may be
augmented by representatives who serve from constituent Networks,
according to such agreements as may be established between IFNA
and those Nets. The present scheme which divides North America
into various regional segments may well be better suited for the
operational organization of Zone1 FidoNet. This point typifies
the fact that details will have to be worked out as we progress.
Provisions in the Bylaws and the contract with TJ will also have
to be included to allow for the existence and support of multiple
Networks and Nodelists.
But the biggest problem remains the fact that FidoNet does not
have an existing operational infrastructure that is formally
responsible to the sysops of the net or that operates on
universal administrative principles and procedures. How do we
get the *C structure (including EchoMail Coordinators) to
integrate democratic processes into their operations? Realize,
that this is not a simple question. Democracy needs to be in
place to provide for expression of choice on various matters of
policy and administration. But certain operational aspects may
always need to be reserved. After all, in a hobbyist environment
no one can actually be compelled to perform tasks designed to
benefit others, particularly if they involve any expense.
Really, beyond just the plain encouragement of peer pressure, the
only power a hobbyist group may actually be able to invoke is
that to enjoin. And the nature of FidoNet makes even that power
very tenuous in some areas.
Who Must Do What?
In order to get this plan rolling IFNA must do the following:
o Establish various necessary universal policies of
administration and operation. IFNA's Articles, Bylaws, and
contract with TJ all call upon IFNA to be responsible for
defining policy. IFNA needs to take up this responsibility
FidoNews 5-50 Page 17 12 Dec 1988
at the universal level, while leaving local details and
aspects of procedure to the *C structure.
o Concentrate on establishing the technical requirements for
inter-Network communications.
o Begin work on establishing the bases upon which all Nets may
enter into formal agreements with IFNA.
o Get working on changing its Bylaws where necessary.
o Continue work on most of its other services such as
standards, certification, and its own administration.
The *C structure must:
o Concentrate on Procedure more than actual Policy. Granted,
the *C structure is responsible for detailed policy making
at levels below the universal, but it should demand that
IFNA provide them a satisfactory basis from which to work.
o Make allowances in its present methods of administration and
operation for more direct responsiveness to sysops at all
levels.
o Establish, or assist in causing to be established, formal
procedures for such matters as voting, grievance resolution,
and other operational concerns at all levels within their
heirarchy.
o Broaden involvement in these and other aspects of Net
administration. Most *Cs have a great deal to do under the
present conditions and it is often demonstrated that it is
too much to expect of any volunteer. By creating more
positions and extending involvement to more sysops, we
ensure a much broader base of expertise to step in and take
over in times of need.
Sysops must:
o Press and assist the *C structure in accomplishing the
above. In particular, if you wish to have your voice heard
relative to Net matters, then make sure it is!
(Constructively, of course!) And insist that there be a
more formal way for this to happen so we don't have to rely
on the often torrid environment of EchoMail.
o If you wish to see IFNA do something for you, join it and
pitch in through vocal encouragement, moral support, or
direct action.
o Take responsibility for all the actions ascribed to the
above. We all know "Rome wasn't built in a day." Each of
us have our pet projects that we hope will be worked on and
it is easy to become impatient when we see little progress.
The key to progress here is to make sure that we've each put
FidoNews 5-50 Page 18 12 Dec 1988
our own house in order to as great a degree possible; and
then to help those who are responsible for what we feel we
need, perhaps by just taking on some unrelated aspect of
their burden to allow them the time to get to that what
which we seek.
With Sysops taking responsibility for this entire process, the
*Cs increasing the franchise of all sysops at all heirarchial
levels, and IFNA establishing the high-level political and
technical inter- connections in a manner which is less intrusive
than serving, there is a great chance that FidoNet can soon
become a force far greater than it even is today.
-----------------------------------------------------------------
FidoNews 5-50 Page 19 12 Dec 1988
=================================================================
NOTICES
=================================================================
The Interrupt Stack
24 Aug 1989
Voyager 2 passes Neptune.
5 Oct 1989
20th Anniversary of "Monty Python's Flying Circus"
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
-----------------------------------------------------------------
New Medical Echo: MEDLIT -- Medical Literature Discussions
Richard Kaplan
Medical Software Exchange
FidoNet: 1:135/3
Internet: medsoft.UUCP
(305) 325-8709
I am organizing a new echo (MEDLIT) which will include
discussions of current papers in popular medical journals such as
JAMA and NEJM. I think electronic publishing ultimately could
revolutionize the way medical information is disseminated by
minimizing publication delays and providing for efficient
discussion of controversial theories, including direct
communication with authors. Perhaps FidoNet can in some way
contribute to this vision.
Think of MEDLIT as an electronic letters-to-the-editor section of
your favorite medical journal. If the echo is of high enough
quality and has enough participation, I would be willing to
compile the messages periodically and submit them to the editors
of the appropriate journals, similar to the publication of the
"Best of Bix" in Byte magazine at one time.
Let me know if you would like to link into this echo or if you
have any suggestions about organizing it. I am PC-PURSUITABLE,
but if you do not use PC PURSUIT then I will try to link you in
locally as the distribution list grows.
-----------------------------------------------------------------
Latest Software Versions
BBS Systems Node List Other
& Mailers Version Utilities Version Utilities Version
FidoNews 5-50 Page 20 12 Dec 1988
Dutchie 2.90b EditNL 4.00 ARC 5.32*
Fido 12i MakeNL 2.12 ARCmail 1.1
Opus 1.03b Prune 1.40 ConfMail 4.00
SEAdog 4.10 XlatList 2.86 EchoMail 1.31
TBBS 2.1* XlaxNode 2.22 MGM 1.1
BinkleyTerm 2.00 XlaxDiff 2.22 TPB Editor 1.21
QuickBBS 2.03 ParseList 1.20 TCOMMail 1.1
TPBoard 4.2 TMail 8812*
TComm/TCommNet 3.2 UFGATE 1.0
Lynx 1.10 GROUP 2.0*
D'Bridge 1.10
FrontDoor 2.0
* Recently changed
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
-----------------------------------------------------------------
FidoNews 5-50 Page 21 12 Dec 1988
=================================================================
COMMITTEE REPORTS
=================================================================
IFNA Election Committee
1:1/10
Special Election For Bylaws Amendments
This past week ballots were mailed to all current members of
record of IFNA for the Special Election for Bylaws Amendments.
Completed ballots must be returned prior to January 16.
For information as to where the completed ballot should be
sent, please refer to the instructions contained within the
package.
Due to the large quantity of material in the ballot package it
will not be reproduced here in FidoNews. The ballot package
material is available for file request (BARK) from the Election
Committee at either 138/34 (west coast) or 107/210 (east coast)
under the name BALLOT.ARC.
-----------------------------------------------------------------
FidoNews 5-50 Page 22 12 Dec 1988
OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION
Hal DuPrie 1:101/106 Chairman of the Board
Bob Rudolph 1:261/628 President
Matt Whelan 3:3/1 Vice President
Ray Gwinn 1:109/639 Vice President - Technical Coordinator
David Garrett 1:103/501 Secretary
Steve Bonine 1:115/777 Treasurer
IFNA BOARD OF DIRECTORS
DIVISION AT-LARGE
10 Courtney Harris 1:102/732? Don Daniels 1:107/210
11 Bill Allbritten 1:11/301 Hal DuPrie 1:101/106
12 Bill Bolton 3:711/403 Mark Grennan 1:147/1
13 Rick Siegel 1:107/27 Steve Bonine 1:115/777
14 Ken Kaplan 1:100/22 Ted Polczyinski 1:154/5
15 Larry Kayser 1:104/739? Matt Whelan 3:3/1
16 Vince Perriello 1:141/491 Robert Rudolph 1:261/628
17 Rob Barker 1:138/34 Steve Jordan 1:102/2871
18 Christopher Baker 1:135/14 Bob Swift 1:140/24
19 David Drexler 1:19/1 Larry Wall 1:15/18
2 Henk Wevers 2:500/1 David Melnik 1:107/233
-----------------------------------------------------------------
FidoNews 5-50 Page 23 12 Dec 1988
__
The World's First / \
BBS Network /|oo \
* FidoNet * (_| /_)
_`@/_ \ _
| | \ \\
| (*) | \ ))
______ |__U__| / \//
/ Fido \ _//|| _\ /
(________) (_/(_|(____/ (tm)
Membership for the International FidoNet Association
Membership in IFNA is open to any individual or organization that
pays a specified annual membership fee. IFNA serves the
international FidoNet-compatible electronic mail community to
increase worldwide communications.
Member Name _______________________________ Date _______________
Address _________________________________________________________
City ____________________________________________________________
State ________________________________ Zip _____________________
Country _________________________________________________________
Home Phone (Voice) ______________________________________________
Work Phone (Voice) ______________________________________________
Zone:Net/Node Number ____________________________________________
BBS Name ________________________________________________________
BBS Phone Number ________________________________________________
Baud Rates Supported ____________________________________________
Board Restrictions ______________________________________________
Your Special Interests __________________________________________
_________________________________________________________________
_________________________________________________________________
In what areas would you be willing to help in FidoNet? __________
_________________________________________________________________
_________________________________________________________________
Send this membership form and a check or money order for $25 in
US Funds to:
International FidoNet Association
PO Box 41143
St Louis, Missouri 63141
USA
Thank you for your membership! Your participation will help to
insure the future of FidoNet.
Please NOTE that IFNA is a general not-for-profit organization
and Articles of Association and By-Laws were adopted by the
membership in January 1987. The second elected Board of Directors
was filled in August 1988. The IFNA Echomail Conference has been
established on FidoNet to assist the Board. We welcome your
input to this Conference.
-----------------------------------------------------------------
FidoNews 5-50 Page 24 12 Dec 1988
INTERNATIONAL FIDONET ASSOCIATION
ORDER FORM
Publications
The IFNA publications can be obtained by downloading from Fido
1:1/10 or other FidoNet compatible systems, or by purchasing
them directly from IFNA. We ask that all our IFNA Committee
Chairmen provide us with the latest versions of each
publication, but we can make no written guarantees.
Hardcopy prices as of October 1, 1986
IFNA Fido BBS listing $15.00 _____
IFNA Administrative Policy DOCs $10.00 _____
IFNA FidoNet Standards Committee DOCs $10.00 _____
SUBTOTAL _____
IFNA Member ONLY Special Offers
System Enhancement Associates SEAdog $60.00 _____
SEAdog price as of March 1, 1987
ONLY 1 copy SEAdog per IFNA Member
Fido Software's Fido/FidoNet $100.00 _____
Fido/FidoNet price as of November 1, 1987
ONLY 1 copy Fido/FidoNet per IFNA Member
International orders include $10.00 for
surface shipping or $20.00 for air shipping _____
SUBTOTAL _____
MO. Residents add 5.725% Sales Tax _____
TOTAL _____
SEND CHECK OR MONEY ORDER IN US FUNDS:
International FidoNet Association
PO Box 41143
St Louis, Mo. 63141
USA
Name________________________________
Zone:Net/Node____:____/____
Company_____________________________
Address_____________________________
City____________________ State____________ Zip_____
Voice Phone_________________________
Signature___________________________
-----------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink