

 EchoList - The EchoMail Conference List                                Page 1
 Technical Reference                                        as of: 21 Feb 1993

                       ================================
                       The EchoList Technical Reference

                                  21 Feb 1993
                       ================================


 CONTENTS

 1.   PURPOSE.....................................................    2
 2.   ECHOMAIL DISTRIBUTION BACKBONES.............................    2
 3.   DEFINITIONS.................................................    3
 4.   HOW IT WORKS................................................    3
 5.   ECHOLIST CONTENTS...........................................    4
 6.   RULES FILE REPOSITORY.......................................    4
 7.   SPECIAL DATABASE FIELDS.....................................    5
      7.1.   NODE ADDRESSES.......................................    5
      7.2.   NAME FIELDS..........................................    5
      7.3.   KEY FIELD............................................    5
 8.   UPDATE MESSAGES.............................................    6
      8.1.   TO ADD OR UPDATE AN ENTRY............................    7
      8.2.   TO DELETE AN ENTRY...................................    7
      8.3.   TO ADD OR UPDATE A CONFERENCE RULES FILE.............    8
             8.3.1. Rules File Attach.............................    8
             8.3.2. Rules File in Message Text....................    8
 9.   MESSAGE FORMATTING DETAILS..................................    9
 10.  UPDATE MESSAGE FIELD DESCRIPTIONS...........................    9
 11.  PUBLICATION.................................................   13
 12.  ADVANCED TECHNICAL ISSUES...................................   14
      12.1.  DATABASE IMPLEMENTATION..............................   14
      12.2.  KEY GENERATION.......................................   14











 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                                Page 2
 Technical Reference                                        as of: 21 Feb 1993

 1.   PURPOSE

 This document provides complete details on how to submit and maintain entries
 in the EchoList.  For a quicker reference you can refer to the companion
 Users Guide.  This Technical Reference is painfully long and boring.  But
 that's the way it goes...

 The EchoList is a monthly publication which attempts to document certain
 interesting information about EchoMail Conferences; "interesting" to people
 who would like to participate, interesting to EchoMail Coordinators and those
 who route the conference traffic, and potentially interesting to the
 Conference Moderator.  The base product of the EchoList database is the
 detailed Conference listing.  But, as needs are identified which can be
 satisfied with the available information, additional reports and analyses can
 be developed.

 Basically, the EchoList is maintained by the Moderators who choose to
 advertise their conferences here.  Additions and updates to the database are
 done by submitting NetMail messages addressed to a special name and node
 address.  The Subject of the message indicates what is to be done, and the
 body of the message has the data for the database entry, formatted as one
 keyword and value per line.  If you're familiar with AREAFIX or RAID message
 formatting, this will give you no trouble.

 Theoretically, updates should be sent by the conference Moderator.  A
 password field is provided for the Moderator's use for controlling updates.
 As far as I'm concerned, anybody who can help with additional information
 (like seen-by's, paths...) is invited to do so.  And, if future automated
 data gathering tools can be implemented, it will be encouraged.  Of course,
 if the Moderator does not have the time to maintain the listing, a helpful
 associate could do it.  Updates do not HAVE to be submitted by the Moderator,
 they just have to identify one.

 I created and maintain the EchoList as an advertising service for Moderators,
 and as a reference for users.  It is a completely open, international and
 inter-network publication.  I do not generate, nor do I normally censor the
 entries--they are the work of the Moderators.  In kind, I also take no
 responsibility for the accuracy of any of the information in these entries.
 I am in no position to pass judgment on the validity of EchoList entries.  It
 is strictly a first come, first served database.

 A final note on adding entries to EchoList.  I will not list any conference
 which promotes illegal activities.  Rejections based on unreasonableness will
 be solely at my discretion.

 The EchoList was originated by Thomas Kenny, and the bulk of the original
 design was initiated by Thomas, for which he has my thanks.

 2.   ECHOMAIL DISTRIBUTION BACKBONES

 A clarification is needed on the subject of EchoMail backbones and backbone
 conferences.  The EchoList is not an official publication of any of the


 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                                Page 3
 Technical Reference                                        as of: 21 Feb 1993

 backbones, zones, networks or FidoNet.  It is an open, free directory of
 information on ANY EchoMail conference, anywhere.

 However, a couple of distribution backbones have implemented a requirement
 (which I heartily endorse) that any conference they carry must have a
 Moderator identified.  The Zone 1 EchoMail Coordinator (among others) has
 decided to use the EchoList as a convenient repository for official
 information on backbone conferences.  So the only exception to the EchoList's
 voluntary status is that dictated by the distribution backbone you may choose
 to use.  If you are using one of these backbones you must list, at a minimum,
 the Tag name, the Title, and the Moderators name and node number.

 I have no direct involvement in the distribution or administration of
 EchoMail itself.  Any rules governing your conference need to be obtained
 from your network and/or distribution backbone.

 3.   DEFINITIONS

 I used-to provide lengthy definitions of Moderators and Coordinators, since I
 knew of no where else they were documented.  This is no longer the case,
 since the backbones have published policy documents containing painstaking
 detail.  I refer you to those documents.

 In the case of the EchoList, a Moderator is the person who defines a
 Conference, and keeps it on track.  The Moderator may or may not be the
 originator of the conference.  But he or she is assumed to be the one with
 authority over the internal operation of the conference, with the right to
 define it's purpose, policies and rules.  If a conference has no Moderator it
 will not be listed in the EchoList.  If more than one Moderator is listed for
 a conference entry in the EchoList, all are assumed equal in authority over
 that database entry.

 If you know of a conference which you feel is important to the community and
 it doesn't have a moderator I seriously suggest you consider taking on the
 job.  How you do that, however, is business internal to the conference.

 4.   HOW IT WORKS

 If a Moderator wants to list a conference in the EchoList, he or she must
 send a message in the proper format (as defined below) to the EchoList update
 processor at 1:1/201.  Since this is a completely automated procedure, the
 address name and node number must be exact in order to be picked-up.

 Update messages are processed at least once a day; I'm working on the
 performance so that they can be processed after every NetMail call.  Every
 properly addressed update message will generate a reply message back to you
 via NetMail--even if the update failed.  In addition, adds and updates of
 conference entries will be broadcast to interested EchoMail conferences
 (unless you tell ELISTUPD not to).

 In order to provide a level of reliability to the list, EchoList entries
 purge-off after six months.  If you want to keep your entry active, you

 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                                Page 4
 Technical Reference                                        as of: 21 Feb 1993

 should re-send an update periodically (even if there are no changes) in order
 to refresh the list.  The current purge criteria deletes EchoList entries
 with a last-modified date older than six months.  The last-modified date is
 the date the message was received and processed.  The EchoList is published
 on a monthly basis (around the first of each month) and purging is not done
 until the production date following the six-months anniversary.

 Updates to the EchoList are processed directly against the database, so there
 is no advance cut-off date for inclusion in a given edition.  BUT, the
 EchoList is currently maintained as part of a hobby, so other time
 constraints will dictate how much can actually be accommodated in a given
 month and what the actual production date will be.  It could be anywhere from
 the 25th through the 5th.  I can only suggest that important changes be sent
 early in the month.

 5.   ECHOLIST CONTENTS

 The EchoList is maintained in an object-oriented database, which improves
 data management and reporting, and provides a great deal of flexibility
 concerning the contents of the database.  But the update messages are
 processed by an automated front-end program which edits and processes them;
 and it is quite unforgiving.  Computer programs are very literal cretins.

 The minimum information required for an EchoList entry includes: The symbolic
 area Tag name used by the conference, a Title or brief descriptive phrase for
 the conference, and at least one Moderator's name and node number.

 I understand that, for security reasons, certain Moderators do not want to
 publicize the Tag name in order to control unauthorized links to a private
 conference.  The EchoList has the ability to suppress the display of the Tag
 name in the EchoList reports.  However, the Tag name is the key to the
 database and all update processes.  So even if you want it unpublished, it
 must be provided.

 In addition to the Tag name, the EchoList implements a derived Key field for
 each conference.  You can ignore the existence of this internal Key in all
 but the most unusual situations.  It is used to provide a unique, DOS file
 name compatible abbreviation of the Tag, and to allow multiple conferences
 with the same Tag (perhaps in different networks) to maintain independent
 EchoList entries.  For those interested, there is a section devoted to the
 topic later in this document.

 If you feel there is a piece of information that is missing from this
 database but vital, please bring it to my attention.

 The best way to explain the various fields in the EchoList is to describe the
 format for submitting additions and updates.  You'll find that in section 7.

 6.   RULES FILE REPOSITORY

 In addition to the EchoList itself, I provide a repository for text files
 documenting the rules for individual conferences.  The rules files are

 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                                Page 5
 Technical Reference                                        as of: 21 Feb 1993

 tracked in the database, but are not reported as part of the EchoList.  They
 are stored in a separate compressed file.  Rules files have no purge criteria
 and do not have to be refreshed unless you change them.  They will be valid
 as long as there is an EchoList entry for that conference.

 7.   SPECIAL DATABASE FIELDS

 7.1.    NODE ADDRESSES
 The EchoList has a number of fields that provide storage of Node Addresses.
 The EchoList supports "5-D" or "Domain" addressing throughout--with a twist.

 All places in the EchoList where you can use a node address, support the full
 notation:
           zzz:ttt/nnn.ppp@ddddddd

 where zzz is the zone number, ttt is the net, nnn is the node, ppp is the
 point (if applicable), and ddd is the Domain.  Zone, net, node and point are
 each integer fields.  Domain is a text field than cannot contain spaces.
 Other than that, the Domain can contain anything you need.

 The twist is that the EchoList allows use of the Domain field by itself to
 specify non-FidoNet addresses.  Lets say, for example, you wanted to list
 your Compuserve user id as an alternate address, you could enter:

           MOD  Mike Fuchs, 1:266/71@fidonet.org
           MOD  Mike Fuchs, @CIS-72760.3326

 But who'd want to do that...  Ah well, it's a Lucky Strike extra I threw in
 to the NODE_ADDRESS processing routines.

 7.2.    NAME FIELDS

 In order to accommodate the wide variety of ways people want their name to
 appear, I've devised a really strange way of parsing names in incoming
 messages.  In order to sort names by last name, I need to store the first
 name and last name separately.

 The line is parsed into tokens--words separated by spaces, tabs or commas.
 When I expect a name and address, the last token (word) is looked-at to see
 if it's a node address.  If it is, fine.  If it isn't, it defaults to the
 address of the sender of the message.  From there, at least the last token is
 taken as the last name--even if it means there's no first name.  I work my
 way backwards through the stack of tokens.  I add each token to the beginning
 of the last name field until I hit the first token or hit a token that ends
 in a period (which is assumed to be a middle initial).  The first name and
 middle initial (if present) are put in the first name field.  Aren't you
 sorry you asked?

 7.3.    KEY FIELD

 The primary index into the EchoList database is the Tag name.  Starting with
 version 2 the EchoList also maintains an index field called the area KEY.


 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                                Page 6
 Technical Reference                                        as of: 21 Feb 1993

 For the sake of standardizing definitions:  "Tags" are the symbolic mnemonics
 used by conference distribution software.  They are also referred to as Area
 names, Group names or Tag names.

 "Keys" are one-to-eight character alphanumeric codes, unique for each
 EchoList entry.  They are generated automatically by the EchoList system
 based on the area Tag name you use.  They are intended to be compatible with
 all operating system file name conventions (MS-DOS being the least common
 denominator).  They are no more than eight characters, include only
 alphabetic and numeric characters, and are guaranteed to be unique within all
 EchoList entries.

 99% of you can ignore the existence of these keys.  The Tags are still used
 for identification as before.  The Keys are an addition.  Using another index
 as the unique key will allow multiple EchoList entries using the same Tag.
 The update program will allow inserting multiple entries for the same Tag by
 manually specifying unique Keys.

 Another use of the Key field is to generate unique file names for the rules
 files.  This eliminates the chance of two moderators accidentally using the
 same names.  It also allows accepting Rules File text in NetMail messages,
 with ELISTUPD creating the .RUL file here (rather than having to send file-
 attaches).

 If you want to manually specify a Key, it must follow the same rules as the
 automatically generated ones.  Namely:  It must be unique within the EchoList
 database, it must be from one to eight characters, and it must only contain
 alphabetic and numeric characters.  If specified, the KEY line must
 immediately follow the TAG line.

 8.   UPDATE MESSAGES

 EchoList updates must be formatted and transmitted in a NetMail message as
 explained below.  The update process is completely automated, which requires
 strict adherence to this format.

 I would suggest using a message generator such as TELL or ROBOT against a
 text file to generate the Conference update message.  But, please DO NOT SHIP
 IT AS A FILE ATTACH!  The information must be in the body of a message.

 To add or update an EchoList entry, submit a NetMail message to "ECHOLIST" at
 1:1/201.  The message subject is the type of processing to be done, usually
 "MOD UPD".  The body of the message text has the data for the database entry,
 formatted so that every line starts with a special keyword that identifies
 the field name, followed by the data to be put in that field.  Most of the
 lines are optional.  If you don't want to supply data for a given field,
 don't include it in the message at all.  The only required fields are TAG,
 TITLE and MODERATOR.

 The first line describing a conference entry is TAG.  The other lines can
 come in any order, but TAG must come first.  The CAPITALIZED part of the
 keyword is the minimum abbreviation you can use.  The To-name, subject,
 keywords and passwords are NOT case sensitive.

 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                                Page 7
 Technical Reference                                        as of: 21 Feb 1993

 The EchoList update processor is run daily.  All submissions will generate a
 reply message whose subject will explain that the entry was: "Accepted",
 "Accepted with Warnings", or "Rejected for Errors".  Acceptance messages will
 also specify the Edition in which the update will appear.  The text body will
 provide detailed, line-by-line edit messages, and it may also include
 standard epilog text appended to all reply messages as a sort of bulletin
 facility from me to the moderators.

           Syntax used below:  CAPITALS are used to indicate the
           minimum abbreviation of reserved-word literals--you don't
           have to capitalize anything.  Upper/lower case for
           passwords and keywords is irrelevant.  <...> is used to
           indicate a value to be supplied by the submitter.

 There are three formats for Moderators to use;  two for EchoList Entries and
 one for Rule File submission.

 8.1.    TO ADD OR UPDATE AN ENTRY

 To:       ECHOLIST
 At:       1:1/201
 Subject:  MODerator UPDate

 In the body of the message:

     TAGname       <symbolic area name> /NOSHow
     TITLe         <brief area title for sorting>
     DESCription   <A full description of the conference, audience, topics...>
     MODerator     <moderator name>, <moderator node>
     PASSword      <current password>, <new password>
     TOTalnodes    <number of nodes carrying this conference>
     VOLume        <number of messages>/<Month or Day or Week>
     RESTrictions  /SYSop /MOD-apvl /MEMber
     ORIGin        <origination node of the distribution
     DISTribution  <distribution areas or vehicles of note>
     GATEway       <gateways to other zones & networks crossed by the
                   conference>
     SEENby        <node list>
     PATH          <node-pair list>
     ---

 I've left off the KEY field to avoid confusion.  If you want to override the
 automatic key generation, read the docs on the KEY line.  If used, the KEY
 line must come immediately after the TAG line.

 8.2.    TO DELETE AN ENTRY

 This also deletes its Rule File if it exists.

 To:       ECHOLIST
 At:       1:1/201
 Subject:  MODerator DELete


 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                                Page 8
 Technical Reference                                        as of: 21 Feb 1993

 In the body of the message:

     TAGname       <symbolic area name>
     PASSword      <current password>
     ---

 8.3.    TO ADD OR UPDATE A CONFERENCE RULES FILE

 8.3.1.    Rules File Attach
 In order to submit a Rules File the EchoList entry must already have been
 added with a MOD UPD message.  Rules File messages can be used only for that-
 -adding Rules Files to entries that are already in the database.

 There are two ways to submit a rules file.  The first way is to create a text
 file containing your rules and policies, and send it via NetMail as a file-
 attach.  The subject of a file attach message is obviously the name of the
 file, and the file-attach bit must be on in the message header.  The message
 body text must specify the Tag name and password to link the rules file to.

 To:       ECHOLIST        (as a File Attach message)
 At:       1:1/201
 Subject:  <attached rules file name (xxxxxxxx.RUL)>

 In the body of the message:

     TAGname       <symbolic area name>
     PASSword      <current password>
     ---

 8.3.2.    Rules File in Message Text
 The second way of submitting a rules file is to imbed it in the text of a
 NetMail message.  This can allow for routing the rules file through
 intermediate systems.  The Rules File text starts with the first line
 FOLLOWING the RULETEXT keyword line, and ends at the "---" tear line.  During
 processing here, all those lines, word-wrapped at 80 characters, are written
 to a file named for your entry's Key.

 To:       ECHOLIST        (as a File Attach message)
 At:       1:1/201
 Subject:  MODerator RULes

 In the body of the message:

     TAGname       <symbolic area name>
     PASSword      <current password>
     RULEtext
     <rule file text ...>
     < . . . >
     ---

           * Note you MUST use a --- tear line in ALL of these
           messages after the update info and before any trailing
           "signature" or message text.

 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                                Page 9
 Technical Reference                                        as of: 21 Feb 1993


 9.   MESSAGE FORMATTING DETAILS

 Each keyword MUST begin on a new line.  Lines MUST end with a 'hard' return.
 Most keywords allow multiple lines to be used for fields that don't fit on
 one line.  When multiple lines of data are provided for a single keyword,
 every line MUST be preceded by the keyword.

 The first keyword line must be the area Tag name.  The order of the rest of
 the lines is unimportant, but it is suggested that the MODerator line be
 entered before any SEENby and PATH lines.  If more than one conference is
 being listed in a single message, separate the lines for one conference from
 the other with at least one blank line.

 An update that is missing some keyword line(s) results in no change to the
 fields of an existing EchoList entry affected by the missing keyword(s).  If
 you want to delete a field such that a keyword's database field is null (like
 dropping all Restrictions) supply the keyword on a line by itself with no
 arguments.

 Keyword lines generally replace the associated field(s) in the database in
 their entirety.  The exceptions are MODERATOR, PATH and SEENBY.  Normally,
 the node list for PATH and SEENBY simply replaces the entire list in the
 database.  But, if you want to modify the list that's already there, you can
 prefix the keyword with a plus (+).  The "+" will cause the list to be added
 to the existing database (duplicates are ignored).  Likewise with MODerator
 lines, if ANY are in an update, the entire list of Moderators is replaced in
 the database.  If (at least the first) MOD keyword is prefixed with a "+",
 all the MOD lines will be added to the database record.

 If the message subject is MODerator DELete, only the Tag name field and
 Password (if set) are used.  The Conference will be dropped from the list,
 and the Rules File (if it exists) will be deleted.

 For Rules File updates, only the Tag name field and Password (if set) are
 used.  The rules file name will be forced to the conference Key to make sure
 it doesn't duplicate someone else's file name.

 10.  UPDATE MESSAGE FIELD DESCRIPTIONS

 The following is a description of each field.  The part of the keyword that
 is capitalized is the minimum required.  The actual case of the keywords you
 use is irrelevant.  Brackets ([]) denote optional arguments -- do not include
 the brackets in your message.  Text character counts are recommended
 maximums.  In reality, all text fields are variable length, and the only
 limitation is overall record size and my opinion of what is reasonable.

 A * means the line is optional.
 A + means the line can be repeated multiple times.



 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                               Page 10
 Technical Reference                                        as of: 21 Feb 1993

                   MINIMUM
 KEYWORD     *+    ABBREVIATION    ARGUMENTS
 TAGname           TAG <areaname> [/NO]
                   The "area name" used for distributing the conference.  If
                   the moderator does not want to make the area name public,
                   you can add the parameter "/NOSHOW" (with at least one
                   intervening blank or tab) after the area name.

 PASSword          PASS <currentpwd>[, <newpwd>]
                   The current password field is only required if one has been
                   set.  If set, the current password must match in order to
                   do a Moderator Update or Delete or Rules File.  To change
                   the password at any time, simply provide the current
                   password, a comma, and the new password.  An initial
                   password is set by leaving the current password field blank
                   and starting with the comma.  Case is ignored.  There is no
                   facility for removing a password (changing it to null).
                   [Text 12 chars]

 MODerator    +    MOD <firstname> <lastname(s)>, <node>
                   The name and net address of the moderator, separated by a
                   comma.  ONLY ONE MODERATOR AND ADDRESS CAN BE LISTED PER
                   LINE.  If multiple Moderators need to be listed, they will
                   be reported in the same order submitted.  Do not use middle
                   names.  If you use a middle initial, make sure it has a
                   period.  Node numbers in this field and throughout the
                   database are stored as four integers plus a text Domain.
                   They are input and displayed as
                   <zone>:<net>/<node>.<point>@<domain> .  The 'point' is
                   (obviously) optional, and if the zone is not specified, the
                   zone of the message sender is used.  If no zone is found
                   (@INTL address), the zone defaults to the zone of the
                   EchoList processor.  If the domain is omitted, but the zone
                   matches either the sender or the EchoList processor
                   address, that Domain text is used.  If there is still no
                   Domain, the EchoList has a list of zone-domain pairs to use
                   as a guess.  If anyone can provide me with a more complete
                   list, please send it!

 TITLe             TITL <short conference title>
                   A SORT-ABLE title for the conference. (avoid starting with
                   things like A, An, The...)
                   [Text 70 chars]

 DESCription  +    DESC <longer description>
                   Describe the conference. The topics, audience, policies,
                   and anything else that would be helpful.  Don't bother
                   trying fancy formatting.  All the lines are combined and
                   word-wrapped into a single paragraph.

 The following three lines, ORIGIN, DISTRIBUTION and GATEWAY are really just
 an organized set of free text fields you can use to describe sources and
 contacts that control links to the conference.  Use none, any or all of them
 as you see fit.  If you are on a formal distribution backbone of some kind,

 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                               Page 11
 Technical Reference                                        as of: 21 Feb 1993

 don't just say BACKBONE--there are lots of them.  Specifically say "Zone 1
 Backbone" or "Zone-3 Backbone" or "EchoNet Backbone", etc.

 ORIGin       *+   ORIG <originator node text>
                   If appropriate, describe the originator node of the
                   conference.
                   [Text 70 chars]

 DISTribution *+   DIST <distr1>[, <distr2>, ... <distrN>]
                   If appropriate, describe the extent and/or manner in which
                   the conference is distributed, and/or limited.  Multiple
                   keywords separated by commas and/or spaces are fine.  Valid
                   regional descriptors would be: Z1-BACKBONE, ALTERNET, ZONE-
                   1, REGION-13, NET-105, LOCAL-CHICAGO, etc.  Restrictive
                   values would be: NET-107-ONLY, CHICAGO-ONLY.  If topology
                   is strict, distribution node(s) can be listed as:
                   1:123/789.  No descriptive text, please.  This field is
                   manually edited by me to some degree for consistency and
                   reasonableness.  When and if I think I've got a complete
                   enough list, I'll implement automatic checking.
                   [Text 70 chars]

 GATEway      *+   GATE <gate1> VIA <gate2>[, <gate3> VIA <gate4>, ...]
                   If the conference is transmitted via gateways to other
                   zones or networks, use this field to specify those links.
                   Each gateway must be a pair of expressions separated by the
                   word "via".  Each expression can be either a node number or
                   an environment name.  If multiple gateways are listed,
                   separate them with commas.  e.g.:  UseNet via 999/111,
                   Zone-3 via 1:200/999, 2:100/200 via 3:200/100.
                   [Text 70 chars]

 TOTalnodes   *    TOT <numnodes>
                   This is an estimate of the total number of nodes that are
                   active in the conference.  It is NOT a descriptive text
                   field.  It's optional.  If supplied, save the editorials--
                   it's just a single integer number.

 VOLume       *    VOL <num>/M  or  VOL <num>/W  or  VOL <num>/D
                   This is an estimate of the number of messages entered in a
                   given period of time for the benefit of those planning to
                   link-in.  Enter it as a NUMBER followed by a SLASH followed
                   by the word MONTH, WEEK, or DAY.

 RESTrictions *    REST [/SYS] [/MOD] [/MEM]
                   This line can contain one or more restriction identifiers.
                   It's a shorthand reference to certain Moderator-imposed
                   rules.  Enter /SYSOP if the conference is restricted to
                   Sysops only.  Enter /MOD-APVL if Moderator approval is
                   required prior to linking in.  Enter /MEMBER if
                   participants must be validated members of some group or
                   organization (e.g.: MENSA-ONLY).  Note that these are not
                   any-old text string you want to call a restriction.  These
                   actually set individual, pre-defined, binary flags in the

 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                               Page 12
 Technical Reference                                        as of: 21 Feb 1993

                   EchoList database.  If there are other generic flags you
                   think should be added, let me know.

 SEENby       *+   SEEN <node> [<node> <node> ... <node>]
                   This is a list of nodes that get the conference.  This is
                   probably a total waste of space if you're documented as
                   being distributed on one of the backbones.  You can enter
                   them in any order, and can simplify them the way real SEEN-
                   BY lines are in messages (dropping the zone & net when
                   they're the same as the previous node).  If the domain,
                   zone and/or net are missing from the first node, they are
                   carried from the moderator address;  if that's missing,
                   from the sender's address.  They are also carried forward
                   from one line to the next if needed.  The EchoList will
                   automatically simplify them, eliminate duplicates, and sort
                   them.  The bottom line is, you can pull these lines
                   straight from messages if you like.  If you don't know (or
                   care about) the nodes, but know nets, or there are too many
                   to list at the node level, drop the node number, such:
                   "1:107/".

 +SEENby      *+   This is exactly the same as SEEN above, except that the
                   list of nodes is added to the list already in the database.

 PATH         *+   PATH <node> [<node> <node> ... <node>]
                   or PATH <node><><node>[, <node><><node>, ...]
                   There are two ways to provide this data.  Internally to the
                   EchoList database, the path connections are stored as
                   unordered pairs of nodes.  So the method of input does not
                   affect storage in the database.  The simplest method of
                   input is to have one line for each valid node path (like
                   the PATH lines added by certain mailers/scanners).
                   Formatting would look like the SEENby line, but the order
                   will indicate the actual path taken by a message, and
                   individual lines will not be concatenated but be treated as
                   different paths.  Duplicate segments will automatically be
                   eliminated during database processing, so you can use
                   multiple, overlapping PATH lines from messages as the basis
                   for this.  One warning, however: long PATHs in real echo
                   messages get "wrapped" with follow-on lines starting with
                   PATH.  This is not correct for the EchoList.  Either turn
                   such wrapped lines from an individual message into one long
                   line, or repeat the last node number from the previous line
                   at the beginning of the next line to show that link.

                   Alternatively, you can provide the input in the same format
                   that EchoList outputs it: as pairs of linked node numbers
                   connected by the "<>" characters.  Regardless of the format
                   used, please edit-in the zone numbers and domains where
                   appropriate.  Both input formats 'inherit' domain, zone and
                   net numbers from previous entries in the same way as SEENby
                   lines.


 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                               Page 13
 Technical Reference                                        as of: 21 Feb 1993

 +PATH        *+   This is exactly the same as PATH above, except that the
                   list of node pairs is added to the list already in the
                   database.

 There are a few fields that you cannot set directly, but are retained in the
 EchoList database.

 rule file name    This is not a keyword provided field.  If a rule file
                   update is sent-in, the file name is stored with the
                   database entry.

 date added        The date the entry was originally added.

 last modified     The date and sender of the last update message successfully
                   processed.

 11.  PUBLICATION

 The EchoList is published on or about the first of each month.  The monthly
 release is sent to Regional Software Dist nodes who want it (1/3xx).  There
 is no guarantee that they will make it available for download or file-
 request, or pass it across zones unless you ask them.

 The latest version (which may include interim updates during a month) will
 always be available for file-request from 1:1/201 via the "magic" file name:
 "ECHOLIST" (no period or extension).  The actual file name you get will be
 ELISTnnn.LZH, where nnn is the edition identifier.  It will contain, at a
 minimum, the file ELISTnnn.TXT, the detailed EchoList report sorted by
 conference title.

 The combined rules files can be requested as "ECHORULE", which will provide a
 file named ELRULnnn.LZH.

 These instructions will be updated from time-to-time, and are available for
 file-request via the "magic" file name: "ECHOMOD".  Which delivers the file
 ELMODmyy.LZH.

 The EchoList, it's derivative reference files, and these instructions, are
 all Copyright (c) Michael G. Fuchs 1988-93, and all rights are reserved.  All
 files may be freely copied and distributed provided no charge is made for
 such copying and distribution, and no changes whatsoever are made to the
 files or their contents.

 Comments, questions and suggestions should be sent to me, Mike Fuchs, at
 1:1/201, and are heartily encouraged.  Thank you for your patience with these
 long-winded instructions.




 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                               Page 14
 Technical Reference                                        as of: 21 Feb 1993

 12.  ADVANCED TECHNICAL ISSUES

 This is really absurdly detailed information that nobody should have to be
 concerned with.  But, for those of you who are interested, here it is.

 12.1.   DATABASE IMPLEMENTATION

 The EchoList system was completely rewritten from the ground-up for version
 2.  It is implemented in C++, and utilizes an Object Oriented database class
 of my own.  When It's "done" I will consider making the system available as a
 package to those who want to maintain a private EchoList.  When it's
 available, I'll publicize it.

 The text fields in the database are variable length strings.  Their length is
 not arbitrarily limited, however you can be assured I'd edit-down any text
 submitted that was really excessive.

 Seen-by node-addresses and Path node-address pairs are stored in Sets
 separate from the base EchoArea table, so the number of entries per area is
 unlimited.  This, coupled with storage of node numbers in four integer fields
 plus a text field each, provides the maximum flexibility in reporting and
 analysis (like path analysis that'll get done some day).

 I have discovered a bewildering range of differences in message files sent
 from various editors.  They all seem to have their own little quirks.  If you
 know of any message editor that cannot generate a hard return under user
 control, please let me know with a sample message.

 12.2.   KEY GENERATION

 Beyond the internal uses for duplicate Tags and Rules File naming, interest
 was expressed in having a standardized source for filenames unique to each
 conference.  I don't know whether anybody will use them, but the list of Keys
 are available in a couple of table files, as well as in the distributed data-
 file version of the EchoList.  I'll also publish the algorithm, but because
 of the collision detection logic you can't be sure you're generating exactly
 the same Key as the EchoList.  For what it's worth, I'm supplying them.  If
 anybody has a use for them, let me know.

 How does the Key get generated?  You shouldn't need to care.  And I can't
 take credit for the algorithm, as much of it was suggested by others.  But if
 you're curious...

 First, the Tag has all non-alphanumeric characters removed.  If the result is
 eight characters or less, we're done.

 Next, any vowels beyond the first character are removed.  (The first
 character is never dropped.)

 If it's still longer than eight characters, then we drop every fourth
 character.

 If all this hasn't gotten it <= 8 characters, truncate it to eight and we are
 done.

 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                               Page 15
 Technical Reference                                        as of: 21 Feb 1993

 Now the Key is checked for collision with existing Keys for other Area Tags.

 If it collides, it has '0's appended one-by-one until doesn't collide.  If
 it's already eight chars, the last character is replaced with a '0'.

 If it continues to collide, the code starts incrementing the trailing numbers
 until it doesn't.

 Anybody got a better idea, let me know.























 Copyright (c) 1993 by Michael G. Fuchs
