


 EchoList - The EchoMail Conference List                                Page 1
 Technical Reference                                         as of: 6 Sep 1993





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

                               6 September 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.   DATABASE QUERY FACILITY.....................................5
 8.   SPECIAL DATABASE FIELDS.....................................5
      8.1.   NODE ADDRESSES.......................................5
      8.2.   NAME FIELDS..........................................5
      8.3.   KEY FIELD............................................6
 9.   UPDATE MESSAGES.............................................6
      9.1.   TO ADD OR UPDATE AN ENTRY............................7
      9.2.   TO DELETE AN ENTRY...................................7
      9.3.   TO ADD OR UPDATE A CONFERENCE RULES FILE.............8
             9.3.1. Rules File Attach.............................8
             9.3.2. Rules File in Message Text....................8
 10.  MESSAGE FORMATTING DETAILS..................................9
 11.  UPDATE MESSAGE FIELD DESCRIPTIONS...........................9
 12.  PUBLICATION.................................................14
 13.  ADVANCED TECHNICAL ISSUES...................................16
      13.1.  DATABASE IMPLEMENTATION..............................16
      13.2.  KEY GENERATION.......................................16













 Copyright (c) 1993 by Michael G. Fuchs



 EchoList - The EchoMail Conference List                                Page 2
 Technical Reference                                         as of: 6 Sep 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 provides a place for moderators
 to advertise their conferences to people who would like to participate and to
 those who route conference traffic.  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
 backbones, zones, networks or FidoNet.  It is an open, free directory of
 information on ANY EchoMail conference, anywhere.



 EchoList - The EchoMail Conference List                                Page 3
 Technical Reference                                         as of: 6 Sep 1993

 However, a couple of distribution backbones have implemented a requirement
 (which I heartily endorse) that any conference they carry must have a
 Moderator and description publicly 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.  If you use one of these organized distribution systems I refer you
 to their documents.

 For the purposes 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
 addressee name and node number must be exact in order to be picked-up by the
 software.

 Update messages are 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 must
 send an update periodically (even if there are no changes) in order to



 EchoList - The EchoMail Conference List                                Page 4
 Technical Reference                                         as of: 6 Sep 1993

 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 a hobby, so other time constraints will
 dictate how much can actually be accommodated in a given month and when 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 is: The symbolic area
 Tag name used by the conference, a Title (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 11.


 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
 tracked in the database, but are not reported as part of the EchoList.  They



 EchoList - The EchoMail Conference List                                Page 5
 Technical Reference                                         as of: 6 Sep 1993

 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.   DATABASE QUERY FACILITY

 The EchoList is only published once a month.  But you can query the database
 at any time by sending an ECHO QUERY message via NetMail or in one of several
 EchoMail conferences that are scanned for such messages.  For formatting and
 submission instructions for ECHO QUERY messages see ELQRY993.LZH.


 8.   SPECIAL DATABASE FIELDS

 8.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 (without
 commas, they're delimiters so change any commas to periods or something):

           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.

 8.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



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

 middle initial (if present) are put in the first name field.  Aren't you
 sorry you asked?

 8.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.

 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 to 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 lowest 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 to use the same Tag.
 The update program will allow inserting multiple entries for the same Tag if
 you manually specify unique Keys.

 The other 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 file 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.


 9.   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,



 EchoList - The EchoMail Conference List                                Page 7
 Technical Reference                                         as of: 6 Sep 1993

 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.

 The EchoList update processor is run after every NetMail call.  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.

 9.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 description 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.



 EchoList - The EchoMail Conference List                                Page 8
 Technical Reference                                         as of: 6 Sep 1993

 9.2.    TO DELETE AN ENTRY

 This also deletes its Rule File if it exists.

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

 In the body of the message:

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


 9.3.    TO ADD OR UPDATE A CONFERENCE RULES FILE

 9.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 only used for just
 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>
     ---

 9.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



 EchoList - The EchoMail Conference List                                Page 9
 Technical Reference                                         as of: 6 Sep 1993

 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.


 10.  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 in an update message 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 message, 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 at the end of the Moderator list already there.

 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.



 EchoList - The EchoMail Conference List                               Page 10
 Technical Reference                                         as of: 6 Sep 1993

 11.  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.

                   MINIMUM
 KEYWORD     *+    ABBREVIATION    ARGUMENTS
 ==============    =========================================================
 OPTION      *     OPTION [HOLD] [NOREP] [NONOT] [SHOWPAS]
                   This command line provides instructions for handling the
                   processing of your reply.  You don't need this line, but if
                   you use it you should probably make it the first line in
                   the message.  Specify one or more arguments separated by
                   spaces on the OPTION line.  Arguments:
                   HOLD - means to HOLD the reply message awaiting your poll.
                   NOREP - means do not generate any reply message.
                   NONOT - means do not generate public notify messages.
                   SHOWPAS - means show the password in the reply message.

 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.
                   [Text 30 chars]

 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 NAME AND ADDRESS CAN BE LISTED PER
                   MODERATOR 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>



 EchoList - The EchoMail Conference List                               Page 11
 Technical Reference                                         as of: 6 Sep 1993

                   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 description>
                   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 the 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,
 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 origination 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,



 EchoList - The EchoMail Conference List                               Page 12
 Technical Reference                                         as of: 6 Sep 1993

                   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
                   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



 EchoList - The EchoMail Conference List                               Page 13
 Technical Reference                                         as of: 6 Sep 1993

                   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.

 +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.


 12.  PUBLICATION

 The EchoList is published on or about the first of each month.  The monthly
 release is sent to Regional Software Distribution 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



 EchoList - The EchoMail Conference List                               Page 14
 Technical Reference                                         as of: 6 Sep 1993

 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 instructions for use of the EchoList Query facility are available as
 "ECHOQRY", which delivers the file ELQRYmyy.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.



 EchoList - The EchoMail Conference List                               Page 15
 Technical Reference                                         as of: 6 Sep 1993

 13.  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.

 13.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.  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.

 13.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.



 EchoList - The EchoMail Conference List                               Page 16
 Technical Reference                                         as of: 6 Sep 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.

