FidoNews is published weekly by the System Operators of the
FidoNet (r) International BBS Network as its official newsletter.
Its contents represent a compendium of articles freely submitted
and openly published by members of the FidoNet (r) community.
You are encouraged to submit articles for publication in
FidoNews. Article submission standards are contained in the file
ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous
Mail system, available for network mail 24 hours a day.
Copyright 1990, Fido Software. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only.
For use in other circumstances, please contact Fido Software at
(415)764-1688.
This is a compilation of individual articles contributed by their
authors or authorized agents of the authors. Contribution of
these articles to this compilation does not diminish the rights
of the authors.
Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, 164 Shipley St., San Francisco, CA 94107 and are
used with permission.
We don't necessarily agree with the contents of every article
published here. Most of these materials are unsolicited. No
article submitted by a FidoNet SysOp will be rejected if it is
properly attributed and legally acceptable. We will publish
every responsible submission received.
Table of Contents
1. EDITORIAL ................................................ 1
And Now -- FidoNet after IFNA ............................ 1
2. ARTICLES ................................................. 2
Come to FidoCon '90! ..................................... 2
Internetwork Gateway Policy - Another Perspective ........ 5
And more!
FidoNews 7-05 Page 1 29 Jan 1990
I have heard that this past weekend's IFNA meeting came to an end
with IFNA remaining alive. As I hear it, the reason has to do
with corporate laws which make it necessary for the paid-up
members of IFNA to vote in favor of dissolution before the board
can act.
This of course doesn't necessarily have any bearing on the
operations of the net. IFNA has been a largely irrelevant
presence for the past two years or so, and the fact that today it
continues to exist changes nothing. In fact, if you carefully
read this week's nodelist, or for that matter the first page of
FidoNews, you will see that life is indeed going on without IFNA.
Since IFNA continues to exist, and since its bylaws require that
it regard FidoNews as its official publication, there will no
doubt be many articles here, probably until some time after the
formal ending of the Association. Most, I suspect, will relate
to official business that simply must be transacted.
Be patient with them. And please don't get the idea that I
consider it appropriate to start dancing on IFNA's grave. IFNA
was a damned fine idea which died of a particularly toxic mixture
of cynicism and apathy. When the time finally comes, I'll mourn
the passing of this idea, if you don't mind. Please just allow
me my moment of silence. Thank you.
-----------------------------------------------------------------
FidoNews 7-05 Page 2 29 Jan 1990
by Bill VanGlahn, 1/90, FidoCon Committee Chairman
As you may or may not know, this year's FidoCon is being hosted
August 1-5 at the Conclave '90 sysops convention by the Secret
Sysop Society in Net 107 in New Jersey. As you can probably
guess by the name, we're out to have some fun! Well, now that
we've gotten our act together, here's some of the details, but
remember, don't tell anyone! It's a SECRET! ;-)
We wanted this year's FidoCon to be more than just a convention.
Past FidoCon's have been lots of fun for the sysops, but
probably pretty boring for the rest of the family, so we've gone
out of our way to make sure that this year you can plan on
spending a real vacation here in the New York/New Jersey
metropolitan area.
Additionally, we've also simplified the registration procedures
with our all-inclusive "chinese menu" registration form (to be
published next week or the following). No longer will you have
to worry about what meals you're going to attend, make your own
room reservations, etc. Just pick the plan you want to have,
and we'll take care of the rest!
Well, on with the show:
Plans A & B include the hotel room, all meals (including
Friday's banquet), and the conference fee, all in one cost.
Please note the discounts for early registration:
Before 6/1/90: Before 4/1/90:
-------------- --------------
A. Single Occupancy.......$595.00 $545.00 $495.00
B. Double Occupancy.......$450.00 $400.00 $350.00
C. Conference w/ meals....$300.00 $250.00 $200.00
D. Conference w/ Banquet..$205.00 $155.00 $105.00
E. Conference only........$175.00 $125.00 $75.00
F. Banquet only...........$130.00 $80.00 $30.00
(Those registering before 4/1/90 get a $100.00 discount, those
registering before 6/1/90 get a $50.00 discount on all plans.)
The conference opens with a pool-side welcoming cocktail party,
at which beer & wine will be covered by your meal ticket.
Friday night will be the sysop's banquet, which is also included
in plans A-D (and F, of course), and there'll be a special
barbecue lunch on saturday afternoon.
FidoNews 7-05 Page 3 29 Jan 1990
Seminars will be held from 10am till noon, and from 1PM until 4,
to give all participants plenty of time to recover from those
all-night 'bull sessions' where the REAL activity takes place!
We promised you outdoor activies, too, so here they are:
(Since we're dealing with sysops, we've formatted the 'external
events' into an event table)
Start End
Thu 08:30 16:30 ;Day trip to the Beach $24.50
Thu 14:30 22:30 ;Bus trip to Atlantic City $22.00
Thu 17:30 23:00 ;Twilight Manhattan Tour $37.50
Thu 18:30 23:00 ;A Night On Broadway $71.00
Fri 07:30 17:30 ;Daytime Shopping Tour: NYC $36.50
Fri 08:30 16:30 ;Day trip to the Beach $24.50
Fri 14:30 22:30 ;Bus trip to Atlantic City $22.00
Fri 17:30 23:30 ;Twilight Manhattan Tour $37.50
Sat 17:00 23:00 ;Twilight Manhattan Tour $37.50
Sat 19:30 22:00 ;Grand Costume Ball $50.00*
* Costume mandatory, and included in entrance fee
The TWILIGHT TOUR of New York includes a ride through Times
Square (you know, that place you see every New Year's Eve), the
marquees of Broadway, a trip to Macy's, the world's largest
department store, a walking tour through Greenwich Village, then
a ride through Soho and Little Italy and then to Chinatown for
dinner. The tour then continues on to the financial district of
Wall Street, and Battery Park, where you'll board a ferry that
will take you across New York harbor to Ellis Island and a
breath-taking view of the Manhattan skyline. The tour then
finishes off with a trip past the United Nations building,
Rockefeller Center, the Channell Gardens, and terminates at the
Empire State building. All in all, the tour takes about 5 hours
and is well worth the fee of $37.50.
The Grand Costume Ball will be held at Medieval Times, a new
type of dinner theater, where the times of King Arthur are
brought to life again. The theater is an actual medieval area,
where feats of heroics, jousting tournaments, and demonstrations
of Renaissance life are recreated, all while you enjoy a true
Medieval feast! Costumes are mandatory, and included in the
$50.00 fee.
The day trips to the beach are held at the famous New Jersey
Shore, at beautiful SEAside Park. Lay on the beach all day, or
enjoy the amusement park on the boardwalk! Anyone for miniature
golf? $24.50 includes bus fare.
FidoNews 7-05 Page 4 29 Jan 1990
Trips to Atlantic City include bus fare to the famous casinos on
the board walk, as well as casino 'comps' (coupons, rebates,
free tickets, etc.). The activities on the beach and boardwalk
are also available for those not into the fast action and bright
lights of the casinos. $22.00
For those so inclined, registration also includes use of the on
premises Meadowlands Health Club and all equipment, and free
admission to Cricket's nightclub and disco.
For further information, please contact me at 1:1/90.
Of course, we'll have the usual airline discounts (details
soon), so we hope to see you all there!
-----------------------------------------------------------------
FidoNews 7-05 Page 5 29 Jan 1990
I submitted this article not in an attempt to elicit additional
caustic reactions to the "Gateway Document" but rather in an
attempt to clarify and correct a few misconceptions and to
publicly answer some questions I've been asked frequently since
the document was published.
I'd like to begin with some answers to some commonly asked
questions:
- "Is the Gateway Document in effect now? The article said it
would go into effect in 30 days."
No, the document is not in effect. No, that is not what the
article said would happen. The article said the document would
be submitted to the International Coordinator for approval in
thirty days. Everyone will be given ample notice before the
document goes into effect. Stay tuned to FidoNews.
- "I'm the IC of XYZ-Net. Am I going to loose my echomail feeds
when the document is implemented?"
No evil FidoNet axe will fall upon your echomail feed at midnight
on the day the document goes into effect. The Internetwork
Coordinator will help you find the software necessary to comply
with the requirements. No reasonable request for assistance or
additional time has or will be refused. Please contact the
Internetwork Coordinator for further information on the
registration and certification process. Over a half dozen
networks have already registered. None of them were turned down.
- "If my nodes have FidoNet addresses then I can't get a gateway,
right? The document says that if you have a FidoNet address you
must get your echomail directly from FidoNet."
Wrong. The document says that this is the expected method. It
assumes that most folks with other than a purely political
motivation would prefer to take the shortest distance between two
points. The overriding consideration is that non-FidoNet
addresses not appear in FidoNet echomail while said echomail is
inside FidoNet and that all echomail gateways also be
bidirectional netmail gateways. If you have a case to make with
respect to this issue, please make it (even if it is purely
political). The key issue in my mind is that you demonstrate a
willingness to cooperate with FidoNet in good faith on technical
and administrative issues. We certainly pledge to cooperate in
good faith with you. Don't believe everything you hear. I
suggest you contact the Internetwork Coordinator directly and see
FidoNews 7-05 Page 6 29 Jan 1990
for yourself if all the dire predictions are true.
- "Where do you get the authority to implement such a document?"
I direct your attention to Section 7.1 of Policy4 as adopted by
FidoNet.
I was going to address some other points next. However, I think
the following echomail reply to what, in my opinion, was a very
sincere message from Jack Decker makes these points more
concisely than any rewording I could come up with. I would like
to thank Mr. Decker for his reasoned approach to this issue.
Msg # 2907
From: Tim Pearson
To: Jack Decker
Subj: Re: gateway proposal
________________________________________________________________
> I have never conversed with you before so I hold no
> preconceptions (good or bad) about you. I assume that you
> felt there was some sincere need for this Gateway Document.
Yes I do feel that there is a sincere need for the document. I'll
try to explain why as we go along here...
> I hope you saw my article in Fidonews in which I expressed
> some reservations about this document.
I do remember reading one you wrote, Jack. To be totally honest,
as I sit here now, I can't remember what points you made versus
points made by others who wrote similar articles. As you say,
there have been several. I'm sorry I can't recall it more
clearly.
> ... if there is any consensus at
> all, it is that folks don't seem to feel that there is any
> need for this document, and/or that it is actually designed
> to cause problems for the other networks and to build
> additional barriers between the other networks and Fidonet.
I'm afraid I can't subscribe to your conclusion, Jack, although
from looking only at the public record I can certainly see how
you arrived at it. I would think the same thing had I only had
FidoNews articles to rely on. The fact is that I (and others on
the GPDC) have received numerous positive comments via netmail
from folks inside as well as folks outside FidoNet. We have
received applications from over a half dozen "Other Networks"
(none of which have been rejected, by the way) who seem willing
to accept even the original draft of the document. Human nature
makes things work kind of like the evening news. One usually
doesn't hear loud and long public outcry from those who are
FidoNews 7-05 Page 7 29 Jan 1990
satisfied with the way things are going. They have no incentive
to "go public." Similarly, you don't see evening news broadcasts
filled with reports on how things are going right in the world
very often. To be quite honest, I feel that (as we so clearly saw
in the IFNA referendum) the "I don't give a damn's" are in the
majority again in this case.
>
> My only question would be, who asked for this document and
> why do we need it? I know you guys put a lot of work into it
> but if the general consensus of sysops in Fidonet was that
> we don't need this, would you guys consider dropping the
> whole idea? Or are there one or more people who are
> determined to push this through whether anyone wants
> it/feels it is needed or not?
>
I've already spoken to the "general consensus" issue above so I
won't waste your time with a restatement of that position. I will
try to address the "who asked for it?" part of your question.
This was an ongoing process when I became an RC almost exactly
one year ago. David Dodell was IC then as I'm sure you remember.
David, Randy Bush and virtually all of the RC's at the time (and
now as far as I know) seemed to feel that we had a problem that
would only get worse. We couldn't possibly make these other
networks go away even if we wanted to (and we didn't want to).
Therefore, we felt and feel that we should try to put a set of
guidelines in place to try to bring some order to the chaotic
"grab a zone" practice that was ongoing at the time. David was
getting netmails every week asking him as IC to "assign" so and
so zone such and such. He was getting messages whose content
consisted of irate complaints about network "A" having zone 123
before network "B" and how he should make network "B" use some
other zone number. It was a mess. I think I do remember you
saying that we are all agreed that Zonegates don't make proper
network gateways. Well, then and now, many folks feel they do. I
don't think it is malicious. I just think they don't know any
better.
I tried to bring forward another problem in the lead-in article I
wrote when the draft document was published. That problem being
that these illicit zone numbers were breaking FidoNet/Internet
gateways. (Someone took issue with the use of the word "illicit".
From FidoNet's point of view, that is what these non-FidoNet
addresses are.)
Someone somewhere made the suggestion that this could all be
fixed if only FidoNet would compile all the FTN Other Network
nodelists along with its own. We have enough trouble keeping our
own nodelist current. The technical and logistic nightmare this
would create should be obvious. Not to mention the "minor"
problem that several FTN other nets are using the same zone
number.
FidoNews 7-05 Page 8 29 Jan 1990
The only workable solution we could come up with was simply to
require that only FidoNet addresses appear in FidoNet mail. That
means that some other networks are going to have to change the
way their gateways work. We are in the process of helping
several other networks to obtain and implement the software
necessary to run a proper gateway right now.
> I guess I just don't see the need to put up additional walls
> between the networks. I think most of us are in this hobby
> to communicate with each other, not to figure out ways to
> make communications difficult. This document honestly seems
> to be moving us in the wrong direction, unless I'm really
> missing the reason it's needed...
I'm not going to get into a counterproductive discussion of why
these "walls" exist and who raised them. The fact is that they
exist because other networks exist. These other networks have
their own way of doing things, their own nodelists, their own
addressing schemes, and their own reasons for existance. All of
that is fine. We are attempting to cut some standardized
bidirectional "doors" in these walls.
We are not trying to make communication more difficult. The fact
is, Jack, that communication is virtually impossible (via
netmail) to many of the current other networks that are using
FidoNet echos. How can we possibly enforce moderator's rules
about topical limitations when the option to "take it netmail"
doesn't exist in many cases? I would like to see one standard
method agreed upon for internetwork routing. I don't care if it
is the RBBS-Net method or the ^ADOMAIN method or something else
entirely as long as it works -- both directions.
One last point and then I'll let you rest your eyes. I've heard
many people say how biased and unfair the document is. Consider
the analogy to a trade agreement between the U.S. and, say,
Japan. The folks in the U.S. think the Japanese are being
unfair. The Japanese think the folks in the U.S. are being
unfair. It is all a matter of perspective. Folks in FidoNet
look at it from the FidoNet perspective. Others look at it
differently. My job as a FidoNetter is to look out for the best
interest of my network. I'm trying to do that. If I did any
less, I would be derelict in my obligation to my network. Folks
have every right to establish as many other networks as they
like. If we're honest, Jack, we'll admit that without FidoNet
echomail, most of them would wither on the vine. Is it too much
to ask that they partake of their lifeblood in a manner not
harmful to their host? I hope you would agree that the answer to
that question is no.
Take care (sorry for my verbosity),
FidoNews 7-05 Page 9 29 Jan 1990
Tim
-----------------------------------------------------------------
FidoNews 7-05 Page 10 29 Jan 1990
Re-formatted for FidoNews from original SYSOP echo message.
Date: 23 Jan 90 10:37:37
From: Walter Tietjen (1:151/114)
To: Tim Pearson
Subj: Re: gateway proposal
TP> Someone somewhere made the suggestion that this
TP> could all be fixed if only FidoNet would compile
TP> all the FTN Other Network nodelists along with
TP> its own. We have enough trouble keeping our own
TP> nodelist current. The technical and logistic
TP> nightmare this would create should be obvious.
TP> Not to mention the "minor" problem that several
TP> FTN other nets are using the same zone number.
_NO_NEED_ for FidoNet to compile an OtherNet's nodelist. The ZC
of AnyOtherNet could compile his own nodelist using the keywords
SINDEX and either FIDOTXT or FIDOPRN in his XLATLIST.CTL file (or
equivalent if using a different nodelist compiler). Take the
sorted index at the end of his NODELIST.TXT/NODELIST.PRN file.
Example for AlterNet - Dos-command `COPY NODELIST.PRN
ANETLIST.PRN'. AnyOtherNet ZC then fires up a text editor. `EDLIN
ANETLIST.PRN'. Delete the tedious node-by-node list at the top, &
keep the net by net sorted index. Now netmail file-attach the
`sorted-index-only' to a volunteer at a `central-clearing-house'
serving _ALL_ networks (FidoNet included).
At the `central-clearing-house', the volunteer compares the
`SINDEX-only' NODELIST.PRN from FidoNet, ANETLIST.PRN from
AlterNet, NETLIST.PRN from NETWORK/FamilyNet, RBBSLIST.PRN from
RBBS-Net, EGGLIST.PRN from EggNet, etc.
Said volunteer looks for `net' number (of <Net>/<Node>)
collisions where 2 or more political networks use the same `net'
number. _IMPERATIVE_ that only one network use a `net' number
within any FidoNet Geo-Zone - (Easier on mailer software if `net'
numbers were only used once world-wide, but not essential.)
TP> The only workable solution we could come up with
TP> was simply to require that only FidoNet addresses
TP> appear in FidoNet mail.
See Above.
Primary reason for leaving `foreign net' (ie non-FidoNet)
addresses in echomail "seen-by" lines is "dupe" control. ANY
`circular feed' causes dupes. If a seen-by-stripping
internet-echogate is included in an accidental `circular feed',
the dupes are spread much farther than a `circular feed' which
does not include an echogate in the path.
FidoNews 7-05 Page 11 29 Jan 1990
JD = Jack Decker
JD> I guess I just don't see the need to put up additional walls
JD> between the networks. I think most of us are in this hobby
JD> to communicate with each other, not to figure out ways to
JD> make communications difficult. This document honestly seems
JD> to be moving us in the wrong direction, unless I'm really
JD> missing the reason it's needed...
TP> We are not trying to make communication more
TP> difficult. The fact is, Jack, that communication
TP> is virtually impossible (via netmail) to many of
TP> the current other networks that are using FidoNet
TP> echos. How can we possibly enforce moderator's
TP> rules about topical limitations when the option
TP> to "take it netmail" doesn't exist in many cases?
A periodic (maybe monthly?) list of those FidoNet/AnyOtherNet
multi-ID systems which have `AnyOtherNet' nodelists FReqable and
which `AnyOtherNet' nodelists are available there. Freq. the
desired nodelist from a multi-ID system, then send direct netmail
to the desired AnyOtherNet single-ID system.
Example: Dual-ID FidoNet 1:151/114 - AlterNet 7:48/2022 has both
the AlterNet and NetWork/FamilyNet nodelists available for FReq.
even though it is not in Network/FamilyNet. Extract from the list
you would get if you FReq'ed `FILES' from 1:151/114 on Jan 23.,
1990 :
ANETDIFF.A19 2635 AlterNet nodediff - ANETDIFF
ANETLIST.019 49242 AlterNet nodelist - ANETLIST
FIX1990.LZH 2400 OPUS event bug fix for 1990
NETDIFF.A19 1985 The Family nodediff - FMLYDIFF
NETLIST.019 41600 The Family nodelist - FMLYLIST
NODEDIFF.A19 37782 FidoNet nodediff - NODEDIFF
NODELIST.A19 274718 FidoNet nodelist (PKPAK squashed)
- NODELIST
TP> I would like to see one standard method agreed
TP> upon for internetwork routing. I don't care if
TP> it is the RBBS-Net method or the ^ADOMAIN method
TP> or something else entirely as long as it works -- both
TP> directions.
See paragraphs directly above my edited FILES list.
In addition to the 2-step method of first FReq'ing the desired
AnyOtherNet nodelist then sending direct netmail, _REAL_ working
zonegates could be set up between the various networks.
Back in the days when NETWORK and RBBS-Net were formed, everyone
_THOUGHT_ "Zones" _HAD_ to be single-digit numbers causing a
false appearance of a shortage of usable zones. Actually only the
TABBY package (versions 2.1 and earlier) has the single-digit
zone problem. QuickBBS will handle zone numbers 1-255, and
BinkleyTerm will handle zones 1-4095 (.001 - .FFF extensions on
the separate holding-area for each zone setup).
RBBS-Net could switch to a multi-digit zone number thereby
eliminating the "2 zone 8s" conflict. Same basic principle
applies to any/all other "shared zone" conflicts.
-----------------------------------------------------------------
FidoNews 7-05 Page 13 29 Jan 1990
Jack Decker
1:154/9, 11:154/8
A MODERATED ECHOMAIL CONFERENCE PROCESSOR
-or-
MY TWO BITS' WORTH
[continued from last week]
AN OPTIONAL ADD-ON TO THE BASIC PROPOSAL
Last week I presented the basic proposal for a moderated
echomail conference processor. I'd also like to throw out a
proposal for an option that would partially emulate one other
advantage of GroupMail, namely, that every system that receives
a conference gets the same message bundle. Please note that
the following discussion applies to message packets that are
being sent downbound from the conference moderator's system,
NOT to messages that are upbound to the moderator, and that the
following is really a separate proposal from the above. The
following discussion will be meaningless if moderated
conference mail is not implemented, but what follows should be
considered an optional add-on to the basic moderated conference
mail proposal described above. This add-on will greatly
facilitate the handling of pass-thru conferences when
implemented as part of any moderated conference mail processor.
First, an explanation of the GroupMail feature we're trying to
improve upon: Under GroupMail, when a system receives a
message bundle for a particular conference, it does NOT unpack
and re-toss the bundle before passing it along to any downlinks
that receive the conference from that system. Instead, the
bundle is passed along unchanged, just as received. So, if the
unpacking software "grunges" a message (as often happens when a
disk full or similar unexpected condition occurs), it only
affects the display of the message on that particular system,
and does not affect the condition of the message bundle
received at any downstream system.
GroupMail does this by building a separate message bundle (and,
ultimately, a separate .ARC file) for each and every available
conference. The advantage of doing this can be explained if
you consider the case where (for example) you feed a large echo
to several different systems. With echomail you have to toss
the messages separately for each system. Thus, if you receive
a 200K packet of FOR-SALE and feed it to five systems, you'll
need one meg of free space (5 systems * 200K) just to toss
those messages to the five individual systems, plus some
additional room to allow the archiver to try and compress those
packets. With GroupMail, you'd receive the one 200K packet (in
ARCed format) and store it in a holding area, and that one
packet would be sent to all five systems.
FidoNews 7-05 Page 14 29 Jan 1990
The disadvantage of this scheme is that if all conferences are
stored in individual archives, then a system receiving seventy
different GroupMail conferences could conceivably receive
seventy different archives (one for each conference) every
night. As fast as most mailers are, there is still a certain
amount of turnaround time required each time a different file
is sent, so transmitting a number of small archives instead of
one large one increases the connection time required to receive
one's nightly echo feeds. Also, each conference archive must be
individually named in such a manner as to prevent name
collisions, while not using a filename that may have some
meaning to a mailer program (e.g. a filename that might appear
to be an attach file or a request file or a mail packet).
There's also the question of how long to retain each individual
message archive. As mentioned above, with echomail you will
temporarily create one copy of the messages in any given
conference for EACH system receiving the conference (so, if you
are feeding an echo to five different systems, you will
temporarily have five different copies of the messages in that
echo on your system). BUT, as these message packets are sent
to the recipient systems, they are automatically deleted from
your system. With GroupMail, you only keep one copy of any
given set of echo messages, but you have to keep it around
until all the systems you've fed the echo to have had a chance
to retrieve it from you system. Given that systems sometimes
have technical problems that may keep them from connecting on a
given night, and sysops sometime go away for weekends (at which
point Murphy invariably takes over and crashes their systems),
the normal retention time for GroupMail echoes has to be set at
3 to 5 days in order to make sure that no messages are "missed"
by any downstream system. So the advantage of only having to
store one copy of the messages in a given conference for all
the nodes you feed it to is largely negated by the requirement
to keep 3-5 days's worth of messages around in order to make
sure that none of the systems you feed miss any messages.
Finally, when the same message archive is sent to all systems
you feed, it must be stored in an archive format that can be
uncompressed at all systems being fed. Unfortunately, none of
the best archivers are portable across all computing
environments found in Fidonet. So the "least common
denominator" approach is used (.ARC format archives in the case
of GroupMail) which insures that virtually all systems
receiving GroupMail packets can unARC them without difficulty,
but at a cost of longer transmission times and greater disk
space storage requirements than would be necessary if a newer
archiver could be used.
For these and other reasons, I do not feel that storing each
day's worth of messages from a conference in an individual
ARCHIVE file is a good idea. However, storing each conference
in a separate BUNDLE (that is, a separate .PKT file) which is
then packed to each recipient might be an effective way to
transmit moderated conference mail.
FidoNews 7-05 Page 15 29 Jan 1990
Let's consider how an advanced conference mail processor might
handle moderated conferences:
1) An incoming mail ARCHIVE (a .mo?, .tu?, ... .su?) file
arrives from another system.
2) The conference mail processor finds this packet, determines
which archive format was used to create it (ARC, ZIP, LHARC,
ZOO, etc.) and calls the proper de-archiver to decompress the
file and recover the individual .PKT files.
3) The header of the .PKT files are examined and if they are a
standard .PKT file (as currently used) they are processed in
the normal manner (messages are tossed/scanned to/from the
appropriate netmail or echomail areas). However, if the header
indicates that the incoming .PKT file is a moderated echo
conference, it is temporarily moved to a separate directory
(actually, placing these files in a separate directory may not
be necessary, but it's easier to mentally visualize the process
if we separate these files). Please note that each of these
new type .PKT files will contain messages from only one
moderated conference per .PKT file (for example, if we received
feeds of FOR-SALE, TECH, and COMM, we'd get three moderated
conference style .PKT files, one for each of the three
conferences). Also please note that both types of .PKT files
may be intermixed in the same mail archive (this solves the
problem of having to transmit multiple files).
4) As the new style .PKT files are moved to the holding area, a
temporary index is constructed showing which conference area
tag relates to each of the .PKT files (for example, showing
that packet 12345678.PKT contains messages for the FOR-SALE
echo). Each area tag in the index is then examined and the
associated .PKT file may be handled in any of the following
ways:
If the .PKT file is NOT associated with a passthru area, then
the messages in that .PKT file are tossed to the appropriate
message areas on your system.
If the .PKT file is associated with an area that is fed to
other (downstream) systems, then the .PKT file is archived into
an outgoing mail ARCHIVE (a .mo?, .tu?, ... .su?) file destined
for each of those systems, WITHOUT change. The .PKT file that
is received is the .PKT file that goes out. Note that in this
case the PATH line in the messages cannot be changed. However,
the integrity of the .PKT file is maintained (assuming that no
errors were encountered in the process of unarchiving the .PKT
file in the first place... obviously, such errors should be
trapped).
FidoNews 7-05 Page 16 29 Jan 1990
It should be noted here that if a moderated conference is
converted to regular echomail, then it MUST be unpacked and a
SEEN-BY line must be added to each message, and the system's
net/node number must be added to the PATH line of each message.
The messages in that conference may then be re-packed as
echomail to the conference in question. To do otherwise would
defeat the duplicate message security built into this scheme
(this would in most cases make the use of the -p and -e
switches together on the same AREAS.BBS line invalid, however,
I suppose a truly ambitious programmer could figure out a way
to adjust the PATH lines in the .PKT files of passthru
conferences without first unpacking and tossing the individual
messages).
5) Once the individual .PKT files have been tossed to your
system and/or archived to other downstream systems that receive
them from you, they are deleted immediately (generally in the
same scan/toss cycle), and don't hang around taking up space on
your system (some software might allow you to optionally
override this if for some reason you wanted to keep the .PKT
files around for a day or two).
One might reasonably ask how a conference mail processor is
supposed to know that a .PKT file contains a moderated echo
conference, and how to determine the area tag. Please consider
the header of a typical .PKT file:
PktHType = Record
OrigNode : integer;
DestNode : integer;
Year : integer;
Month : integer;
Day : integer;
Hour : integer;
Minute : integer;
Second : integer;
DestBaud : integer;
PktVers : integer;
OrigNet : integer;
Destnet : integer;
Product : char;
filler : char;
PwdKludge : Array[1..8] of char;
filler : Array[1..24] of char;
end;
Since the baud rate of the destination system is a totally
useless piece of information in an echomail header packet (and
since virtually all systems get this information from someplace
other than the packet header anyway), I propose that we utilize
one byte of this integer as a "signature byte" which will
indicate to a conference mail processor that this is a
moderated echomail packet. No true modem baud rate currently
in use is an odd value (I think we can safely ignore the
oddities such as 1200/75 splits used by commercial videotex
services in some countries), therefore, bit 0 of the least
FidoNews 7-05 Page 17 29 Jan 1990
significant bit of the least significant byte will never be set
if this field really contains a modem value. I therefore
propose the field be redefined as follows for moderated
conference mail:
Instead of: DestBaud : integer;
We'd use: EchoPktFlag : Char;
SerialNo : Char;
Where the echo packet type would be defined as follows:
Bit 0 1 if moderated conference mail, 0 otherwise
Bits 7-6 Reserved for future use
Again, the implication is that if bit 0 is not set, the packet
is a normal mail packet containing regular netmail or regular
echomail (or both). If bit 1 IS set, the packet contains ONLY
moderated conference mail which meets the following criteria:
1) The packet is exactly as it was when it left the
moderator's system (the .PKT file is totally unmodified except
for being unpacked and repacked) and,
2) The packet contains moderated echomail that is downbound
from the moderator ONLY and,
3) ALL messages in the area are for the SAME conference and
have the exact same AREA tag (the conference mail processor
will normally only read the first AREA tag of the first
message).
If the moderated conference .PKT file is changed in ANY way,
then the system making the change must reset bit 0 of the
EchoPktFlag (in effect changing the packet to a normal echomail
PACKET, although the messages contained therein would still be
flagged as part of a moderated conference) AND the system must
add its address to the PATH line of each message in the packet.
You will note that I have suggested a redefinition of the
second byte of the Destination Baud integer as a Serial Number
byte. This would simply be a byte value that is incremented at
the moderators' system each time a new message packet is issued
(with rollover from 255 to 0). In this manner the recipient of
a conference area could, if he so desired, keep track of this
value and thereby be alerted to any interruptions or missing
packets in the echo feed.
Actually, if I could be sure that the 24 bytes of filler in the
.PKT file header were not being used by anyone, I would suggest
that this information could go in there, rather than usurping
the DestBaud integer. Were that to happen, I'd prefer to see a
two-byte value for the serial number, and also a 32-bit CRC
value calculated on the portion of the .PKT file following the
header (e.g., starting with the first byte of the first message
header) to insure the integrity of the .PKT file.
FidoNews 7-05 Page 18 29 Jan 1990
It should be obvious, as you read the above, that a new style
moderated conference .PKT file would be completely compatible
with virtually all currently existing mail processors. These
processors would simply treat such packets as they would any
other bundle of incoming echomail. In fact, the ONLY reason
that such packets would need to be unpacked before sending to a
system that is only capable of handling regular echomail is so
that the required SEEN-BY line can be added, and the PATH line
updated, in order to protect against duplicate message
generation.
It should be noted that when the -m switch is used in the
AREAS.BBS file, a conference mail processor that supports this
optional add-on to the basic moderated conference mail scheme
should toss mail to the appropriate conference area as it is
received, but NOT scan (export) it unless a specific switch is
used on the command line when the mail processor is invoked.
Normally you'd have a once-daily event that would invoke the
processor with that switch, in order to scan and export
messages from any areas that you moderate, followed IMMEDIATELY
by a call to whatever you use to renumber and clean up that
message area. It would not normally be a good idea to
automatically delete messages from the conferences you moderate
at any time other than immediately after the daily message
export from that area (this would prevent messages arriving
after the export event but before the cleanup event from being
deleted before they can go out). And, of course, the moderated
conference mail processor would have to build the .PKT files
for each conference according to the specifications mentioned
above.
One potential problem exists at this point, and that is the
possibility of creating duplicate .PKT file names. Consider
that many conference moderators might decide to run their
once-daily export events at about the same time (just after
midnight, for example) and therefore a .PKT file naming scheme
based solely on time just might produce packets for different
conference areas with the same filenames. It would therefore
seem wise to at least try and avoid the potential for duplicate
filenames by using a .PKT file naming scheme that is not based
solely on the time of day.
The root portion of a .PKT filename may contain any valid
hexadecimal character (0-9 or A-F). Therefore, one possible
scheme might be to use a four character checksum of the
conference name plus some time dependent information. For
example, the following scheme might create adequately unique
filenames:
Mail packet filename format: cccctttt.PKT
FidoNews 7-05 Page 19 29 Jan 1990
.....where cccc is a 32 bit checksum of the conference area
tag, and tttt is the number of seconds past the start of the
month (at the time the .PKT file is created) expressed in
hexadecimal format.
No .PKT file naming scheme can GUARANTEE unique filenames for
conferences created on different systems, so it would be best
if the moderated conference mail packer could check existing
mail archives for duplicate filenames before adding a new .PKT
file (I realize this may be difficult to do, however, given the
number of different archiving programs in common use today).
If such a check were made, renaming of .PKT files to avoid name
collisions WOULD be permissible. Yet another possibility would
be to use a base 36 character set (0-9 or A-Z), or perhaps
better yet, a base 20 character set (the letters G-Z ONLY, to
positively avoid conflicts with .PKT filenames created by
existing mail packers) for the root part of moderated
conference mail .PKT filenames, and base these on some sort of
random numbering scheme. To some extent, the preferred method
of avoiding .PKT file name collisions should be left to the
software authors, but the (admittedly small) potential for
difficulty should not be ignored.
POLITICAL CONSIDERATIONS
The above about covers the technical end of this proposal.
Alas, there are the political considerations to contend with.
I propose the following as sort of a Policy Statement in regard
to moderated echomail:
1) Anyone who converts moderated echomail to regular echomail
may do so without prior permission to feed leaf nodes (nodes
that do not further distribute the conference further) ONLY.
If a node receiving a converted echomail feed wishes to pass
that feed along to other nodes, the conference moderator's
permission is required. In any event, the node that converts
moderated echomail to regular echomail is responsible for
knowing which systems are receiving the conference via his
system (either directly or indirectly) and for making sure that
"dupe loops" are not created.
2) It should be considered a serious violation of policy to
feed moderated echomail conferences to a node capable of
processing only regular echomail without inserting the required
SEEN-BY and PATH lines (put another way, within an AREAS.BBS
file the -d switch must NOT be used to feed a node that is not
running a "moderated conference mail aware" echomail processor.
The -e switch MUST be used instead).
3) As long as moderated echomail is distributed as moderated
echomail, (not converted to regular echomail), the propagation
of duplicate messages is nearly impossible. Therefore, there
is no reason that the distribution of moderated echomail
conferences needs to be restricted by anything other than
least-cost routing considerations (that is, geographic
restrictions are not really appropriate for conferences in
FidoNews 7-05 Page 20 29 Jan 1990
which duplicate messages cannot easily be propagated).
4) IF the new packet type as described above (with the header
bit indicating that the packet is moderated echomail) is used,
then it shall NOT be a requirement that the uplink and downlink
paths between any particular system and the moderator's system
be the same; however, if a conference is made available on a
BBS, then an uplink path for replies MUST be provided. The
intent of this provision is to allow specific conferences, or
groups of conferences, to be distributed via one-way channels
(e.g. radio or satellite feeds) to reduce the costs for those
wishing to receive the conference. However, if an uplink path
back to the moderator's system were not provided, users of a
BBS might wrongly assume that they could leave messages that
would be seen by all participants of the conference. Thus, the
requirement that an uplink path for replies must be made
available. The moderator of a conference may waive this
requirement (although doing so is not recommended except in the
case of "read-only" conferences).
5) Complaints that moderated echomail equals censorship are
really not valid. Consider that Fidonet echomail is one of the
few mediums in which folks seem to think they should be able to
say anything they doggone well please. Most sysops would not
allow users to post just anything that they might want to say
in any conference they feel like saying it in, yet some of
these same sysops will be the first to complain about anyone
who tries to implement some effective moderation in echomail.
This proposal addresses that concern by insuring that echomail
processors will be able to handle BOTH types of echomail (both
moderated and unmoderated) as easily as regular echomail is now
run. So it would not be an either/or choice for sysops and
echomail hub operators whether to run moderated or unmoderated
echomail. Right now we have echomail hubs that offer only
echomail conferences and GroupMail hubs that offer only
GroupMail conferences, but with software designed to be
compliant with this proposal, all hubs would be able to handle
both types of conferences. Thus, it would be strictly up to
the moderator of a conference as to whether that conference
should be moderated or unmoderated. In the case of conferences
that have been on the backbone for a long time, many would
undoubtedly remain as regular (unmoderated) echomail
conferences. But for new conferences, shouldn't it be the
moderator's option as to how closely he wishes to moderate a
conference? After all, no one will force anybody to join a
conference that they feel is too tightly moderated.
CLOSING COMMENTS
I think that about covers everything. If you feel this
proposal is missing something, please drop me a note at 154/8
or if that won't work for you, you can send it to 1:154/9. You
can also leave comments in the NET_DEV echo but keep in mind
that echomail currently isn't always as reliable as netmail,
and occasionally my feed of NET_DEV does seem to be interrupted
FidoNews 7-05 Page 21 29 Jan 1990
for various reasons (technical, not political!). One question
that I have left open (mostly because I don't really want this
proposal to get mired in political concerns) is whether some
mechanism should be included for routing private netmail
replies to echomail back up to the sender of the original
message via the same path that the original message came down?
I wouldn't mind seeing such a mechanism included, but it would
require some changes to the above proposal and worse, it might
make the whole proposal politically unacceptable in Fidonet
(besides that, I think there are better ways to devise a
netmail routing scheme for Fidonet, should we ever have the
collective will to do so. See my article in Fidonews 7-01 if
you'd like my thoughts on a netmail routing scheme).
I will probably send this proposal up to the Fidonet Technical
Standards Committee in a week or two, but I reserve the right
to make revisions first, based on any comments I may receive
from readers of these articles. Your constructive comments are
welcome.
-----------------------------------------------------------------
FidoNews 7-05 Page 22 29 Jan 1990
A Reply to Mr. Riddle
Phil Root
NC 285
285/0, 285/17
Having been forwarded a copy of Mr. Riddle's article on
the Proposed Gateway Policy Document, I'd like to mention a short
rebuttal. I feel that some of the 'facts' that he puts forth
could use some clarification, and perhaps, I can point out some
errors in his logic.
Point 1: Mr. Riddle says that the major issue facing Fidonet is
that of direction. I feel that he is wrong. He states the real
issues are how the current coordinators acceded to their
positions, how they remain there, the management and personal
attitudes they represent.... I think that this indicates that
the proposed Gateway Policy Document has absolutely nothing to do
with his dissatisfaction. It wouldn't matter at all if it was an
absolutely PERFECT document, (which it isn't, but that's a
different matter), the point that he makes is that since it was
proposed by the *c structure, and individual sysops were not
"consulted", etc. that it is somehow flawed. I find this logic
to be somewhat contorted.
Point 2: Mr. Riddle is mistaken in his assumption that POLICY 4
mandated membership in the local net. It doesn't. It does,
however, grant to the International, Zone, Regional and Network
coordinators the ability to manage the nodelist for the greatest
effeciency. In this case, the Regional coordinator saw that
there was an existing net in the Omaha calling area. There were
also 6 independent nodes in that area. Attempts to convince
those nodes to come into the net voluntarily had failed, and
under mandate from the Zone coordinator, the RC instructed that
those members were to be included in the Network nodelist. In
the same paragraph, there was another indication and reference to
an internal network dispute that needs no further clarification
here.
Point 3: In paragrph 3 of Mr. Riddle's comments, he states that
the *C's proposed internet gateway policy document was created in
an atmosphere of "narrow-minded and short-sighted, arguably ego-
tripping conduct". Such comments are really counterproductive.
A lot of work and thought went into the creation of this
document.
Point 4: There as never been any real proof that the vote was
flawed, and no one complained as long as the vote was going to
their liking. Further, Mr. Riddle offers no proof that the vote
was flawed. If the Board of Directors of a SEPARATE organization
decides to put a resolution to the sysops, and a majority of them
decide to ignore it, then I find nothing flawed in it, except
that it did not turn out to Mr. Riddle's advantage.
FidoNews 7-05 Page 23 29 Jan 1990
Point 5: I'm not going to comment on the debate excerpts the Mr.
Riddle chooses to publish. I think that they show even further
that his comments actually have very little to do with the
viability or non-viability of the Internet Gateway Document.
What we have here is another 'Fidonet sysop' complaining about
the age old complaint, "that we have no say". This is hogwash.
There is a complaint and appeal process clearly written into
POLICY 4. If a *C at almost any level refuses to listen, there
is ALWAYS the opportunity to go to the next higher level. Mr.
Riddle has the opportunity of seeking membership in another
network if he chooses. I should note that he is not even a full
Fidonet node, but a point off of 285/666. Not that this
diminishes his right to comment, and yes, I DID invite this
comment. However, I must confess, I had hoped for some
constructive criticism of the Gateway document, not a diatrabe on
the *c structure, and its supposed evils.
People were clamoring for democracy. They 'DEMANDED' that the
sysops be given a choice on matter. Yet, when the sysops were
given a choice, we saw the result. Most of the sysops did not
even bother to cast their ballots. We've seen that democracy CAN
work. However, it won't work in Fidonet without participation by
the sysops, any better than it works anywhere else without the
participation of the electorate.
-----------------------------------------------------------------
FidoNews 7-05 Page 24 29 Jan 1990
Regional Netmail Routing
-------- ------- -------
(Published For the Zone 1 Coordinator and RCs by 1:286/703.)
The Zone 1 Coordinator and the Zone 1 Regional Coordinators would
like to announce the creation of what we hope will be a helpful
service to the sysops in FidoNet Zone 1. The service is not new
to FidoNet but is new to Zone 1.
In a significant number of cases, it really shouldn't matter if a
netmail message is delivered in 5 minutes or 5 days. The Z1C
connects with each Zone 1 RC and with the Zone 2/3/4/5 zonegate
nightly. The Zone 1 RC's connect with each of their NC's at
least twice each week on FidoNews and Nodediff nights. These
already established connections could easily be utilized to offer
routing services for low priority netmail addressed to any
FidoNet destination. That is precisely what we've done. Although
this is currently labeled a "pilot project", we can currently
forsee no reason why it could not be implemented permanently.
FidoNet sysops in Zone 1 may feel free to route any low priority
netmail to any FidoNet Z1RC or to the Z1C. You should understand
that "low priority" means that you don't care if it takes up to 5
or 6 days for the message to arrive at its ultimate destination.
The transfer from RC to ZC to RC (or to zonegate) would take
place fairly rapidly. However, the speed with which the message
is delivered to the NC will vary from region to region based upon
how often RC connects with the NC (i.e. Friday & Monday for
Nodediff's and FidoNews or until the NC and RC connect for some
other purpose). NC's are invited to participate in this plan and
provide outbound low priority netmail routing (via the RC). NC's
please understand we said "invite" not "insist". That decision
us up to you and your network sysops.
Zone 1, feel free to use or ignore this offer as you please. We
hope that this plan will, as but one example, provide echomail
users with an incentive to take message threads that stray off
topic "to netmail". Yes, we could be deluged with so much traffic
that our collective pocketbooks could not bear the strain.
However, we prefer to trust the sysops of FidoNet and their users
to use this service judiciously and responsibly.
The regional routing plan is, to be sure, not mandated by Policy.
It was simply something that seemed to make sense and has been
voluntarily implemented. We hope that this proposal will be
received in the spirit in which it is offered. That being a
sincere effort to provide a service we feel we can afford to
those we serve. If it doesn't work out we are surely no worse
off than we are today. If it does, perhaps we can say we brought
netmail "out of the closet" and made it widely available to the
sysops and (more significantly to the) users in Zone 1.
FidoNews 7-05 Page 25 29 Jan 1990
Questions and comments may be directed to the Zone 1 Coordinator
or to any of the Zone 1 Regional Coordinators.
-----------------------------------------------------------------
FidoNews 7-05 Page 26 29 Jan 1990
By Bill Weinel
1:151/121.0 @ FidoNet
SCSI SYSTEM ONE: A SYSOP'S SCSI SYSTEM
SCSI System One: The History
----------------------------
One of the most frustrating problems I have found since
switching my BBS system over to a PC based computer is the PC's
inherent inability to deal with large HD storage spaces. (While
this problem has been remedied to some degree with the advent of
DOS 4.x, the hardware problem of multiple hard drive storage on a
single PC still exists.) This article is the story of some folks
who decided that "enough was enough" and did something about it.
About a year back, I became an SDS node and found myself
facing the situation of needing more hard drive storage on my
system. Not being the kind of person who could afford to go out
an plunk down $6000 for a brand new super-duper-800-megabyte-12-
millisecond-Super-Seeker hard drive, I decided that it was time
to start looking for some other reasonable way to break the 2
hard drive barrier on the PC. I quickly found that I wasn't alone
in my quest. A handful of other local sysops had been faced with
this same problem too. Enter Jeff Lengel.
Jeff is a local computer consultant, hardware engineer,
software hacker, and long time friend. We started discussing the
problem last January and decided that there was just no good
system available to fill the need for multiple hard drive storage
at the time. We had pretty much decided that SCSI was the route
to go, but at that time commercial SCSI systems for PCs were few,
and those that were affordable for sysops on our budget were
basically non-existant. Jeff said that he had seen some good
prices on SCSI hardware available through some mail order vendors
and that it should be possible to put together a software package
to make it all fly. None of us knew it at the time, but SCSI
System One was born right there.
Needless to say, Jeff found that writing the SCSI driver
code was a bit more than a trivial task. He started out in
assembler, but the code eventually out grew his ability to manage
it. So he converted all utilities over to C, leaving the driver
in assembler for speed. As time went by, Jeff got the basic
driver code finished. This allowed him to start testing the
SCSI controller hardware.
By June, he had a working SCSI driver which would allow
the PC to talk to the SCSI devices through a host adaptor card.
Once the driver was working correctly, he started to refine it to
work with various multi-tasking and BBS packages. He also added
the ability to use bridge controllers to the system. This opened
up the door for getting all those old retired ST506 type drives
out of the closet and back online again.
FidoNews 7-05 Page 27 29 Jan 1990
This is the point where my job started... Jeff needed a
few beta testers (guinea pigs?) to iron out the remaining flaws
in the driver. And of course there was that burning question that
still needed to be answered: "Would the SCSI driver really run
reliably with all that mailer/BBS software loaded on top of it?"
I volunteered to test it under DOS 3.3 while Mike Stroud
(1:151/102.0) volunteered to test it under DOS 4.x. Between the
two of us, we managed to thrash it pretty well. This helped Jeff
work out the few remaining kinks in the driver.
"So where are we today?", you ask. Well, today we have
five systems in net 151 now running a Scsi System One on a
day-to-day basis. Jeff has continued to improve the SCSI drivers
transfer rate and support for as many bridge adapters as he can
possibly find. At the same time, he has managed to develop a 150
megabyte automatic streaming SCSI tape backup system. This
addition to the his base system is a real sysops dream! It can be
left to run unattended in the wee hours of the morning through
use of an errorlevel exit and will automatically preform
incremental backups of your system while you sleep. It can backup
a 100 megabyte drive in file-by-file mode in about 16 minutes and
can be tailored, through use of a CFG file, to backup individual
files, subdirectories, or complete drives. Jeff's also working on
adding disk mirroring and a LAN link package for a future
release.
It's really hard to believe that just about a year ago
this was all a pipe dream floating around in the heads of a few
local folks. Today, thanks to a little hard work and extremely
patient wives, it's a reality. That just goes to show that a
little collaboration between sysops can go a long way!
SCSI System One: The Specs
--------------------------
-Meets ANSI X3T9.2 specifications
-Asynchronous interface up to 1.5 megabytes per second
-Supports full parity generation and checking
-Supports full SCSI arbitration and checking options
-Supports linked commands
-Supports bridge controllers
-Supports logical units
-Direct SCSI bus drivers
-Host interface: PC, XT, AT, 80386, true compatible (*)
. SCSI address 330h-337h
. DMA channel 3
-Supports DMA or PIO transfer
-Supports up to 7 physical drives (14 on bridge controllers)
-Supports up to 24 logical drives (total)
-Supports up to 536 megabytes per logical drive 3n3
FidoNews 7-05 Page 28 29 Jan 1990
-Supports complete compatibility between XT and AT bus types
-Compatible with Norton Advanced utilities Ver. 4.5 and
Fasttrax disk optimizer
(*) max bus speed 8 Mhz.
The system consists of one host adaptor card (half sized card),
partitioning/low-level formatting software and SCSI device
driver. A three foot SCSI interface cable is included. It
requires at least DOS 3.2 or higher.
Jeff has agreed that in an effort to aid the growth of the
'BBS Network' he will offer the SCSI System One host adapted
system to net sysops at a special rate. For more details on the
sysop offer, contact Jeff Lengel at the address below.
SCSI System One
1013 Ivy Lane
Cary NC 27511 USA
919-469-9750
Full information may be file requested by requesting SCSIONE from
1:151/121.0 anytime other than ZMH.
-----------------------------------------------------------------
FidoNews 7-05 Page 29 29 Jan 1990
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
-----------------------------------------------------------------
FidoNews 7-05 Page 32 29 Jan 1990
Announcing the DRUM_CORPS echo
------------------------------
DRUM_CORPS is an echo for chewing the rag about competitive
drum & bugle corps, marching bands, and Winter color guards.
It's on the backbone via the Eastern Star and is moderated by
yours truly. If you've ever played in a drum corps, college
band, high school marching band, or marched in a Winter color
guard, this is the place for you!
I've had a great deal of experience in drum corps over the
years, having taught them, played with them, run them, and
been a spectator too. And we're looking for other with similar
experience and interests.
During the competition season, we'll have scores & schedules
and general BS from other drum corps freaks around the
country. So ask your NEC to pick up DRUM_CORPS and join us!
