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 /NOSHow TITLe DESCription MODerator , PASSword , TOTalnodes VOLume / RESTrictions /SYSop /MOD-apvl /MEMber ORIGin GATEway SEENby PATH --- 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 ). 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