Volume 7, Number  5                               29 January 1990
    +---------------------------------------------------------------+
    |                                                  _            |
    |                                                 /  \          |
    |                                                /|oo \         |
    |        - FidoNews -                           (_|  /_)        |
    |                                                _`@/_ \    _   |
    |        International                          |     | \   \\  |
    |     FidoNet Association                       | (*) |  \   )) |
    |         Newsletter               ______       |__U__| /  \//  |
    |                                 / FIDO \       _//|| _\   /   |
    |                                (________)     (_/(_|(____/    |
    |                                                     (jm)      |
    +---------------------------------------------------------------+
    Editor in Chief:                                  Vince Perriello
    Editors Emeritii:                                     Dale Lovell
                                                       Thom Henderson
    Chief Procrastinator Emeritus:                       Tom Jennings

    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


    =================================================================
                                EDITORIAL
    =================================================================


    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


    =================================================================
                                ARTICLES
    =================================================================

    Come to FidoCon '90!

    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


    Internetwork Gateway Policy
    ------------ ------- ------

    Tim Pearson
    1:286/703


    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.

    -Walter

    --- ConfMail V4.00
     * Origin: TI-RALEIGH 919-833-3412 NCRTP 9986 (1:151/114)

    FidoNews 7-05                Page 12                  29 Jan 1990


    Adding to original SYSOP echo message:

    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


    =================================================================
                             LATEST VERSIONS
    =================================================================

                         Latest Software Versions

                              MS-DOS Systems
                              --------------

                          Bulletin Board Software
    Name        Version    Name        Version    Name       Version

    Fido            12q+   Phoenix         1.3    TBBS           2.1
    Lynx           1.30    QuickBBS       2.61*   TComm/TCommNet 3.4
    Kitten         2.16    RBBS          17.2B    TPBoard        6.0
    Opus          1.03b+   RBBSmail       17.2    Wildcat!      2.10*
                           TAG           2.5d1*


    Network                Node List              Other
    Mailers     Version    Utilities   Version    Utilities  Version

    BinkleyTerm    2.30    EditNL         4.00    ARC           6.02
    D'Bridge       1.30*   MakeNL         2.20    ARCA06        2.20*
    Dutchie       2.90C    ParseList      1.30    ARCmail        2.0
    FrontDoor     1.99b*   Prune          1.40    ConfMail      4.00
    PRENM          1.47    SysNL          3.01*   EMM           2.02
    SEAdog        4.51b    XlatList       2.90    Gmail         2.01
                           XlaxDiff       2.32    GROUP         2.16
                           XlaxNode       2.32    GUS           1.30*
                                                  LHARC         1.13
                                                  MSG            4.0
                                                  MSGED         1.99
                                                  PK[UN]ZIP     1.02*
                                                  QM             1.0
                                                  QSORT         4.03
                                                  StarLink      1.01
                                                  TCOMMail       2.2
                                                  TMail         1.12
                                                  TPBNetEd       3.2
                                                  TosScan       1.00*
                                                  UFGATE        1.03
                                                  XRS           3.10
                                                  ZmailQ        1.10*

                                Macintosh
                                ---------

    Bulletin Board Software   Network Mailers     Other Utilities

    Name            Version   Name      Version   Name       Version

    FidoNews 7-05                Page 30                  29 Jan 1990


    Red Ryder Host   v2.1b4   Tabby         2.1   MacArc        0.04
    Mansion            7.15   Copernicus   1.0d*  ArcMac         1.3
    WWIV (Mac)          3.0                       StuffIt       1.51
                                                  TImport      1.331
                                                  TExport       1.32
                                                  Timestamp      1.6
                                                  Tset           1.3
                                                  Import        2.52
                                                  Export        2.54
                                                  Sundial        2.1
                                                  UNZIP         1.01*

                                  Amiga
                                  -----

    Bulletin Board Software   Network Mailers     Other Utilities

    Name            Version   Name      Version   Name       Version

    Paragon            2.00+* BinkleyTerm  1.00   AmigArc       0.23
                              TrapDoor     1.11   booz          1.01
                              WelMat       0.35*  ConfMail      1.10
                                                  ChameleonEdit 0.10
                                                  Lharc         1.00*
                                                  ParseLst      1.30
                                                  PkAX          1.00
                                                  PK[UN]ZIP     1.01*
                                                  RMB           1.30
                                                  UNzip         0.86
                                                  Zoo           2.00


                                   Atari ST
                                   --------

    Bulletin Board Software   Network Mailer      Other Utilities

    Name            Version   Name      Version   Name       Version

    FIDOdoor/ST        1.5c*  BinkleyTerm 1.03g3  ConfMail      1.00
    Pandora BBS       2.41c   The BOX     1.20    ParseList     1.30
    QuickBBS/ST        0.40                       ARC           6.02*
    GS Point           0.61                       LHARC         0.51
                                                  PKUNZIP       1.10
                                                  MSGED        1.96S
                                                  SRENUM         6.2
                                                  Trenum        0.10
                                                  OMMM          1.40


    + Netmail capable (does not require additional mailer software)
    * Recently changed

    FidoNews 7-05                Page 31                  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


    =================================================================
                                 NOTICES
    =================================================================

    Glen Johnson, 1:269/101

                    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!

    Glen Johnson
    1:269/101

    -----------------------------------------------------------------

                         The Interrupt Stack


     9 Feb 1990
       Jack Porter's Birthday. Send greetings to him at 1:205/69.

     5 Jun 1990
       David Dodell's 33rd Birthday

     1 Aug 1990
       Start of FidoCon '90. Contact Bill Vanglahn at 1:1/90 for
       details.

     5 Oct 1990
       21st 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.

    -----------------------------------------------------------------