

 EchoList - The EchoMail Conference List                                Page 1
 Users Guide                                                as of: 21 Feb 1993

 PURPOSE

 This Users Guide is intended as a brief overview of the EchoList, and a
 shortcut description of how to submit updates to the database.  Probably 75%
 of you will not need to know anything more about the process than what you
 find here.

 The companion Technical Reference document goes into much more detail on the
 format of the update messages and on how the EchoList system itself works.
 Those of you with insomnia will want to take a look at it right away.

 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 one
 keyword and value per line.  If you're familiar with AREAFIX or RAID message
 formatting, this will give you no trouble.

 In order to keep the EchoList clear of out-of-date information and dead
 conferences, all entries expire six months after initially published.  You
 must send an update at least once every six months to maintain your EchoList
 entry.  Let me repeat: YOU maintain the EchoList entries--not me.  I just
 publish 'em.

 ADDITIONS AND UPDATES

 To add or update an EchoList entry, submit a NetMail message to "ECHOLIST" at
 1:1/201.  The message subject must be "MOD UPD".  The body of the message
 text has the data for 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.  I'll list the keywords and flags
 in a typical message followed by a brief description of each.  For a more
 detailed description refer to the Technical Reference.  The CAPITALIZED part
 of the keyword is the minimum abbreviation you can use.  The To-name,
 subject, keywords and passwords are NOT case sensitive.

 To add or update an EchoList Entry send a NetMail message:

 To:       ECHOLIST

 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                                Page 2
 Users Guide                                                as of: 21 Feb 1993

 At:       1:1/201
 Subject:  MODerator UPDate

 In the body of the message:

     TAGname       <symbolic area name> /NOSHow
     TITLe         <brief 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>
     SEENby        <node list>
     PATH          <node-pair list>
     ---

 The TAG is obviously the one-word symbolic name used in distributing the
 conference;  also called the AREA name or GROUP name.  If you are paranoid
 about unauthorized links to a privately distributed conference, you can
 follow the tagname with a space and /NOSHOW.  This will record the conference
 appropriately but not include the tagname in reports (it'll say <hidden>).

 TITLE should be a one-line title for the conference, preferably 70 chars or
 less, preferably starting with a word which will make finding it in a sorted
 list sensible (avoid starting with A, An, The, ...).

 DESCRIPTION allows for a longer description of the conference, and you can
 supply multiple DESC lines and they will be appended.  Don't bother trying
 fancy formatting.  All the lines are combined and word-wrapped into a single
 paragraph.

 Next to title, MODERATOR is one of the most important fields.  The EchoList
 definition of a Moderator is someone with authority over the internal
 operation of a conference, with the right to state the description and
 policies within it.  You MUST list at least one Moderator in order to have a
 valid EchoList entry.  You can list as many as you want.  Each Moderator line
 consists of a first and last name followed by their Node Address.  You only
 put ONE NAME AND ADDRESS PER LINE.  If you have more than one alias address,
 and you feel it's absolutely essential you advertise them, enter multiple
 MODERATOR lines with your name, but different addresses on each.  This is a
 good time to explain how the EchoList stores Node Addresses.

 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.  There's
 more detail on how defaults are handled in the Tech Ref.  The twist is that
 the EchoList allows use of the Domain field by itself to specify non-FidoNet

 Copyright (c) 1993 by Michael G. Fuchs

 EchoList - The EchoMail Conference List                                Page 3
 Users Guide                                                as of: 21 Feb 1993

 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.

 The PASSWORD field is not required.  If you assign one, you must use it in
 every change you make from then on, and it may protect your entry from
 modification by someone else.  There are two password fields.  The first is
 for the current password.  The second is for the new password to change it
 to, if you want to change it.

 TOTALNODES is for publishing a rough estimate of the number of systems
 participating in your conference.  It's optional.  If supplied, save the
 editorials--it's just a single integer number.

 VOLUME is for advertising a rough estimate of the volume of messages to be
 expected by those who link-in.  It's optional.  If specified it MUST be a
 single integer number followed by a slash followed by either MONTH, WEEK or
 DAY to identify the time period in which that number of messages flow.

 RESTRICTIONS is a shorthand reference to rules applied by the Moderator
 concerning admission to the conference.  /SYSOP means only Sysops are allowed
 to participate,  /MEMBER means you must be validated as a member of some
 organization in order to participate (eg: MENSA), and /MOD-APVL means you can
 not link in without specific approval of the Moderator.

 ORIGIN, DISTRIBUTION and GATEWAYS are just an organized set of 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, don't just say BACKBONE--there are
 lots of them.  Specifically say "Zone 1 Backbone" or "Zone-3 Backbone" or
 "EchoNet Backbone"...

 SEENBY lines let you document where your conference appears.  This is a total
 waste of space for backbone-type conferences.  Saying you're on a backbone in
 the DISTRIBUTION field above should be more than adequate.  If you use it for
 a privately distributed conference, list the node numbers the way you'd see
 them on an EchoMail message (except these can include Zone, Domain and
 Point).  Like EchoMail seen-by lines, if you leave off the Domain, Zone or
 Net, it'll be inherited from the previous seen-by node address.

 PATH lines let you document specific routing connections as pairs of
 connected node addresses.  If you want to use these, look at the Tech Ref for
 an explanation.

 That's a brief look.  There's a lot more detail in the Technical Reference.
 And I haven't even discussed the KEY or OPTIONS lines.  And there are message
 formats for deleting EchoList entries and for submitting Conference Rules
 files for inclusion in a combined archive of rules.  You probably should,
 eventually, look over the Tech Ref.  Enjoy.

 Copyright (c) 1993 by Michael G. Fuchs
