F I D O N E W S --       Volume 14, Number 24          16 June 1997
    +----------------------------+-----------------------------------------+
    |  The newsletter of the     |   ISSN 1198-4589 Published by:          |
    |    FidoNet community       |   "FidoNews"                            |
    |          _                 |        1-904-409-7040    [1:1/23]       |
    |         /  \               |                                         |
    |        /|oo \              |                                         |
    |       (_|  /_)             |                                         |
    |        _`@/_ \    _        |                                         |
    |       |     | \   \\       |   Editor:                               |
    |       | (*) |  \   ))      |        Christopher Baker  1:18/14       |
    |       |__U__| /  \//       |                                         |
    |        _//|| _\   /        |                                         |
    |       (_/(_|(____/         |                                         |
    |             (jm)           |     Newspapers should have no friends.  |
    |                            |                    -- JOSEPH PULITZER   |
    +----------------------------+-----------------------------------------+
    |               Submission address: FidoNews Editor 1:1/23             |
    +----------------------------------------------------------------------+
    |  MORE addresses:                                                     |
    |                                                                      |
    |    submissions=> [email protected]                                |
    +----------------------------------------------------------------------+
    |    For  information,   copyrights,   article   submissions,          |
    |    obtaining copies of FidoNews or the internet gateway FAQ          |
    |    please refer to the end of this file.                             |
    +----------------------------------------------------------------------+


                    NO NEWS IS GOOD NEWS?


                       Table of Contents
    1. EDITORIAL  ................................................  1
       How hard IS it to format a text file to 70 columns?  ......  1
    2. LETTERS TO THE EDITOR  ....................................  2
       What to do for more articles  .............................  2
    3. ARTICLES  .................................................  3
       SHARING-the FidoNet World Class, Global Communication E  ..  3
    4. GETTING TECHNICAL  ........................................  7
       FSC-0082 - Proposed New Packet Type  ......................  7
       FSC-0083 - Proposed standard for message IDs  ............. 18
    5. COORDINATORS CORNER  ...................................... 37
       Nodelist-statistics as seen from Zone-2 for day 164  ...... 37
    6. NET HUMOR  ................................................ 38
       Java the Hutt?  ........................................... 38
    7. NOTICES  .................................................. 40
       A_THEIST Echo is on the Backbone!  ........................ 40
       Future History  ........................................... 40
    8. FIDONEWS PUBLIC-KEY  ...................................... 42
       FidoNews PGP public-key listing  .......................... 42
    9. FIDONET BY INTERNET  ...................................... 43
    10. FIDONEWS INFORMATION  .................................... 45
    FIDONEWS 14-24               Page 1                   16 Jun 1997


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


    Even the most primitive word processing [EDLIN anyone?] programs can
    count the columns live and in color as one is typing an article or
    notice. Netmail and email is harder to control but text files are
    difficult to make conform to ARTSPEC.DOC? Nah.

    If anyone is being held back by the formatting constraints of the
    ARTSPECs, please be assured that I will reformat [and even spell check
    if desired] your submission for you. ARTSPEC exists to provide
    directions to make a file that an automated MAKENEWS operation will
    not choke on during a weekly run to produce FidoNews. Since I don't
    run FidoNews as an automatic function, the poorly formatted stuff
    doesn't get stuck in the dead letter file.

    A couple promised articles never arrived [and i still have the email
    link open behind me as i type this, JIC] so here's what we have for
    this week.

    BTW, what ever happened to the ASCII_ART Echo? It still isn't in the
    BACKBONE.NA list and I would have sworn it got the REC requests.

    And anybody heard any news on the resumption of ops at 1:13/10?

    My Father's Day ran a little late and so is this Issue. [grin]

    C.B.

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

    FIDONEWS 14-24               Page 2                   16 Jun 1997


    =================================================================
                          LETTERS TO THE EDITOR
    =================================================================


    From: [email protected]
    Date: 13 Jun 97 22:11:07 -0700
    Subject: Fidonews - what to do for more articles
    To: [email protected]
    Organization: Don't Mistake Lack Of Talent For Genius

    >From steve steffler, 1:342/1022

    Hi Chris, feel free to publish this in Fidonews if you wish..

    I see in the newest Fnews that you ask what could be done to make
    readers write articles for Fidonews.  I know that for me, the one
    thing that has kept me from contributing is that I don't like having
    to carefully follow ARTSPEC.DOC when writing.  If you eliminated that
    document and formatted everything yourself before feeding it into that
    MKNEWS program (or whatever it's called) then I am confident that more
    people would contribute to the publication.

    I'm also a firm believer that there is too much filler content in it -
    if a 10k Fidonews was released without all the stuff like the PGP key
    and the FSC documents, perhaps people would open their eyes and see
    that an important link between individuals in the Fidonet community is
    on the brink of extinction.  Plus, the stuff that never changes from
    issue to issue is really a deterrent to reading it, but I'll save that
    for another rant, as I'm sure you've already all heard it all before.
    ;-)   <= (Suggestion: Put the copyright notice, etc, etc, stuff that
    never changes or rarely changes, into a separate file in the Fidonews
    archive?)

    [email protected] * http://www.geocities.com/SoHo/3755 * team os/2

     -30-

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

    FIDONEWS 14-24               Page 3                   16 Jun 1997


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


    Christopher Baker
    Rights On!, 1:18/14
    Edgewater_FL_USA

    There's a new Echo in town dedicated to the REAL spirit of FidoNet
    Sysoping. It's called SHARING. Here's the blurb from the EListing:

    What Sysops will see and learn in SHARING will make it "the place to
    be." What they will see will be up to them but there will be laughter
    and wonders and mysteries of FidoNet technology will be explained.
    SHARE the wonderful experience of our hobby.  This Echo will be
    Awesome. It's the Swiss Army knife of information!  There's plenty to
    learn. Sysops can SHARE everything!  Every Sysop in the FidoNet
    phonebook [Nodelist] is invited to participate but we will have a few
    simple rules. POLITENESS to each other is EXPECTED! It is REQUIRED!
    The few off-topic topics are contained in the accompanying SHARING.RUL
    file. The Moderators reserve the right to declare off-topic any
    subject getting out of the bounds of politeness and cooperation. The
    Backbone or any backbone is off-topic automatically except as noted in
    the rules.

    mod  Christopher Baker, 1:18/14
    mod  jim barchuk, 1:141/355
    mod  Debra Milner, 1:112/285
    mod  Emeritus-Don Dawson, 1:150/730

    Backbone status has been in effect for months so Areafix a link from
    your local Backbone feed or contact any of the Moderators for a direct
    link via Netmail.

    Here's the SHARING Echo Guidelines for those without a copy of the
    current ELRUL file:

    --- Following message extracted from SHARING @ 1:18/14 ---
        By Christopher Baker on Sat Apr 20 23:38:03 1997

    From: Christopher Baker
    To: All
    Date: 15 Apr 97  00:52:32
    Subj: SHARING Echo Guidelines - regular repost

    From: [by Don Dawson]
    To: Y'all
    Date:  4 Aug 95  22:27:48
    Subj: Da Rulz

    Sorry, it's dirty work but someone has to do it.  :-)

    What is this echo?
    ------------------
    FidoNet is a World Class, Global, Communications Network of, by and
    FIDONEWS 14-24               Page 4                   16 Jun 1997


    for FidoNet Sysops around the Globe.  There are other FTN networks but
    none are of the size of FidoNet.

    What Sysops will see and learn in SHARING will make it "the place to
    be".  What might they see?  We don't have an agenda, hidden or
    otherwise, but I'm sure we'll laugh at ourselves, cry for each other
    and everyone will be "just themselves".

    The wonders and mysteries of FidoNet Technology will be explained!.
    Learn how and where files fall into dishes.  Learn how and where files
    pop out of the InterNet tunnel.  Learn how to eat the Echomail
    Elephant rather than have it eat you! Learn how to send e-mail to
    anywhere on the Globe often with a local phone call, including to AOL,
    Prodigy, C$erve, and perhaps that office down the street.  Learn
    there's no such thing as FREE!

    SHARE the wonderful experience of our hobby.  This echo is Awesome,
    it's the Swiss Army knife of information!  There's plenty to learn,
    learn, learn and it doesn't matter what hardware, operating system,
    mailer or BBS Software a sysop uses.

    Sysops can share those funny experiences we all have.  One of mine is
    a brief story about NERF.BAT.  We can laugh with each other and cry
    with each other. Yes, tragedy, sometimes simple, sometimes bizarre,
    hits us all.  Why not share it?  There's good news too: someone is a
    new parent for the first time, a new grandparent even.

    Sysops find good deals on all sorts of goods and services.  Why not
    SHARE where, how much and how good so we can all get the most out of
    our hobby budget?

    Please!
    --------
    What won't you see?  No anger.  No threats.  No intimidation. No
    inappropriate language.  And none of that politistrivial junk so
    common in other Sysop Echos.  No Zeroes. No Binary addresses allowed.
    If you're a 0 or a 1, stay away!  No a.k.a.'s allowed!  Use your real,
    primary address or stay out, especially those 0's and 1's!  Simple
    enough?

    Every Sysop in any FTN phonebook is invited to participate, invited to
    just be themselves and SHARE the FidoNet Technology Experience.
    FidoNet Technology Sysops are *very* special people, this echo is by,
    for and about them.

    Politeness to each other is EXPECTED!  It IS REQUIRED.  Almost no
    topic is "off topic" except as noted below.  The Moderators reserve
    the right to BAN any topic.  I reserve the right to "suspend
    discussion" of a topic for a time certain.  Be CERTAIN of your FACTS,
    NAME names, don't take the cowards way out by using "They said, He
    said".  Be SPECIFIC.

    There are three Moderators. They are:

    Christopher Baker;
    jim barchuk; and
    FIDONEWS 14-24               Page 5                   16 Jun 1997


    Debra Milner.

    They are the only ones who will make Moderatorial pronouncements to
    anyone else. Leave any Moderating to them. We don't expect to have to
    do much in the way of moderating in a friendly and cooperative Echo.

    Definitions:
    ------------

    Phonebook:   The Nodelist

    FidoGawd:    (or its variations) are prohibited from this Echo.

    Fight-o-Net: (or its variations) are also prohibited.

    Policy:      Policy4 as indicated in the nodelist. The ONLY policy.
                 If your zone/region/net also has a local policy, be
                 specific.  If you use Policy by itself, POLICY4 is
                 assumed.

    EchoPol:     It does not exist, never did.  Maybe never will.

    CRP:         Cost Recovery Plan/Program.  I prefer Cost Sharing but
                 you call it what you wish.

    CRaP:        Something that sometimes accompanies participation in a
                 CRP.  It is and is intended to be an unflattering term.

    Grunt Sysop: All 30,000+ PEOPLE in the FidoNet phonebook and or any
                 FTN phone book.

    backbone:    or Backbone, whichever you prefer is OFF Topic [except we
                 will share how to get an Echo on the Backbone if asked.]

    As Mr. Bartles and Mr. James are known to say: Thank you for your
                                                   support!

    Short and sweet (?)

    Moderator Emeritus, former 1:150/730

    B-)  Don

     QOFM.
     Chris

     Christopher Baker
     jim barchuk
     Debra Milner
     Moderators, SHARING

     -30-

    We invite you to join us in a friendly and cooperative Echo for
    FidoNet Sysops who don't need someone standing over them with a club
    to behave like adults and who would prefer a Sysop Echo with less tar.
    FIDONEWS 14-24               Page 6                   16 Jun 1997


    [grin]

    QOFM.
    Chris

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

    FIDONEWS 14-24               Page 7                   16 Jun 1997


    =================================================================
                            GETTING TECHNICAL
    =================================================================


    [This is part of the continuing FidoNet History series of FTSC
     Standards and Proposals. These docs have been reformatted to 70
     columns where required. Tables may be askew. Node numbers and phone
     numbers may be out of date.] Ed.

      | Document: FSC-0082
      | Version:  001
      | Date:     14 May 1995
      |
      | Stephan Slabihoud, 2:2446/[email protected]

                          A Proposed New Packet Type
                               Stephan Slabihoud
                           2:2446/[email protected]
                             90:400/[email protected]
                   [email protected]
                              1.Rev: Sep 20, 1994

         Status of this document
         =======================

         This FSC suggests a proposed protocol for the FidoNet(r)
         community, and requests discussion and suggestions for
         improvements. Distribution of this document is unlimited.

         Fido and FidoNet are registered marks of Tom Jennings and
         Fido Software.

         Purpose
         =======

         This document should introduce a widely used standardised
         extension to FTS-0001, like FTS-0006, 0007 and 0008 are, and
         provides a new way to switch to a new more confortable bundling
         method. I call this method XType-1. This is also more convenient
         than FSC-0014 (an earlier binary-style msg proposal) and allows
         multimedia extensions for further support (e.g. samples and
         pictures like World-Wide-Webb). An example how to implement MM
         extensions can be found at the end of this document. Note: This
         proposal does not suggest how to implement MM extensions, it
         should only demonstrate the flexibility of XType-1.

         Prologue
         ========

         The new bundling method (XType-1) that document is introducing is
         NOT backward compatible. So only new software packages may offer
         this bundling method.

         Why introducing a new bundle format?
         ====================================
    FIDONEWS 14-24               Page 8                   16 Jun 1997


         Well, FSC-0001, 0039, 0048 and 0045 are not very comfortable to
         handle. Software must be very complex to process a Type-2 packet
         and looking for control lines like SEEN-BYs, MSGIDs, REPLYs and
         so on slows down the importing, processing and exporting of every
         mail.

         How can I recognize a new XType-1 bundle?
         =========================================

         XType-1 bundles are using a new extension "*.PKX" and not longer
         "*.PKT". So software can recognize a reveived XType-1 packet in a
         very easy way. Older software that do not know the XType-1
         bundling method will not touch the file. But it is highly
         recommended to send the XType-1 bundles only to nodes you know
         about that they can process this new bundling method.  Filename
         naming is the same as in FTSC-0001 explained. Only the extension
         has been changed from "PKT" to "PKX".  For older software it is
         possible to convert the XType-1 format in one of the older
         formats like FSC-0001, 0039, 0048 and 0045.

         Packet Header
         =============

           Offset
          dec hex
                  .-----------------------------------------------------.
            0   0 | HeaderVersion      ($01) | I/M-Format           [1] |
                  [2] +--------------------------+------------------------
                  --+
            2   2 | ProductCode          (*) | ProductCode          (*) |
                  +--------------------------+--------------------------+
            4   4 | Revision         (major) | Revision         (minor) |
                  +--------------------------+--------------------------+
            6   6 | origZone             (*) | origZone             (*) |
                  +--------------------------+--------------------------+
            8   8 | origNet              (*) | origNet              (*) |
                  +--------------------------+--------------------------+
           10   A | origNode             (*) | origNode             (*) |
                  +--------------------------+--------------------------+
           12   C | origPoint            (*) | origPoint            (*) |
                  +--------------------------+--------------------------+
           14   E | destZone             (*) | destZone             (*) |
                  +--------------------------+--------------------------+
           16  10 | destNet              (*) | destNet              (*) |
                  +--------------------------+--------------------------+
           18  12 | destNode             (*) | destNode             (*) |
                  +--------------------------+--------------------------+
           20  14 | destPoint            (*) | destPoint            (*) |
                  +--------------------------+--------------------------+
           22  16 |                      password                       |
                  |                8 bytes, null padded                 |
                  +--------------------------+--------------------------+
           30  1E | Date/Time in POSIX 1003.1 format                (*) |
                  | (4 bytes)                                           |
                  [5] +--------------------------+------------------------
                  --+
    FIDONEWS 14-24               Page 9                   16 Jun 1997


           34  22 | CapabilWord          (*) | CapabilWord          (*) |
                  +--------------------------+--------------------------+
           36  24 |          length of origNetwork (in bytes)       (*) |
                  [3]
                  +-----------------------------------------------------+
           38  26 |  origNetwork, zero when "length of origNetwork"=0   |
    [4]
                  |           null padded to an even length             |
                  +-----------------------------------------------------+
           ~~  ~~ |          length of destNetwork (in bytes)       (*) |
                  [3]
                  +-----------------------------------------------------+
           ~~  ~~ |  destNetwork, zero when "length of destNetwork"=0   |
    [4]
                  |           null padded to an even length             |
                  +-----------------------------------------------------+
           ~~  ~~ |                    zero or more                     |
                  ~                        packed                       ~
                  |                       messages                      |
                  +--------------------------+--------------------------+
           ~~  ~~ |      0      |      0     |      0      |      0     |
                  '-----------------------------------------------------'

        (*) high-low-byte or low-high-byte according to I/M-Format-Flag
            (see [1]).

        [1] This flag defines Intel ($00) or Motorola ($01) format.
            Intel-Format stores low-byte first, Motorola-Format stores
            high-byte first.
        (2) HeaderVersion $01 means XType-1 ($02 means XType-2 and so on).
        (3) Length of network domain (max. 64k characters). Zero, when
            no network name is used, not known or your software does not
            allow a 5D address. When this field is $0000 the next field
            (the domain itself) will not be stored.
        (4) Domain names are not case sensitive.
        (5) POSIX 1003.1 format: Long integer containing the number of
            seconds since the 1st of January 1970 (00:00:00).

        Packet       = PacketHeader  { PakdMessage }  $00 $00

        PacketHeader = $01            /* $01 means XType-1 header
    */
                       I/M-Format     /* $00=Intel format, $01=Motorola
    format*/
                       productCode    /* 0 for Fido, write to FTSC for
    others */
                       revision       /* revision or 0
    */
                       origZone       /* zone of pkt sender (otherwise
    null)  */
                       origNet        /* of packet, not of messages in
    packet */
                       origNode       /* zone of pkt sender (otherwise
    null)  */
                       origPoint      /* zone of pkt sender (otherwise
    null)  */
    FIDONEWS 14-24               Page 10                  16 Jun 1997


                       destZone       /* zone of pkt receiver (otherwise
    null)*/
                       destNet        /* of packet, not of messages in
    packet */
                       destNode       /* of packet, not of messages in
    packet */
                       destPoint      /* of packet, not of messages in
    packet */
                       password       /* session pasword  (otherwise null)
    */
                       date           /* of packet creation, binary coded
    */
                       time           /* of packet creation, binary coded
    */
                       CapabilWord    /* bitvector of XType versions known
    by */
                                      /* orig. software
    */
                       origLength     /* length of orig domain
    */
                       origNetwork    /* network of pkt sender
    */
                       destLength     /* length of dest domain
    */
                       destNetwork    /* network of pkt receiver
    */



                        msb           Capability Word               lsb
         Node Supports  ------------FTSC Type Supported **)------------

                         U  S 14 13 12 11 10  9  8  7  6  5  4  3  2  1

         Type-N,XType-1  0  1  0  0  0  0  0  0  0  0  0  0  0  0  0  1

                         ^  ^
                         |  +-- "S" Indicates nodes able to process type
                         2,
                         |      type 2+ or stone age style packets
                         +----- "U" Indicates nodes able to process RFC-
                                822 bundles.
                        ** - In the example bit definitions only XType-1
                             is defined now. The rest are to be concidered
                             "reserved by FTSC".

         Generating XType-1 bundles
         ==========================

          Do we have a CW              Does CW indicate
         stored for dest?  YES ---->   higher packets  YES ---> Generate
    higher
               NO                       we support?                packet
               |                            NO
              \|/                           |
               +-----<----------------------+
    FIDONEWS 14-24               Page 11                  16 Jun 1997


               |
          Fill header with all info
               |
          Add Messages
               |
          Terminate packet
               |
          Send packet


         Receiving bundles
         =================

           Receiving a PKX? NO -------------> Old style (PKT) format
              YES
               |
           HeaderVersion = $01 NO -------------> Process XType-Other
              YES
               |
           Store CW
               |
           Process


         Packed Messages in the XType-1 bundle
         =====================================

         To conserve space and eliminate fields which would be meaningless
         if sent, messages are packed for transmission in a binary style.

         XType-1 uses two different styles, a netmail style and an
         echomail style.


                                 Packed Netmail Message
           Offset
          dec hex
                  .-----------------------------------------------------.
            0   0 |     0      |     1       | I/M-Format           [1] |
                  +--------------------------+--------------------------+
            2   2 | origZone             (*) | origZone             (*) |
                  +--------------------------+--------------------------+
            4   4 | origNet              (*) | origNet              (*) |
                  +--------------------------+--------------------------+
            6   6 | origNode             (*) | origNode             (*) |
                  +--------------------------+--------------------------+
            8   8 | origPoint            (*) | origPoint            (*) |
                  +--------------------------+--------------------------+
           10   A | destZone             (*) | destZone             (*) |
                  +--------------------------+--------------------------+
           12   C | destNet              (*) | destNet              (*) |
                  +--------------------------+--------------------------+
           14   E | destNode             (*) | destNode             (*) |
                  +--------------------------+--------------------------+
           16  10 | destPoint            (*) | destPoint            (*) |
                  +--------------------------+--------------------------+
    FIDONEWS 14-24               Page 12                  16 Jun 1997


           18  12 | Attribute            (*) | Attribute            (*) |
                  +--------------------------+--------------------------+
           20  14 | cost                 (*) | cost                 (*) |
                  +--------------------------+--------------------------+
           22  16 | Time/Date string (20 characters)                    |
                  [2]
                  +-----------------------------------------------------+
           42  2A |          length of origNetwork (in bytes)       (*) |
                  [3]
                  +-----------------------------------------------------+
           44  2C |  origNetwork, zero when "length of origNetwork"=0   |
                  |           null padded to an even length             |
                  +-----------------------------------------------------+
           ~~  ~~ |          length of destNetwork (in bytes)       (*) |
                  [3]
                  +-----------------------------------------------------+
           ~~  ~~ |  destNetwork, zero when "length of destNetwork"=0   |
                  |           null padded to an even length             |
                  +-----------------------------------------------------+
           ~~  ~~ |                  variable fields                    |
                  ~                                                     ~
                  |                                                     |
                  `-----------------------------------------------------'

                                 Packed Echomail Message
           Offset
          dec hex
                  .-----------------------------------------------------.
            0   0 |     0      |     2       | I/M-Format           [1] |
                  +--------------------------+--------------------------+
            2   2 | Attribute            (*) | Attribute            (*) |
                  +--------------------------+--------------------------+
            4   4 | cost                 (*) | cost                 (*) |
                  +--------------------------+--------------------------+
            6   6 | Time/Date string (20 characters)                    |
                  [2] +--------------------------+------------------------
                  --+
           26  1A |                  variable fields                    |
                  ~                                                     ~
                  |                                                     |
                  `-----------------------------------------------------'

        (*) high-low-byte or low-high-byte according to I/M-Format-Flag
            (see [1]).
        [1] This flag defines Intel ($00) or Motorola ($01) format.
            Intel-Format stores low-byte first, Motorola-Format stores
            high-byte first. Date/Time always stored in the format above!
        [2] Time/Date string (ascii format) Format (see FTS):
            DAY [ ] MONTH [ ] JEAR [ ][ ] HOUR [:] MINUTE [:] SECOND [0]

               DAY: [00] ... [31]
             MONTH: [Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec]
              JEAR: [00] ... [99]
              HOUR: [00] ... [23]
            MINUTE: [00] ... [59]
            SECOND: [00] ... [59]
    FIDONEWS 14-24               Page 13                  16 Jun 1997


        (3) Length of network domain (max. 64k characters). Zero, when
            no network name is used, not known or your software does not
            allow a 5D address. When this field is $0000 the next field
            (the domain itself) will not be stored.


          Due to routing, the origin and destination net and node of a
          packet are often quite different from those of the messages
          within it, nor need the origin and destination nets and nodes of
          the messages within a packet be homogenous.

          PakdMessage  = $01             /* $01 indicates packed netmail
    message*/
                         I/M-Format      /* $00=Intel, $01=Motorola-Format
    */
                         origZone        /* of message */
                         origNet         /* of message */
                         origNode        /* of message */
                         origPoint       /* of message */
                         destZone        /* of message */
                         destNet         /* of message */
                         destNode        /* of message */
                         destPoint       /* of message */
                         AttributeWord   /* as described in FTS-0001
                         */
                         cost            /* in lowest unit of originator's
                         */
                                         /* currency
    */
                         Date/Time       /* message body was last edited
    */
                         origLength      /* length of orig domain
    */
                         origNetwork     /* network of pkt sender
    */
                         destLength      /* length of dest domain
    */
                         destNetwork     /* network of pkt receiver
    */


          PakdMessage  = $02             /* $02 indicates packed echomail
    message*/
                         I/M-Format      /* $00=Intel, $01=Motorola-Format
    */
                         AttributeWord   /* as described in FTS-0001
    */
                         cost            /* in lowest unit of originator's
    */
                                         /* currency
    */
                         Date/Time       /* message body was last edited
    */


         AttributeWord   bit       meaning
    FIDONEWS 14-24               Page 14                  16 Jun 1997


                         ---       --------------------
                           0  +    Private
                           1  + s  Crash
                           2       Recd
                           3       Sent
                           4  +    FileAttached
                           5       InTransit
                           6       Orphan
                           7       KillSent
                           8       Local
                           9    s  HoldForPickup
                          10  +    unused
                          11    s  FileRequest
                          12  + s  ReturnReceiptRequest
                          13  + s  IsReturnReceipt
                          14  + s  AuditRequest
                          15    s  FileUpdateReq

                                s - need not be recognized, but it's ok
                                + - not zeroed before packeting

         Bits numbers ascend with arithmetic significance of bit position.

         What is a variable field:
         =========================

         A variable field consists of a header of four bytes length:

                  .-----------------------------------------------------.
            0     | DATA LENGTH          (*) | DATA LENGTH          (*) |
                  |               $0000 when last field                 |
                  +--------------------------+--------------------------+
            2     | FIELD-ID                                            |
                  |           "ND" (end data) when last field           |
                  +--------------------------+--------------------------+
            4     | FIELD-DATA                                          |
                  ~                                                     ~
                  | zero padded to an even length                       |
                  `-----------------------------------------------------'


         Defined FIELD-ID's:
         ===================

         FIELD-ID  -  synonym to
         --------------------------------------------------------------
               FR     "From" user
               TO     "To" user
               SJ     "Subject"
               AR     AREA               (only used in echomails)
               PD     ^PID
               TD     ^TID
               ED     ^EID
               MD     ^MSGID
               RP     ^REPLY
               RT     ^REPLYTO           (used by uucp gateways)
    FIDONEWS 14-24               Page 15                  16 Jun 1997


               RA     ^REPLYADDR         (used by uucp gateways)
               SN     ^SEEN-BY           (only used in echomails)
               VA     ^VIA               (only used in netmails)
               RN     ^REALNAME
               SP     ^SPLIT
               CS     ^CHARSET or ^CHRS
               OR     Origin             (only used in echomails)
               TL     Tearline
               ML     Mailtext follows
               ND     End of data fields
         --------------------------------------------------------------
          multimedia extensions (explanation follows):
               VO     audio data VOC format
               WA     audio data WAV format
               MI     MIDI data
               GF     bitmap data GIF
               TI     bitmap data TIFF
               JP     bitmap data JPEG
               AV     video data AVI
         --------------------------------------------------------------
          write to St.Slabihoud for more...

         All fields must have an even length. An odd field length must
         be aligned to an even one with a padded 0.

          Field  = dataLength       /* of field data (incl. 0)   */
                   fieldID          /* see table                 */
                   fieldData        /* Field data                */

         Example (NetMail):
         ==================

         From: Stephan Slabihoud on 2:2446/110.6
         To  : Guenther Paczia on 2:2446/110
         Subj: This is a testmail
         -----------------------------------------
         ^PID: AVALON 3.72
         ^MSGID: 2:2446/[email protected] a3dbcfe5
         ^MYCTRL nothing interest
         This is the message body


                  .-----------------------------------------------------.
                  | MESSAGE-HEADER                                      |
                  ~                                                     ~
                  |                                                     |
                  +--------------------------+--------------------------+
                  | PACKED NETMAIL MESSAGE HEADER                       |
                  ~                                                     ~
                  |                                                     |
                  +--------------------------+--------------------------+
                  |           18             |           0              |
                  +--------------------------+--------------------------+
                  |           'F'            |           'R'            |
                  +--------------------------+--------------------------+
                  |             'Stephan Slabihoud', $00                |
    FIDONEWS 14-24               Page 16                  16 Jun 1997


                  +--------------------------+--------------------------+
                  |           16             |           0              |
                  +--------------------------+--------------------------+
                  |           'T'            |           'O'            |
                  +--------------------------+--------------------------+
                  |             'Guenther Paczia', $00                  |
                  +--------------------------+--------------------------+
                  |           18             |           0              |
                  +--------------------------+--------------------------+
                  |           'S'            |           'J'            |
                  +--------------------------+--------------------------+
                  |             'This is a testmail'                    |
                  +--------------------------+--------------------------+
                  |           12             |           0              |
                  +--------------------------+--------------------------+
                  |           'P'            |           'D'            |
                  +--------------------------+--------------------------+
                  |             'AVALON 3.72', $00                      |
                  +--------------------------+--------------------------+
                  |           34             |           0              |
                  +--------------------------+--------------------------+
                  |           'M'            |           'D'            |
                  +--------------------------+--------------------------+
                  |             '2:2446/[email protected] a3dbcfe5\0'   |
                  +--------------------------+--------------------------+
                  |           50             |           0              |
                  +--------------------------+--------------------------+
                  |           'M'            |           'L'            |
                  +--------------------------+--------------------------+
                  | '^MYCTRL nothing interest', $0A                     |
                  | 'This is the message body', $0A                     |
                  +--------------------------+--------------------------+
                  |           0              |           0              |
                  +--------------------------+--------------------------+
                  |           'N'            |           'D'            |
                  +--------------------------+--------------------------+
                  | more messages or zero                               |
                  ~                                                     ~
                  |                                                     |
                  +--------------------------+--------------------------+
                  |      0      |      0     |      0      |      0     |
                  '-----------------------------------------------------'

         Unknown control lines are stores as usual in the message body. So
         it is possible to receive a XType-1 packet and convert it into an
         old style Type-2+ packet to send to it to another systems that do
         not recognize the new Xtype-n bundles.

         Messages can be longer than 65535 bytes. Just use the 'ML' fields
         more than once. When importing such a mail the importer can
         easily split the mail into smaller parts. All 'ML' fields can be
         added to one big mail, or each 'ML' text can be stored in its own
         message.  According to older software each 'ML' field should not
         be longer than 8 kbyte (but it is allowed to use longer fields!).

         All fields are unsigned integer.
    FIDONEWS 14-24               Page 17                  16 Jun 1997


         Example: How to implement MultiMedia extensions (draft version):
         ================================================================

         Graphics and sounds are coded in one of the following fields:
            Audio: VO,WA,MI
            Bitmap: GF,TI,JP
            Video: AV

         Each field-data starts with a multimedia header:

                   .------------------------.
            0   0  | Name (Title)           |
                   | 16 chars (zero padded) |
                   +------------------------+
           16  10  | ID                     |
                   | 32bit Random Number    |
                   +------------------------+
           20  14  | Flags                  |
                   | 16bit bitfield         |
                   +------------------------+
           22  16  | 42 reserved bytes      |
                   |                        |
                   +------------------------+
           64  40  | start of data          |
                   ~                        ~
                   |                        |
                   '------------------------'

           Flags:
            Bit 0/1  - 1 = align left
                       2 = align right
                       3 = center
                       0 = reserved
            Bit 2-15 - reserved


         There are some possibilties for a mail editor to show/play the
         multimedia extensions:

          1. It shows the mail in the first window and a list of all
             available fields in an extra (selection) window. The user
             selects the picture/sound from the selection window.

          2. Pictures will be put together with the mailtext in ONE window
             (a button will be shown when it is an audio field).  To
             define the place where a picture (or other multimedia
             extension) is shown put following ^A-control line into the
             mailbody:     ^MMEDIA: <field> <id> [<infotext>]
               <field> is the "variable field" shortcut.
               <id> is the 32bit ID in hex from the multimedia header.
               <infotext> can be used as infotext for buttons.

         Example of ML field (mailbody):
         ------------------------------------------------------------
           Welcome to\n
           ^MMEDIA: GF 5417fde6\n\n
    FIDONEWS 14-24               Page 18                  16 Jun 1997


           Please select:\n\n
           To hear my voice click on the button:\n
           ^MMEDIA: VO 2f4dca67 Say it\n
           I am watching you ;-):\n
           ^MMEDIA: GF 5627320f Click here\n
         ------------------------------------------------------------

         This mail could be shown as follows:
         ------------------------------------------------------------
           Welcome to:
           +------------------------------+
           | GIF-Picture                  |
           +------------------------------+

           Please select:

           To hear my voice:
           +--------+
           | Say it |
           +--------+
           I am watching you ;-):
           +-------------+
           |             |
           | GIF-Picture |
           |             |
           +-------------+
         ------------------------------------------------------------
         Note: All pictures can be shown as button as well. This should
               be switchable in the mail editor.

         Credits
         =======

         Thanx to Jonathan de Boyne Pollard, Peter Dreuw, Daniel Roesen
         and Rowan Crowe for their good ideas.

         Epilog
         ======

         That's all, now it's up to you to decide whether or not to
         implement it.

     -30-


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


      | Document: FSC-0083
      | Version:  001
      | Date:     17 June 1995
      |
      | Jonathan de Boyne Pollard, FIDONET#2:440/4.0

                A proposed standard for message IDs on FTN systems.

    FIDONEWS 14-24               Page 19                  16 Jun 1997


                                       by

                   Jonathan de Boyne Pollard, FIDONET#2:440/4.0

                            Version 0.02, Sun 19950507

            This document is (c) Copyright 1995 Jonathan de Boyne Pollard,
            all rights reserved.  Originally written on Tuesday 19950131.

            Permission is hereby granted to copy and use this document
            without modification in any way that you see fit, provided
            that you do not attempt to make money from it, and that you
            understand that I take no responsibility whatsoever for any
            effect that it may have on your machine, data, marital status,
            or cat.

            Especial permission to freely use and redistribute this
            document in its original form is given to developers of FTN
            softwares and whatever FIDONET Technical Standards bodies may
            exist from time to time.

            -----------------------
     0.0 Definition of terms
            -----------------------

            This document assumes familiarity with several terms in common
            use in discussion of mail systems, such as `User Agent',
            `Message Transport Agent', and so forth.

            Robot mail programs qualify as UAs, incidentally.

            0.1 Knackered Backward Form
            ---------------------------

            This specification uses a modified BNF notation for discussion
            of textual representation of message IDs.

            Literal syntax elements (terminal nodes of the grammar) are
            enclosed in single quotes.

                    'MSGID:'        '@'    '<'        '"'

            Non-terminal nodes are enclosed in angle brackets (greater
            than and less then signs).

                    <quoted-text>           <hex-text>              <q-p-
    site-identifier>

            Production rules comprise a non-terminal, followed by
            productions.  Alternate productions for the same non-terminal
            are separated by a vertical bar.

                    <qtext-chars> ::=
                                      '"' '"'
                                    | <any-character-except-quotes-NUL-or-
    CR>
    FIDONEWS 14-24               Page 20                  16 Jun 1997


            Optional sequences within a production are indicated in two
            ways.  Square brackets enclose a sequence that may occur
            exactly once or not at all.

                    [ '@' <dns-name> ':' ]

            Curly braces enclose a sequence that may be repeated any
            number of times.  A leading numeric prefix (usually 0 or 1)
            indicates the minimum number of repetitions.

                    1*{ <hex-character> }

            0.1.1 Some standard production rules
            ------------------------------------

                    <whitespace-char> ::= <tab> | <space>

                    <whitespace> ::= 1*{ <whitespace-char> }

                    <hex-character> ::=
                            '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9'|
                            'A'|'B'|'C'|'D'|'E'|'F'|
                            'a'|'b'|'c'|'d'|'e'|'f'

                    <upper-hex-char> ::=

    '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9'|'A'|'B'|'C'|'D'|'E'|'F'

                    <qtext-char> ::=
                                    '"' '"'
                              | <any-ASCII-character-except-quotes-NUL-or-
    CR>

                    <quoted-text> ::= '"' 0*{ <qtext-char> } '"'

                    <quoted-char> ::=
                                    <any-ASCII-character-except-quotes-
    backslash-NUL-or-CR>
                              | '\' <any-ASCII-character-execpt-NUL-or-CR>

                    <quoted-string> ::= '"' 0*{ <quoted-char> } '"'

                    <word> ::= 1*{ <any-ASCII-character-above-SPACE-and-
    below-DEL> }

            Note the difference between the two forms of quoting.
            <quoted-text> is a string with embedded quotation marks
            represented by double quotation marks (the way that most BASIC
            languages do).  However, <quoted-string> is a string with all
            quotation marks and backslashes (and, indeed, any other
            character) escaped by the backslash character, in the style of
            the C and C++ languages.

            -------------------------------------
    1.0 Definition and use of message IDs
            -------------------------------------
    FIDONEWS 14-24               Page 21                  16 Jun 1997


            For the purposes of this document, the network is considered
            to form a vast distributed database of messages, which uses
            replication and store and forward distribution to ensure that
            all carriers of the database are kept up to date.  Every
            message, whether netmail or echomail, carries a primary
            message ID that uniquely identifies it, and zero or more
            reference message IDs that uniquely identify any messages that
            it refers to.

            A primary message ID is a globally unique key that is used for
            uniquely identifying any single given mail message in the
            database (that is, counting all replicas of a message over all
            of the network as "one").  The reference message IDs are used
            by user agents to form a reply graph, allowing the the user to
            easily navigate the messagebase.

            Message transport protocols may require the data in a message
            ID to be encoded so that it may be safely transported.  This
            standard distinguishes between the "underlying" message IDs
            and the encoded forms.  This chapter discusses the underlying
            message IDs and the concepts behind them without reference to
            a particular encoding, and subsequent chapters discuss the
            various encoded forms.

            1.1 Components of a message ID
            ------------------------------

            A message ID comprises two parts, namely a site identifier and
            a local part.  Both of these parts are arbitrary 8-bit binary
            data, that implementations are free to store in any way they
            choose, but which they should never alter.  There are no
            distinguished characters in either the site identifier or
            local part, especially not terminating characters.  So
            implementations must usually store an additional length count
            for both.

            The "minimum maximum" lengths for the site ID and local part
            are 64 octets each, and conforming implementations may not
            impose shorter maximum length restrictions.  In fact,
            implementations are encouraged to impose no length
            restrictions on message IDs whatsoever (for example, it is not
            unreasonable to expect site IDs to exceed 256 octets on
            occasion).

            1.2 Preservation of uniqueness
            ------------------------------

            A site that creates messages (by entering them into the
            distributed database) must also issue message IDs, and must
            ensure that the global uniqueness property of message IDs is
            preserved.

            A site MUST ensure that it issues unique local parts to
            individual messages.  Two or more sites may not have the same
            site identifier, unless they *all* co-operate to ensure that
            they do not issue duplicate local parts.
    FIDONEWS 14-24               Page 22                  16 Jun 1997


            The administrative procedures necessary to obtain a unique
            site identifier are beyond the scope of this document.
            Usually site identifiers will be FTN 5D addresses, or fully
            qualified DNS names, because administrative procedures for
            assigning such are already in place.  However, they are not
            restricted to be such.

            The means by which a site invents new local parts is beyond
            the scope of this document.  A discussion of some example
            options for implementors to consider is given in an appendix.

            1.3 Reference message IDs
            -------------------------

            Reference message IDs in a message denote messages to which it
            is related, comprising a "local subset" of the overall reply
            graph (i.e. the direct and indirect ancestors of the message),
            which each message carries around with it.

            Carrying around multiple reference message IDs provides
            overlap, allowing for the overall reply graph to be
            reconstructed even in the absence of intermediate messages (if
            they had expired, or had not yet arrived due to propagation
            lag, for example).

            UAs that conform to this standard MUST ensure that only
            messages that start new threads (i.e. messages entered into
            the network not in response to any existing message) have no
            reference message IDs.

            All other messages that they create MUST contain at least one
            reference message ID, being that of the message that is being
            responded to.

            [[ Luckily, schemes already in existence mean that in practice
               non-conforming User Agents will generally preserve this
               single back link, as well.  ]]

            When responding to a message, user agents must create the
            reference message ID list of the response by taking the list
            of reference message IDs from the original message, and
            appending the primary message ID of the original message to
            the tail.

            A reference message ID list should not be truncated, unless
            transport or storage limitations are in danger of being
            exceeded.  In which case, message IDs may only be removed from
            the head of the list.  Removing from the tail would eliminate
            links to immediate ancestor messages, and removing from the
            middle would alter the reply graph.


    ----------------------------------------------------------------------
    --
    2.0 Quoted printable encoding for storing 8-bit data in 7-bit
            transports
    FIDONEWS 14-24               Page 23                  16 Jun 1997


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

            To encode the 8-bit data in message IDs for transport by 7-bit
            transport layers, we use a variation on the widely used Quoted
            Printable form [RFC1521] [RFC1522].

            2.1 Grammar of Quoted Printable encoding
            ----------------------------------------

            The grammar of the 7-bit encoding of 8-bit data in a quoted
            printable word is as follows.

                    <q-p-word> ::=
                                    <word>
                              | <quoted-text>
                              | [ '=' ] 1*{ <q-p-character> } [ '=' ]

                    <q-p-character} ::=
                                    <any-ASCII-character-bar-ctls-wspace-
    quote-and-equals>
                              | <q-p-quoted-char>

                    <q-p-quoted-char> ::= '=' <upper-hex-char> <upper-hex-
    char>

            2.2 Conversion from 8-bit to 7-bit
            ----------------------------------

            Rule #1 (non-quoted transparent 7-bit): Where the 8-bit data
            consist of nothing but ASCII characters above SPACE and below
            DEL, they may be copied literally to the 7-bit representation.

            Rule #2 (quoted transparent 7-bit):  Where the 8-bit data
            consist of nothing but ASCII characters except CR and NUL,
            they may be converted to the 7-bit representation by enclosing
            them in quotes, and escaping every embedded quotation mark
            with a second quotation mark.

            Rule #3 (8-bit quoted): Where the 8-bit data contain CR or
            NUL, or any non-ASCII characters, they are converted to a 7-
            bit representation in two stages.

                    Firstly, all non-ASCII characters, all ASCII control
            characters, SPACE, DEL, '"', and '=', are converted to
            "quoted" form.  Quoted form is an '=' character followed by
            the hexadecimal value of the character represented as two
            uppercase hexadecimal digits.

                    Secondly, the entire string is then enclosed by one
            leading and one trailing '=' character.

            2.3 Conversion from 7-bit to 8-bit
            ----------------------------------

            Where the 7-bit field is delimited by equals signs, it is a
    FIDONEWS 14-24               Page 24                  16 Jun 1997


            fair bet that it comprises 8-bit data to which Rule 3 has been
            applied.  However, it is possible that sites in the 7-bit
            world may produce data with leading and trailing equals signs.

            Reverse of Rule #3 : If, after stripping the leading and
            trailing '=', the remaining text can be converted back using
            the reverse of Rule 3, then that 8-bit data is the actual
            message ID.  Otherwise the reverse of Rule 2 should be applied
            to the original 7-bit data.

            Reverse of Rule #2 : If the 7-bit data are enclosed by quotes
            the reverse of Rule 2 should be applied to remove the
            enclosing quotes and any embedded quotes (8-bit form does not
            have delimiter characters and so does not require quoting).
            Otherwise the reverse of Rule 1 should be applied.

            Reverse of Rule #1 : The 7-bit data are copied to the 8-bit
            data.

            2.4 Rationale
            -------------

            The intention is that <q-p-word> tokens will not be parsed as
            separate words by most 7-bit grammars.  The elimination of
            quotes, whitespace, and control characters by Rule 3 is part
            of achieving this.

            Rules 1 and 2 allow message IDs created by 7-bit standards to
            enter and travel within the 8-bit world, and be restored to
            their original form when they return to the 7-bit world.
            Returning 7-bit message IDs to their original form means that
            7-bit duplicate checking is not broken by 8-bit gateways.

            The unfortunate side-effect is that any 8-bit data generated
            in the 7-bit world will be returned to the 7-bit world as 7-
            bit data in Q-P encoded form.  However, the original 8-bit
            data are unlikely to work in the 7-bit world in the first
            place, so this is no great loss.

            Rule 3 is the most general rule of the three.  Rule 3 applies
            to true 8-bit message IDs generated in the 8-bit world that
            use 8-bit characters, allowing them to travel across the 7-bit
            world with a reasonable chance of remaining intact.

            The elimination of the equals sign by Rule 3, replacing it
            with its Q-P encoding, ensures that the decoding process can
            assume that an equals sign not followed by two uppercase hex
            characters is not a valid Rule 3 encoding, and so fall back to
            decoding Rule 2.

    ---------------------------------------------------------------------
    3.0 Storage of message IDs in type 2.0, 2.0+, and 2.2 message packets
            --------------------------------------------------------------
            -------

            Type 2.0 message packets [FTS0001], type 2.0+ message packets
    FIDONEWS 14-24               Page 25                  16 Jun 1997


            [FSC0039], and type 2.2 message packets [FSC0045] are used for
            message transport over much of FIDONET.  They do not have
            space in their message headers available for message IDs
            (along with a lot of other things), therefore message IDs must
            be transferred to the body of the message for transport in
            these forms, and retrieved from the body of the message
            afterwards.

            The existing "kludge line" mechanisms [FSC0068] are used to do
            this.

            There are two concerns here.

            Firstly, it is preferable that as much of the reply graph as
            possible is preserved, even in the face of tools that use
            existing MSGID/REPLY schemes [FTS0009].

            Secondly, message IDs are 8 bit data, and must be encoded into
            a 7-bit form that will be reliably transported in the bodies
            of type 2.0, 2.0+, and 2.2 message packets.

            3.1 Conversion to and from kludge lines
            ---------------------------------------

            The primary message ID of a message is stored to and retrieved
            from a "MSGID:" kludge line.

            All of the reference message IDs of a message are stored, in
            order from first to last, in a single "REFER:" kludge line.
            The last reference message ID of a message (its immediate
            ancestor, in other words) is stored in a "REPLY:" kludge line.
            Note that the information in the "REFER:" kludge line is a
            superset of the information in the "REPLY:" kludge line.

            If a message has zero reference message IDs (it is the start
            of a new thread), then the "REFER:" and "REPLY:" kludge lines
            are omitted.

            If, upon decoding from type 2.0, 2.0+, or 2.2 message
            transport format, a "REFER:" kludge line exists, then its
            contents are assumed to be the complete list of reference
            message IDs (in encoded form) for the message, and the
            "REPLY:" kludge line is ignored.  Otherwise, the content of
            the "REPLY:" kludge line (if any) is used for the single
            reference message ID of the message.

            3.2 Compatibility with existing MSGID/REPLY schemes
            ---------------------------------------------------

            There are two compatibility considerations.  It is important
            that encoded message IDs be correctly parsed by
            implementations using older less versatile standards.  It is
            also important that implementations expecting older
            MSGID/REPLY pairs will destroy as little linking information
            as possible.

    FIDONEWS 14-24               Page 26                  16 Jun 1997


            3.2.1 Grammar considerations
            ----------------------------

            There are two valid interpretations of FTS-0009, both of which
            (should) use the following grammar :

                    <msgid> ::= <soh> 'MSGID: ' <address-text>
    <whitespace> <hex-text>
                    <reply> ::=     <soh> 'REPLY: ' <address-text>
    <whitespace> <hex-text>

                    <soh> ::= ASCII SOH character
                    <address-text> ::= <quoted-text> | <word>
                    <hex-text> ::= 1*{ <hex-character> }

            The "VFIDO" interpretation assumes that MSGID/REPLY kludges
            are the textual representation of an (address, number) ordered
            pair.  Systems using this interpretation may change the case
            of <hex-text> or may renormalise <quoted-text> if they find it
            to be a FTN 5D address.

            Message IDs from this standard that are stored in MSGID/REPLY
            kludges will be mangled by software applying the VFIDO
            interpretation of FTS-0009.  Such software is not compatible
            with this standard.

            The "Mark Kimes" interpretation assumes that MSGID/REPLY
            kludges are text separated by whitespace, and preserves the
            contents of <quoted-text> and <hex-text> without change.

            The encoding scheme outlined in section 2.2 produces two
            whitespace separated text fields.  So software applying the
            "Mark Kimes" interpretation of FTS-0009 will not mangle the
            encoded message IDs.

            In many cases, softwares using the "Mark Kimes" interpretation
            will in fact parse <hex-text> as

                    <hex-text> ::= <word>

            As long as software applying the "Mark Kimes" interpretation
            of FTS-0009 is not written to truncate either field, or
            complain about a non-numeric <hex-text> portion, it is
            compatible with this standard.

            3.2.2 Reply linking
            -------------------

            FTS-0009 implementations will generate MSGID kludges, transfer
            the content (Mark Kimes interpretation) of the MSGID kludge
            data of an original message into the REPLY data of a response
            message, and will not generate a REFER kludge.

            So reply linking will be preserved, but reference information
            beyond the immediate ancestor of a message will be lost.

    FIDONEWS 14-24               Page 27                  16 Jun 1997


            3.3 Quoted printable encoding
            -----------------------------

            The 8-bit data in message IDs is encoded into 7-bit
            MSGID/REPLY data for transport in type 2.0, 2.0+, and 2.2
            message packets by using the quoted printable encoding
            outlined in chapter 2, along with the following grammar.

                    <msgid> ::= <soh> 'MSGID: ' <7-bit-encoding>
                    <reply> ::= <soh> 'REPLY: ' <7-bit-encoding>
                    <refer> ::= <soh> 'REFER: '
                                                    <7-bit-encoding> 0*{
    <whitespace> <7-bit-encoding> }

                    <7-bit-encoding> ::= <q-p-site-ID> <whitespace> <q-p-
    local-part>

                    <q-p-site-ID> ::= <q-p-word>
                    <q-p-local-part> ::= <q-p-word>

            Applying Rule 1 of Q-P encoding to local parts is safe as long
            as <hex-text> (from the FTS-0009 grammar) is in actuality
            treated as <word> by most implementations, as outlined in the
            compatibility notes.

            Rule 2 should not be applied to local parts, because the
            grammar of FTS-0009 does not allow for quoted text in the
            <hex-text> portion.

            The restrictions in Rule 3 have deliberate effect here.  FTS-
            0009 sites will rarely produce data with leading and trailing
            equals signs, so reversing Rule 3 will be unlikely to be
            subject to spurious data.  In theory, relaxing Rule 3 reversal
            to include decoding lowercase hexadecimal as well as uppercase
            hexadecimal would mean that sites that convert the case of
            MSGID/REPLY (as part of the "VFIDO" interpretation) would not
            break Q-P encoding.

            However, the "VFIDO" interpretation will usually do far more
            damage than simple case conversion, which will be impossible
            to restore.  Rather than attempt the reverse conversion (which
            could have the undesirable effect of causing different
            messages to end up with the same 8-bit message ID if the local
            part were truncated to eight characters in the 7-bit world),
            any "VFIDO" mangling that occurs will prevent Q-P decoding
            from succeeding.

            This means that 8-bit message IDs that look like incomplete or
            damaged Q-P encodings are not gateway problems, but are more
            likely to be the result of a site using the "VFIDO"
            interpretation in the 7-bit world.

            ------------------------------------------------------
     4.0 Storage of message IDs in type 2.3 message packets
            ------------------------------------------------------

    FIDONEWS 14-24               Page 28                  16 Jun 1997


            The storage format of type 2.3 messages (so-called "extensible
            type 2" [TYPE2EXT]) provides space in the message headers for
            both a primary message ID and an arbitrary list of reference
            message IDs.

            All message IDs are stored as 8-bit binary strings, using
            length counts rather than delimiters.  Therefore message IDs
            can be stored directly in type 2.3 messages.

            ------------------------------------------------------
     5.0 Storage of message IDs in type 3.x message packets
            ------------------------------------------------------

            There is such a wide variety of type 3 message formats that
            this standard doesn't hope to cover them all.

            For those with binary "chunks", chunk types 'PMID' (primary
            message ID) and 'RFER' (reference message IDs) are expected to
            have the following form :

             |-----------------------------------------------------|
             | Length of site identifier
             WORD32 |
             |-----------------------------------------------------|
             | Site identifider
             ...   |
             |-----------------------------------------------------|
             | Length of local part
             WORD32 |
             |-----------------------------------------------------|
             | Local part
             ...   |
             |-----------------------------------------------------|

            Those schemes that use text format headers and require field
            delimiters may care to use the Q-P encoding outlined in
            chapter 2.

            ---------------------------------------------------------
     6.0 Storage of message IDs in RFC822 and RFC1036 messages
            ---------------------------------------------------------

            The grammar of "Internet" messages is defined by the standards
            for ARPA text messages [RFC0822] and for Usenet news messages
            [RFC1036].

            6.1 Restrictions on interconversion
            -----------------------------------

            Interconversion between a FIDO message ID and an RFC822
            Message-ID is restricted by several factors.  The major factor
            is that RFC0822 actually places greater restrictions upon
            Message-IDs than this standard does upon FIDO message IDs (in
            part because this standard is designed to also be able to
            handle X.400 message identifiers and others transparently as
            well).  It mandates that the <address> portion of a Message-ID
    FIDONEWS 14-24               Page 29                  16 Jun 1997


            be a valid DNS name.

            A secondary factor is reversibility, in that many gateways
            exist between FTN and RFC822, and so message IDs that cross
            the boundary more than once will retain as much of their
            original ID information as possible.  There is more
            information contained within a FIDO message ID than in an
            RFC822 Message-ID.  In particular, the <address> portions of
            RFC822 Message-IDs are not case sensitive, whereas the site ID
            of a FIDO message ID is treated as 8-bit data for the purposes
            of comparison.

            These are handled by restricting the allowable conversions
            that a conformant gateway may use on a message ID, by ensuring
            that all of the FIDO information is not lost when converted to
            the (narrower bandwidth) RFC822 Message-ID format, and by
            allowing gateway softwares to infer a meaning from the site
            identifier portion of a message ID.

            This is the *only* part of this standard where it is allowed
            for softwares to place a meaning on the site identifier of a
            message ID.

            6.1 Converting to RFC822 form
            -----------------------------

            6.1.1 Site identifier recognition
            ---------------------------------

            Gateway softwares are allowed to examine a site identifier of
            a message ID and determine whether it is in a format that they
            recognise or not.  This standard specifies what gateway
            softwares should do when they encounter a site identifier that
            is a recognisable DNS name or one that is recognisable FIDO 5D
            address, and what form the DNS name for RFC822 must take.

            Site identifiers that are not FIDO 5D addresses are really
            beyond the scope of FIDONET documentation.  If an
            implementation recognises another form of site identifier
            (such as X.400 O/R addresses) then it is free to translate
            that site identifier to and from DNS form, as long as it knows
            how (there are RFCs on how to perform X.400 conversion).

            This message ID standard imposes no restrictions on site
            identifiers, allowing any scheme to be administered on
            FIDONET.  It is therefore up to the site identification
            schemes themselves to provide their own mappings to and from
            DNS names.

            Gateways are free to drop messages with message IDs that they
            do not understand how to convert.  Both the FIDONET and RFC
            worlds depend heavily upon message IDs for detecting messages
            duplicates, and so it is better that a gateway should NOT
            distribute messages with message ID formats that it doesn't
            understand how to convert to RFC822 form, rather than that it
            does so incorrectly.
    FIDONEWS 14-24               Page 30                  16 Jun 1997


            6.1.1.1 Site identifiers that are DNS names
            -------------------------------------------

            If the site identifier of a message ID can be parsed as a
            legal DNS name according to the grammar of RFC822 then, even
            if it cannot be resolved to an IP address or MX record, it
            must be used as the domain name of the RFC message ID, and the
            local part must be passed through unchanged.

            This allows for RFC message IDs to enter and leave 8-bit
            FIDONET without change, even via gateways that have no
            knowledge of or connectivity to the originating RFC host.

            6.1.1.2 Site identifiers that are FIDO 5D addresses
            ---------------------------------------------------

            The conversion process for message IDs where the site
            identifier can be parsed as a FIDO 5D address in the forms
            DOMAIN#Z:N/N.P or Z:N/N.P@DOMAIN depends from the "domain" (in
            the FIDO sense of the word) of the address.

            6.1.1.2.1 Site identifiers that are 5D addresses in FIDONET
            -----------------------------------------------------------

            If the site identifier of a message ID is parseable as a FIDO
            5D address of the form Z:N/N.P@FIDONET or FIDONET#Z:N/N.P
            (i.e.  in the FIDONET domain itself), then the DNS name used
            for the RFC message ID must be the DNS equivalent of that
            address.

            This is because MX records exist in the DNS for all of the
            zone:net pairs for 5D addresses in the FIDONET "domain", in
            the form

                    p#.f#.n#.z#.fidonet.org

            where # is a number without leading zeroes giving the
            appropriate portion of the 5D address.  Therefore this is the
            conversion that must be used.

            6.1.1.2.2 Site identifiers that are 5D addresses outside of
            FIDONET
            --------------------------------------------------------------
            -----

            Most other "domains" (in the FIDO sense of the word), are free
            to choose their own DNS domain name, but have not yet done so.

            Therefore, constructs such as p3.f0.n444.z81.os2net.ftn (which
            several people have INCORRECTLY inferred from other FTS
            documentation) are NOT ALLOWED as the DNS name in an RFC
            Message-ID.  .ftn is NOT a valid top-level DNS domain, for a
            start, and there is no guarantee that OS2NET would adopt that
            DNS name, either.

            (p#.f#.n#.z#.os2net.fidonet.org anyone ?)
    FIDONEWS 14-24               Page 31                  16 Jun 1997


            6.1.1.2.3 Conversion of local parts
            -----------------------------------

            Where a gateway has recognised a site identifier to represent
            a FIDO 5D address that it knows the DNS name for, the local
            part must then be encoded.

            According to the grammar in RFC822, any ASCII character (from
            NUL to DEL) is legal in the local part of an RFC822 Message-
            ID, because <quoted-pair> (q.v.) allows any special characters
            to be escaped.

            Since RFC822 transport is merely 7-bit just like type 2.0,
            2.0, and 2.2 message packets are, we use the quoted-printable
            scheme given in chapter 2.

            However,

            6.1.1.3 Site identifiers that are not recognisable 5D
            addresses
            --------------------------------------------------------------
            -

            No implementation may extend the FIDO 5D address to DNS name
            conversions for site IDs that are given above.  If the message
            ID is "almost, but not quite" a FIDO 5D address, then the
            message should for preference be discarded at the gateway
            rather than being passed through.

            Message IDs with abitrary site identifiers are perfectly
            acceptable to this standard, since it ascribes no meaning to
            site identifiers within FIDONET.  However, RFC822 and the
            existing RFC domain name system can only handle a restricted
            subset of the whole range of FIDO 5D addresses.

            6.1.1.4 Other site identifiers
            ------------------------------

            As mentioned before, gateways are allowed to support other
            site identification schemes that are not FIDO 5D addresses,
            and convert site identifiers in those forms to DNS names as
            they please.

            It should be borne in mind when designing such conversion
            schemes that the domain part of an RFC 822 message ID can only
            contain ASCII characters that are not control characters,
            whitespace, or special delimiter characters, because of the
            definition of <atom> in that standard (q.v.).  The quoted
            printable encoding outlined in chapter 2 of this document is
            probably not sufficient for handling full 8-bit site
            identifier schemes, in which case the scheme in RFC1522 should
            be investigated.

            6.1.2 Preserving information
            ----------------------------

    FIDONEWS 14-24               Page 32                  16 Jun 1997


            Although this standard recognises two forms for a FIDO 5D
            address, there is only one valid form for that address in the
            DNS.  For reverse conversions to succeed, when an RFC message
            re-enters 8-bit FIDONET (possibly via another gateway), the
            *exact form* of the original site identifier must be
            reconstructed, otherwise FIDO softwares will treat the two
            message IDs as different.

            Although other schemes exist, which encode the 5D address in
            the local part, and use a "generic" domain name of
            "fidonet.org" (which is not a valid host name), it is
            preferred that the semantics of a message ID ("WXYZ local part
            generated at ABCDE site") be preserved, especially as FIDONET
            sites are visible to the RFC world via the DNS anyway.

            It is therefore suggested that the original FIDONET site
            identifier (since it will be 7-bit text) be encoded as a
            <comment> token immediately following the relevant message ID,
            using quoting to escape any embedded punctuation (q.v. the
            grammar in RFC 822).

            6.2 Converting from RFC822 form
            -------------------------------

            When converting from RFC822 form back to 8-bit FIDONET message
            IDs, gateways should determine whether the address portion of
            the Message-ID is a hostname under the fidonet.org domain.

            If it is, a comment token should be scanned for to find the
            original form of the 5D address, and the site identifier
            should be reconstructed from it if found, or from the given
            DNS name in the form DOMAIN#Z:N/N.P if no comment token were
            present.  The inverse of the quoted printable encoding
            outlined in chapter 2 should then be applied to the local
            part.

            Otherwise, the 7-bit RFC822 Message-ID should be stored in the
            8-bit FIDONET message ID without change.

            6.3 Reply linking
            -----------------

            According to RFC1036, message IDs occur in the Message-ID:
            and in the References:  header for news (echomail).  Although
            RFC822 specifies an In-Reply-To:  header for mail (netmail),
            it makes it difficult to use, because it need not contain a
            message ID.

            The model for message identification used by RFC1036 closely
            matches the model outlined in this standard (it is probable
            that there is only one way to skin this particular cat).
            There is thus a direct mapping between the primary message ID
            defined by this standard and the RFC1036 Message-ID:  header,
            and also between the reference message IDs defined by this
            standard and the RFC1036 References: header.

    FIDONEWS 14-24               Page 33                  16 Jun 1997


            This means that in normal use the reference message ID list
            will be properly maintained by Usenet softwares.

            -----------------------------------------------
     A.0 Discussion on generating unique local parts
            -----------------------------------------------

            How any given site generates unique local parts is up to it.
            So this appendix should only be taken as a guideline.

            On sites where there is only one piece of software assigning
            message IDs (e.g.  there is only one UA, or the MTA itself
            assigns message IDs), then a simple "take a ticket" scheme
            could work.  Multiple instances of that piece of software
            running simultaneously would need to arbitrate access to that
            "ticket dispenser" amongst themselves.

            A discussion of `sequencers' (which is the proper name for
            this idea) and how atomic operations on them can be
            implemented, can be found in any good computer science
            textbook on concurrent systems.

            Unfortunately, in today's heterogeneous world, it is difficult
            to the point of impossibility to get every piece of software
            to agree to use one single central sequencer.

            It is obvious that using just the date/time for a message ID
            is insufficient on multitasking systems, or even on single
            tasking systems that can generate multiple messages per clock
            tick.

            What is less obvious is that it is not a good idea to use the
            name of the software generating the message ID and a sequencer
            maintained by that software as the unique local part.  The
            problem here is that it is not guaranteed that different
            softwares will use different names (especially if they are
            called "Message Editor" (-:), so it is possible that different
            softwares could generate duplicate local parts.

            Some form of "product ID code" would of course rectify this,
            but given the amount of software in use and under development
            these days, a centrally administered product ID database
            hasn't been a viable option for decades now.

            There are, of course, simpler schemes, that can guarantee to
            produce unique local parts, because they rely on features that
            are guaranteed unique to every individual application running,
            and do not rely on different applications co-operating to use
            the same central facilities, such as a site-wide sequencer.

            One commonly used scheme is to use a combination of the
            current date and time and the process and thread IDs of the
            software creating the message ID.

            e.g.  1995Jan31.123426.26.1
              or  1995013112343600260001
    FIDONEWS 14-24               Page 34                  16 Jun 1997


            This doesn't have to be human-readable calendar time, of
            course.  It could equally well be the POSIX 1003.1 time
            (seconds since The Epoch), or the Julian date plus the time of
            day.

            If the time isn't granular enough, a sequence number (which
            can be maintained individually by each process) can be added
            to increase its granularity.

            On just about every operating system in the world, including
            multi-user ones, the <time,process,thread,seq> 4-tuple will be
            unique on one machine *forever* (or until the clock wraps
            around, at least).

            e.g.  1995Jan31.123426.26.1.2
              or  19950131123436002600010003

            On multiple machine sites, where all machines share the one
            site identifier, the above scheme can be extended to include
            the "hidden" local machine name, which will be assumed to be
            made available (in some fashion) to the softwares generating
            the message IDs.

            This yields a unique <machine,time,process,thread,seq> 5-
            tuple.

            e.g.  utopium.1995Jan31.123848.26.1.4
              or  utopium.19950131123907002600010005

            Again, the "intra-site" machine name can be anything, from the
            local uname() (for UNIX people) to the NETBIOS machine name
            (for PC based LAN systems).

       -------------------------
     Bibliography and Author
       -------------------------

            [FTS0001] A Basic FIDONET Technical Standard, version 15.
            Randy Bush, Pacific Systems Group.  FIDONET#1:105/6.0.
            30th August 1990.

                              ( Defines the type 2.0 packet message
    transport format.  )

            [FTS0009] A standard for message identifiers and reply chain
            linkage, version 1. Jim Nutt.  FIDONET#1:114/30.0.  17th
            December 1991.

                              ( Defines the MSGID/REPLY kludges.  )

            [FSC0034] Gateways to and from FIDONET.  Technical,
            administrative, and policy considerations.  Randy Bush,
            Pacific Systems Group.  FIDONET 1:105/6.0.  30th August 1990.

                              ( Discussion on features that should
    be preserved across gateways, and on good gateway behaviour in
    FIDONEWS 14-24               Page 35                  16 Jun 1997


    general.  )

            [FSC0039] A type 2 packet extension proposal, version 4. Mark
            A. Howard.  FIDONET#1:260/340.  29th September 1990.

                              ( Defines the type 2.0+ packet message
    transport format. )

            [FSC0045] A proposal for a new packet format, version 1. Thom
            Henderson.  FIDONET#1:107/542.1.      17th April 1990.

                              ( Defines the type 2.2 packet message
    transport format.  )

            [FSC0068] A proposed replacement for FTS-0004, version 1. Mark
            Kimes.  FIDONET#1:380/16.0.  13th December 1992.

                              ( Defines kludge lines.  )

            [RFC0822] Standard for the format of ARPA Internet text
            messages.  David Crocker, University of Delaware.  13th August
            1982.

                              ( Defines the grammar and semantics of RFC
    messages.  )

            [RFC1036] Standard for the interchange of USENET messages.
            M Horton, AT&T bell labs; and R. Adams, Centre for seismic
            studies.  December 1987.

                              ( Defines changes to the grammar and
    semantics of RFC822 that are required for news instead of mail,
    including reply linking.  )

            [RFC1521] MIME (Multipurpose Internet Mail Extensions) Part
            One: Mechanisms for specifying and describing the format of
            Internet message bodies.  N. Borenstien, Bellcore; and N.
            Freed, Innosoft.  September 1993.

                              ( Defines Quoted Printable encoding of text.
    )

            [RFC1522] MIME (Multipurpose Internet Mail Extensions) Part
            One: Message header extensions for non ASCII text.  K. Moore,
            University of Tennesee.  September 1993.

                              ( Defines how to use Q-P encoding in message
    headers.  )

            [TYPE2EXT] An extension to type 2.0, 2.0+, and 2.2 message
            transport formats to eliminate most kludge lines from the
            message body.  Jonathan de Boyne Pollard.  FIDONET#2:440/4.0.
                               [ Not yet released.  ]

            -----------
            Jonathan de Boyne Pollard
    FIDONEWS 14-24               Page 36                  16 Jun 1997


            FIDONET#2:440/4.0

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

    FIDONEWS 14-24               Page 37                  16 Jun 1997


    =================================================================
                           COORDINATORS CORNER
    =================================================================


    Nodelist-statistics as seen from Zone-2 for day 164
    By Ward Dossche, 2:292/854
       ZC/2

     +----+------+------------+------------+------------+------------+--+
     |Zone|Nl-136|Nodelist-143|Nodelist-150|Nodelist-157|Nodelist-164|%%|
     +----+------+------------+------------+------------+------------+--+
     |  1 |  8367| 8277   -90 | 8277     0 | 8182   -95 | 8182     0 |31|
     |  2 | 15879|15855   -24 |15835   -20 |15774   -61 |15703   -71 |60|
     |  3 |   800|  761   -39 |  765     4 |  758    -7 |  758     0 | 3|
     |  4 |   543|  543     0 |  543     0 |  519   -24 |  514    -5 | 2|
     |  5 |    87|   87     0 |   87     0 |   87     0 |   87     0 | 0|
     |  6 |  1083| 1077    -6 | 1078     1 | 1078     0 | 1078     0 | 4|
     +----+------+------------+------------+------------+------------+--+
          | 26759|26600  -159 |26585   -15 |26398  -187 |26322   -76 |
          +------+------------+------------+------------+------------+

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

    FIDONEWS 14-24               Page 38                  16 Jun 1997


    =================================================================
                                NET HUMOR
    =================================================================


    From: "Mike Riddle" <[email protected]>
    To: "Baker, Christopher" <[email protected] (Christopher Baker)
    Date: Fri, 16 May 97 08:12:01 -0600
    Reply-To: "Mike Riddle" <[email protected]>
    Subject: Fwd: Java's Year 292 Million Bug

    ==================BEGIN FORWARDED MESSAGE==================
    Received: from austin.onu.edu (austin.onu.edu [140.228.10.1]) by
    monarch.papillion.ne.us (8.7.4/8.6.9) with ESMTP id BAA23416 for
    [email protected]>; Fri, 16 May 1997 01:19:06 -0500
    (CDT) Received: from austin.onu.edu (localhost.onu.edu [127.0.0.1])
           by austin.onu.edu (8.8.5/8.8.5) with SMTP id CAA85786
           for <[email protected]>; Fri, 16 May 1997
    02:11:31 -0400
    Date: Fri, 16 May 1997 02:11:31 -0400
    Errors-To: [email protected]
    Reply-To: [email protected]
    Originator: [email protected]
    Sender: [email protected]
    From: jenniferrose <[email protected]>
    To: [email protected]
    Subject: Java's Year 292 Million Bug


    YEAR 2000 WOES DON'T AFFECT JAVA UNTIL A.D. 292271023

    [5/13/97]

    Sun Microsystems Inc. today acknowledged the Year 292 Million Bug in
    the Java computer language, which could cause problems for Social
    Security recipients and millions of other computer-dependent users in
    292271023 A.D.

    Dr. James Gosling, the inventor of Java, divulged the problem and
    hastened to add that a team of specialists is now at work attempting
    to solve the problem sometime within the next 292,271 millennia.

    "We can't be certain Java will be around that long," said Gosling,
    inventor of Java. "But then again, we can't take any chances. Two
    hundred and ninety two million-plus years may seem like a long time
    for a species. But relatively speaking, in astronomical terms, it's
    nothing." Added Gosling, "I don't mean to brag, but Java is taking on
    a life of its own. We do see it as the computing platform of the 21st
    century and well beyond."

    For more information contact Lisa Poulson at [email protected]
    or 408-343-1630.

    http://java.sun.com/pr/1997/may/spotnews/sn970513.html

    _____________________________________________________
    FIDONEWS 14-24               Page 39                  16 Jun 1997


    jennifer j. rose        [email protected]     [email protected]
    Lawyer, Attorney, Counselor, All-Purpose Bitch
    P.O. Box 616    Shenandoah, IA 51601-0616
    voice   712-246-5531   fax  712-246-5533   home  unlisted
    VISA/Mastercard Accepted

    ===================END FORWARDED MESSAGE===================

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

    FIDONEWS 14-24               Page 40                  16 Jun 1997


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


    Christopher Baker
    Rights On! 1:18/14

                          A_THEIST Echo Available


    A_theism means free of religion in the way a_political means free of
    politics or a_sexual means free of sex characteristics or drives.

    With that in mind and ever cognizant of the continued pressure of
    religion to intrude itself into our government and its operations, the
    A_THEIST Echo is provided to inform and alarm and hopefully wake up
    the sleeping and too long silent majority to the peril on our
    doorstep.

    It is a Zone 1 Backbone Echo Hosted and Moderated by Rights On!
    [1:18/14] and Christopher Baker [card carrying member of American
    Atheists, Inc.]. Initial links may be obtained from your local
    Backbone source connection.

    The Echo is open to anyone who can discuss, without proselytizing, the
    extreme desirability of maintaining the absolute separation of State
    and church in this country as provided for in the U.S. Constitution
    and other Constitutions around the world.

    A sample of the first few messages and the statement of purpose of the
    Echo is available as A_THEIST.ZIP from this system anytime except
    0100-0130 ET and Zone 1 ZMH [USR HST ds online] if you wish to get an
    idea of whether to commit disk space to the Echo. An archive of the
    past traffic from the Echo is also available as A_ECHO1.ZIP,
    A_ECHO2.ZIP, and A_ECHO3.ZIP.

    Ask your Backbone connection to get it for you! The complete info is
    available in the current ELISTnnn.XXX file available from your NEC or
    REC or here. [Request ELIST.]

    I hope you will join us or ask your Sysop to request a link via their
    regular Backbone connections!

    QOFM.
    Chris

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

                               Future History

     1 Jul 1997
       Canada Day - Happy Birthday Canada.

     9 Jul 1997
       Independence Day, Argentina.
    FIDONEWS 14-24               Page 41                  16 Jun 1997


     1 Aug 1997
       International FidoNet PENPAL [Echo] meeting in Dijon, France

    13 Oct 1997
       Thanksgiving Day, Canada.

     1 Dec 1997
       World AIDS Day.

    10 Dec 1997
       Nobel Day, Sweden.

    12 Jan 1998
       HAL 9000 is one year old today.

    22 May 1998
       Expo '98 World Exposition in Lisbon (Portugal) opens.

     1 Dec 1998
       Fifteenth Anniversary of release of Fido version 1 by
       Tom Jennings.

    31 Dec 1999
       Hogmanay, Scotland. The New Year that can't be missed.

     1 Jan 2000
       The 20th Century, C.E., is still taking place thru 31 Dec.

    15 Sep 2000
       Sydney (Australia) Summer Olympiad opens.

     1 Jan 2001
       This is the actual start of the new millennium, C.E.

    -- If YOU have something which you would like to see in this
       Future History, please send a note to the FidoNews Editor.

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

    FIDONEWS 14-24               Page 42                  16 Jun 1997


    =================================================================
                           FIDONEWS PUBLIC-KEY
    =================================================================


    [this must be copied out to a file starting at column 1 or
     it won't process under PGP as a valid public-key]


    -----BEGIN PGP PUBLIC KEY BLOCK-----
    Version: 2.6.2
    Comment: Clear-signing is Electronic Digital Authenticity!

    mQCNAzINVLcAAAEEAM5dZN6t6j5Yc0kl7qegVFfiBeVoteuhDg4ay8h43u38Q4kO
    eJ9Mm7J89wXFb9vgouBVb4biIN6bTWCwcXTbGhBe5OIceLvluuxuEKsaIs/UwXNe
    Ogx5azIPhRfC7MJDe41Z8tMEBuHY/NE88cuxQ8yXWO126IRttavu6L/U5BwRAAUR
    tCRGaWRvTmV3cyBFZGl0b3IgPDE6MS8yM0BmaWRvbmV0Lm9yZz6JAJUDBRAyGwFS
    JZMgw7eCKz0BAZl0A/9xrfhpsEOqGiPfjy2qd9dv6tvSVPPVFu+Wy1lGTHYtuTtg
    FIN3fQ47AM3XzqHxWRWvp/xZYgR6sRICL7UFx94ShYBQc7CyqBBZKA0IvIWqXP/g
    c4Br+gQJR6CLiQK7TUyjUbqNbs6QAxuNUi4xFQM+O2Gene5/iTjHFmmSDj2C9YkB
    FQMFEDIOmHDTQ6/52IG1SQEBQ78H/Rz/mleIrtZwFIOhzy3JH4Z6FUTfZuM9nPcs
    1ZLjZCPptHvY7wEYJWGr03lPPJ6tj1VBXwTrWJTf/hOLsoi00GKV8t1thjqGDo23
    O91/bSQ+Vn0vBQ2vOEJys8ftxdoLJAyI5YLzHVT+RsMTQLIXVuPyrNcKs1vC2ql+
    UDHpU1R+9cG9JUEHpGI6z0DPnQ74SKbQH3fiVBpHhYx4BmvcBC4gWQzKMkDWFiq3
    8AssIZ7b9lWl3OBgQ4UM1OIDKoJyjRewIdKyl7zboKSt6Qu8LrcsXO3kb81YshOW
    ZpSS3QDIqfZC4+EElnB15l4RcVwnPHBaQY0FxUr4Vl4UWM36jbuJAJUDBRAyDpgY
    q+7ov9TkHBEBAQGoA/sFfN07IFQcir456tJfBfB9R5Z6e6UKmexaFhWOsLHqbCq6
    3FGXDLeivNn6NTz81QeqLIHglTuM3NP1mu8sw215klAG8G3M1NA2xLw7Eqhspze2
    raGvNeEwxl8e+PY9aZwBj4UWU+CmIm6QNiP0MtvR7QYDIKn5mZCDc3CLmr942IkB
    FQMFEDIOh0O8AhTPqRipPQEB4EYH/1gkDmdHL6lbEkFuQLrylF+weBl0XQ+kv7ER
    vWXYrvIrkppxtc4VAge6CXXEbOGJnvkFHgyNZzO9Q9O64QsmZvjip+4lhDLeNrdH
    X9DizS4YKXxkSKr9Yltmn2/AlBCx6jwcDIfkqy/P1tNWcikxZZMd6KryK0Wsres9
    Ik12OmVmJjQSxb5bS6Q8aYUbV3qwosGXTqy+BzYh/UYAX/XJIWa5kxFVSPKFSZ+5
    toiSzANd9SpHPEogGvQDHJlJ23lmsMx/6uHsR1LTsQ8su8zIk92XyqePJTjlMx2j
    D7KJWNR7Zzu4QHCXBkga5W8l2FfPk7D3+o7bXTLRuR1yTYGdNoiJAJUCBRAyDhwt
    SlKLwP4OFW0BAdaMA/9rcWQlSq44K9JuJ7fZUgt9fwxGreTud9fC8DvlbUW79+CA
    AHLTLLagcEF1OKsWzVBWcA2JEAp+TUTqktRN0oD8vnaw3uNJd1G5KK59hw0WR8x1
    v4ivypbSjiq95Y3gBunb7WjpyiFRWDlm0PrKrWHtbWzjnpPIpetln1UuqsSfbokB
    FQIFEDIOG9C3N61ZQ4Dr/QEBIzMH/1VxxztmBPBszbjZLDO8Svcax9Ng8IcWpcDy
    WqHCAA2Hoe5VtMD0v6w31ZgVqTPIvCark2Y/aTR1GofiuN9NUqbVV534AgAYLzYk
    DMT1swsPvqDTpOYgQl6PCGh6A5JGAbWJfKkX9XCUHJAAmiTsEVRNnjOgL+p6qjoh
    EfIG8CGehghWSRKl5eGeDAtbXupZKNjFI1t2XV+ks0RFQ/RPuTH7pF7pk7WO6Cyg
    +Dk2ZMgua0HRL1fXvHKb5Xzr3MVgsbAl5gP8ooIiD9MI/x5Irh3oo58VyoEZNBs/
    Kz+drGFDPljcS6fdiVCFtYIzMrshY6YsfLi0aB8fwOvFtxgBqli0J0NocmlzdG9w
    aGVyIEJha2VyIDwxOjE4LzE0QGZpZG9uZXQub3JnPrQoQ2hyaXN0b3BoZXIgQmFr
    ZXIgPGNiYWtlcjg0QGRpZ2l0YWwubmV0Pg==
    =61OQ
    -----END PGP PUBLIC KEY BLOCK-----


    File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the
    Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone
    1 ZMH at 1200-9600+ HST/V32B. The FidoNews key is also available on
    the FidoNews homepage listed in the Masthead information.

    -----------------------------------------------------------------
    FIDONEWS 14-24               Page 43                  16 Jun 1997


    =================================================================
                           FIDONET BY INTERNET
    =================================================================

    This is a list of all FidoNet-related sites reported to the Editor as
    of this appearance.

    ============

    FidoNet:

      Homepage     http://www.fidonet.org
      FidoNews     http://ddi.digital.net/~cbaker84/fidonews.html
      HTML FNews   http://www.geocities.com/Athens/6894/
      WWW sources  http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
      FTSC page    http://www2.blaze.net.au/ftsc.html
      Echomail     http://www.portal.ca/~awalker/index.html
      WebRing      http://ddi.digital.net/~cbaker84/fnetring.html

    ============

    Zone 1:       http://www.z1.fidonet.org

      Region 10:  http://www.psnw.com/~net205/region10.html

      Region 11:  http://oeonline.com/~garyg/region11/

      Region 13:  http://www.smalltalkband.com/st01000.htm

      Region 14:  http://www.netins.net/showcase/fidonet/

      Region 15:  http://www.smrtsys.com/region15/ [disappeared?]

      Region 16:  http://www.tiac.net/users/satins/region16.htm

      Region 17:  http://www.portal.ca/~awalker/region17.htm
          REC17:  http://www.westsound.com/ptmudge/

      Region 18:  http://www.citicom.com/fido.html

      Region 19:  http://www.compconn.net

    ============

    Zone 2:       http://www.z2.fidonet.org

    ZEC2:         http://fidoftp.paralex.co.uk/zec.htm [shut down?]
    Zone 2 Elist: http://www.fidonet.ch/z2_elist/z2_elist.htm

      Region 20:  http://www.fidonet.pp.se (in Swedish)

      Region 24:  http://www.swb.de/personal/flop/gatebau.html (in German)

      Region 25:
                  http://members.aol.com/Net254/

    FIDONEWS 14-24               Page 44                  16 Jun 1997


      Region 27:  http://telematique.org/ft/r27.htm

      Region 29:  http://www.rtfm.be/fidonet/  (in French)

      Region 30:  http://www.fidonet.ch  (in Swiss)

      Region 34:  http://www.pobox.com/cnb/r34.htm  (in Spanish)
          REC34:  http://pobox.com/~chr

      Region 36:  http://www.geocities.com/SiliconValley/7207/

      Region 41:  http://www.fidonet.gr (in Greek and English)

      Region 48:  http://www.fidonet.org.pl

    ============

    Zone 3:       http://www.z3.fidonet.org

    ============

    Zone 4:       (not yet listed)

      Region 90:
        Net 904:  http://members.tripod.com/~net904 (in Spanish)

    ============

    Zone 5:       (not yet listed)

    ============

    Zone 6:       http://www.z6.fidonet.org

    ============

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

    FIDONEWS 14-24               Page 45                  16 Jun 1997


    =================================================================
                          FIDONEWS INFORMATION
    =================================================================

    ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------

    Editor: Christopher Baker

    Editors Emeritii: Tom Jennings, Thom Henderson, Dale Lovell,
                      Vince Perriello, Tim Pozar, Sylvia Maxwell,
                      Donald Tees

    "FidoNews Editor"
        FidoNet  1:1/23
        BBS  1-904-409-7040,  300/1200/2400/14400/V.32bis/HST(ds)

     more addresses:
        Christopher Baker -- 1:18/14, [email protected]
                                      [email protected]
                                      [email protected]

    (Postal Service mailing address)
        FidoNews Editor
        P.O. Box 471
        Edgewater, FL 32132-0471
        U.S.A.


    voice:  1-904-409-3040 [1400-2100 ET only, please]
                           [1800-0100 UTC/GMT]

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

    FidoNews is published weekly by and for the members of the FIDONET
    INTERNATIONAL AMATEUR ELECTRONIC MAIL system.  It is a compilation
    of individual articles contributed by their authors or their
    authorized agents.  The contribution of articles to this compilation
    does not diminish the rights of the authors.  OPINIONS EXPRESSED in
    these articles ARE THOSE OF THE AUTHORS and not necessarily those of
    FidoNews.

    Authors retain copyright on individual works; otherwise FidoNews is
    Copyright 1997 Christopher Baker.  All rights reserved.  Duplication
    and/or distribution permitted for noncommercial purposes only.  For
    use in other circumstances, please contact the original authors, or
    the Editor.

                           =*=*=*=*=*=*=*=*=

    OBTAINING COPIES: The most recent issue of FidoNews in electronic
    form may be obtained from the FidoNews Editor via manual download or
    file-request, or from various sites in the FidoNet and Internet.
    PRINTED COPIES may be obtained by sending SASE to the above postal
    address.  File-request FIDONEWS for the current Issue.  File-request
    FNEWS for the current month in one archive.  Or file-request specific
    back Issue filenames in distribution format [FNEWSEnn.ZIP] for a
    FIDONEWS 14-24               Page 46                  16 Jun 1997


    particular Issue.  Monthly Volumes are available as FNWSmmmy.ZIP
    where mmm = three letter month [JAN - DEC] and y = last digit of the
    current year [7], i.e., FNWSFEB7.ZIP for all the Issues from Feb 97.

    Annual volumes are available as FNEWSn.ZIP where n = the Volume number
    1 - 14 for 1984 - 1997, respectively. Annual Volume archives range in
    size from 48K to 1.4M.


    INTERNET USERS: FidoNews is available via:

                         http://www.fidonet.org/fidonews.htm
                         ftp://ftp.fidonet.org/pub/fidonet/fidonews/
                         ftp://ftp.aminet.org/pub/aminet/comm/fido/

                                     *=*=*

    You may obtain an email subscription to FidoNews by sending email to:

                         [email protected]

    with a Subject line of: subscribe fnews-edist

    and no message in the message body. To remove your name from the email
    distribution use a Subject line of: unsubscribe fnews-edist with no
    message to the same address above.

                                     *=*=*

    You can read the current FidoNews Issue in HTML format at:

                         http://www.geocities.com/Athens/6894/

    STAR SOURCE for ALL Past Issues via FTP and file-request -
    Available for FReq from 1:396/1 or by anonymous FTP from:

                         ftp://ftp.sstar.com/fidonet/fnews/

    Each yearly archive also contains a listing of the Table-of-Contents
    for that year's issues.  The total set is currently about 11 Megs.

                                =*=*=*=

    The current week's FidoNews and the FidoNews public-key are now also
    available almost immediately after publication on the Editor's new
    homepage on the World Wide Web at:

                 http://ddi.digital.net/~cbaker84/fidonews.html

    There are also links there to jim barchuk's HTML FidoNews source and
    to John Souvestre's FTP site for the archives. There is also an email
    link for sending in an article as message text. Drop on over.

                           =*=*=*=*=*=*=*=*=

    A PGP generated public-key is available for the FidoNews Editor from
    FIDONEWS 14-24               Page 47                  16 Jun 1997


    1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from
    Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18.  It
    is also posted twice a month into the PKEY_DROP Echo available on the
    Zone 1 Echomail Backbone.

                               *=*=*=*=*

    SUBMISSIONS: You are encouraged to submit articles for publication in
    FidoNews. Article submission requirements are contained in the file
    ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
    from 1:1/23 [1:18/14] as file "ARTSPEC.DOC".  ALL Zone Coordinators
    also have copies of ARTSPEC.DOC. Please read it.

    "Fido", "FidoNet" and the dog-with-diskette are U.S. registered
    trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
    and are used with permission.

            "Disagreement is actually necessary,
             or we'd all have to get in fights
             or something to amuse ourselves
             and create the requisite chaos."
                               -Tom Jennings

     -30-

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