Volume 5, Number 6 8 February 1988 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief Dale Lovell Editor Emeritus: Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Contributing Editors: Al Arango FidoNews is published weekly by the International FidoNet Association as its official newsletter. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. Copyright 1987 by the International FidoNet Association. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact IFNA at (314) 576-4067. IFNA may also be contacted at PO Box 41143, St. Louis, MO 63141. The contents of the articles contained here are not our responsibility, nor do we necessarily agree with them. Everything here is subject to debate. We publish EVERYTHING received. Table of Contents 1. ARTICLES ................................................. 1 IFNA Board January Voting Summary ........................ 1 ICONS Can help you communicate ........................... 4 NaughtNet: Another New Network ........................... 6 POLICY4 Draft Proposal from Thom Henderson ............... 11 2. COLUMNS .................................................. 26 The Apple Core ........................................... 26 3. WANTED ................................................... 29 4. NOTICES .................................................. 31 The Interrupt Stack ...................................... 31 Latest Software Versions ................................. 31 FidoNews 5-06 Page 1 8 Feb 1988 ================================================================= ARTICLES ================================================================= Bob Swift The Power Station (1:140/24) IFNA Board Member-At-Large IFNA Board of Directors Business for January 1988 ------------------------------------------------- There were a total of 7 items voted on by the Board. Results are as listed. Votes are shown as AYE-NAY-HOLD-ABSTAIN. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOCKET NUMBER: BOD-122087.01 - PASSED by vote of 13-0-0-0 Resolution: Allowable ballots will contain either YEA, NAY, ABSTAIN, or HOLD. Actual text of resolution: Be it resolved that the following points be instituted relative to the voting process in the Board of Directors: A. For each action to be voted upon there shall be four possible responses: 1. YEA - Election of this option signifies support for the motion in question. 2. NAY - Election of this option signifies rejection of the motion in question. 3. ABSTAIN - Election of this option makes the statement that the voter either has no choice or chooses to not decide for whatever reason. 4. HOLD - Election of this option signifies a request that the due date of the motion in question automatically be held over to the following vote date. B. In order for a motion appearing on the floor during an electronic session to be passed or rejected there must be received a number of such votes from a majority of the total of all members of the Board eligible to vote, except that such total shall be reduced by the number of ABSTAIN votes cast. When a motion fails to receive such a majority of YEA or NAY votes, it shall automatically be held over to the next voting period. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOCKET NUMBER: BOD-122087.02 - PASSED by vote of 13-0-0-0 Resolution: Maintain current dues structure through 1988. Text of actual resolution: It is hereby resolved that the Board FidoNews 5-06 Page 2 8 Feb 1988 of Directors maintain the current IFNA membership dues structure through 1988. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOCKET NUMBER: BOD-121987.02 - HELD by vote of 8-1-7-0 (Will re-appear on the ballot for 88/01/24) Resolution: The Vice President - Technical Coordinator for IFNA be given sole responsibility for the contents and format of the weekly nodelist. Text of actual resolution: It is hereby resolved that the weekly nodelist contents and format be under the control of the Vice President - Technical Coordinator, with changes being voted on by the full Board of Directors. The FidoNet Technical Standards Committee is available to assist the VP-TC if necessary. In the past, the format and content has been covered by document FSC002, this resolution passes control of the document to the VP-TC, and gives the full Board of Directors the power to accept or deny proposed changes. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOCKET NUMBER: BOD-122087.03 - PASSED by vote of 10-3-3-0 Resolution: Declaration of Ben Baker as an Honorary Member Text of resolution: It is hereby resolved that, in appreciation for the many past services rendered to IFNA and to FidoNet in general, the Board of Directors of the International FidoNet Association declare Ben Baker as its first Honorary Member. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOCKET NUMBER: BOD-123087.01 - PASSED by vote of 15-4-1-0 Resolution: IFNA has no desire to effect a policy statement to control any echomail areas that are not specifically IFNA echos. Text of actual resolution: IFNA believes that one of the benefits of an electronic mail system is the free-flow of information in all forms, including electronic conferencing (ie echomail). IFNA also has no desire to regulate, control or censor any conferencing systems used in the FidoNet electronic mail system. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOCKET NUMBER: BOD-122287.01 - HELD by vote of 9-7-2-1 (Will be held until the BoD Meeting of 88/02/20) Resolution: Bring discussion of Policy4 back from the Executive Committee to the full Board of Directors. Text of actual resolution: Motion to bring back for consideration by the full board the agenda item IIA Consideration of adopting FidoNews 5-06 Page 3 8 Feb 1988 revised Policy4. As was sent to executive committee at the last meeting of the whole on August 23, 1987. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOCKET NUMBER: BOD-121987.02 - PASSED by vote of 12-5-1-0 Resolution: The Vice President - Technical Coordinator for IFNA be given sole responsibility for the contents and format of the weekly nodelist. Text of actual resolution: It is hereby resolved that the weekly nodelist contents and format be under the control of the Vice President - Technical Coordinator, with changes being voted on by the full Board of Directors. The FidoNet Technical Standards Committee is available to assist the VP-TC if necessary. In the past, the format and content has been covered by document FSC002, this resolution passes control of the document to the VP-TC, and gives the full Board of Directors the power to accept or deny proposed changes. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOCKET NUMBER: BOD-011088.01 - PASSED by vote of ?-0-1-0 Resolution: That a summary document of IFNA Board of Directors Operating Policy be maintained and be publicly accessible. Text of actual resolution: It is hereby resolved that a summary document of Board of Directors Operating Policy be maintained and be publicly accessible for the membership (or potential members). The purpose of this document is to maintain a record of items decided by the Board of Directors which affect the operation of the Board and are not covered in currently existing documents such as the Articles of Association and FidoNet Policy & Procedures document. It is also designed to provide a guideline concerning the operation of the Board. It is further resolved that summary documents of Board of Directors activity and voting results be maintained and be publicly accessible for the membership (or potential members). The purpose of this document is to help allow the membership to be fully informed of the actions of the Board of Directors and to provide historical documentation of voting results. ----------------------------------------------------------------- FidoNews 5-06 Page 4 8 Feb 1988 ICONS Help you get the thought out! Are you afraid that you come across differently electronically than you do on paper, over the phone or in person? The answer may be icons! The icons listed below can help you express those no-verbal signals that are all but impossible to express over the net. Any additions to this list would be greatly appreciated! Send all comments and additions to David Melnik at 107/233. :-) Smiling :-( Frowning '-) Wink ;-) Sardonic incredulity %-) Drunk with laughter :-" Pursing lips :-O Wow! :-| Grim := | Baboon :-v Speaking :-V Shouting :-W Speak with forked tongue :-r Sticking tongue out :-* Oops! (covering mouth with hand) :-T Keeping a straight face (tight-lipped) :-D Said with a smile :-x Kiss :-c Real unhappy :-C Just totally unbelieving! (Jaw dropped) :-B Drooling :-, Smirk :-|| Anger FidoNews 5-06 Page 5 8 Feb 1988 :-$ Uncertainty :-# Mouth zipped :-& Tangled up tongue :-@ Swearing ----------------------------------------------------------------- FidoNews 5-06 Page 6 8 Feb 1988 NaughtNet: Another New Network Aaron Priven FidoNet (1:125/1154.0) NaughtNet (0:000/0000.0) "I've had nothing yet," Alice replied in an offended tone: "so I can't take more." That quote (from Lewis Carroll if you saw a movie of _Alice in Wonderland_ so bad that it didn't include that line) expresses the mood of the moment. Or to put it another way: I'm Nobody! Who are you? Are you -- Nobody -- too? Then there's a pair of us! Don't tell! they'd advertise -- you know! How dreary -- to be -- Somebody! How public -- like a Frog -- To tell one's name -- the livelong June -- To an admiring Bog! -- Emily Dickinson (Only the table of contents and the overview are presented here. Other sections are available by request.) N A U G H T N E T Policy and Procedures Guide Version 0 00 Zeroember 1900 0 Overview ................................................ 0 0.0 Definitions ......................................... 0 0.0 The Levels of NaughtNet ............................. 0 0 Sysop Procedures ........................................ 0 0.0 How to get a node number ............................ 0 0.0 If you are going down ............................... 0 0.0 How to join a network ............................... 0 0.0 How to form a network ............................... 0 0 Network Coordinator Procedures .......................... 0 0.0 Routing inbound mail ................................ 0 0.0 Assigning node numbers .............................. 0 0.0 Maintaining the node list ........................... 0 0.0 Passing along node lists and NaughtNews ............. 0 0.0 Forwarding newsletter submissions ................... 0 0 Regional Coordinator Procedures ......................... 00 0.0 Assigning node numbers .............................. 00 FidoNews 5-06 Page 7 8 Feb 1988 0.0 Encouraging the formation and growth of networks .... 00 0.0 Assigning network numbers ........................... 00 0.0 Maintaining the node list ........................... 00 0.0 Overseeing network operations ....................... 00 0.0 Passing along node lists and NaughtNews ............. 00 0.0 Forwarding newsletter submissions ................... 00 0 International Coordinator Procedures .................... 00 0 Resolution of Disputes .................................. 00 0.0 Problems with another node .......................... 00 0.0 Problems with a Network Coordinator ................. 00 0.0 Problems with a Regional Coordinator ................ 00 0.0 Problems with the International Coordinator ......... 00 0.0 Appeals to the International Coordinator ............ 00 0.0 Case Histories ...................................... 00 0.0.0 The Case of the Crooked Node .................. 00 0.0.0 The Case of the Hacker Mailer ................. 00 0.0.0 The Case of the Network Mutiny ................ 00 0.0.0 The Case of the Bothered Barker ............... 00 0.0.0 The Case of the Busy Beaver ................... 00 0.0.0 The Mark of the Devil ......................... 00 0.0.0 The Case of the Sysop Twit .................... 00 0.0.0 The Case of the EchoMail Junkey ................ 00 0.0.0 The Case of the Bouncing Board ................ 00 Chapter 0 OVERVIEW NaughtNet is a new amateur e-mail network. It is an offspring of the world-famous Fidonet network. The founders of Naughtnet believe that Naughtnet addresses all the problems that past alternate networks were formed to address, and in fact will address any future problems that Fidonet nodes have with IFNA and the Fidonet heirarchy. Such problems, as we see them, include: o Entirely too much interest shown by certain people in the functioning of FidoNet, disturbing the conformity of a well- ordered network; o Communication is all too possible, with more and more nodes every week, and echomail making even users able to talk with those in far-away cities and countries (this being alien to the initial spirit of FidoNet, where only sysops could afford to send mail); o Expansion of BBS and netmail software possibilites (including Opus and BinkleyTerm), makes it impossible for the old-time Fido monopoly to continue; o A tremendous upsurge in the number of people willing to volunteer for Net, Region, and Zone Coordinators, as well as chairmen and members of committees, suggests that the sysops at large want a voice in the operation of Fidonet; this FidoNews 5-06 Page 8 8 Feb 1988 would be dangerous to the order of the net, and thus should be eliminated. We feel that these are the reasons that IFNA has proven a complete failure and both it and FidoNet should be scrapped in favor of NaughtNet. 0.0 Definitions NaughtNet nodes are grouped on several levels. These are as follows: o Nodes; A node is a single Naughtnet address. This is the smallest recognized unit of NaughtNet, and the only one anybody likes. o Networks; A network is a collection of nodes, usually in a relatively small geographic area. Networks coordinate their mail activity to decrease cost and increase mail throughput. In NaughtNet it is felt that networks are one of the prime causes of disorder; nodes are wont to complain when they don't get everything they want from their network hosts. Therefore, networks have been eliminated in Naughtnet. We feel this will lessen both the number of complaints and the number of people who want a voice in discussions. o Regions; A region is a well defined geographic area containing nodes. Of course, the nodes can't be in networks, but that makes the Regional Coordinator's job easier. Here are the regions that make up Naughtnet: Earth -- 00 Moon -- 00 Pluto and Charon -- 00 Jupiter -- 00 Callisto -- 00 Other Jovian moons -- 00 Europa -- 00 Ganymede -- 00 Jovian rings -- 00 Mars -- 00 Phobos -- 00 Saturnian rings -- 00 Mercury -- 00 Deimos -- 00 Uranus -- 00 Sun -- 00 Venus -- 00 Uranian moons -- 00 Saturn -- 00 Titan -- 00 Other Saturnian moons -- 00 Io -- 00 Neptune -- 00 Triton and Nereid -- 00 o Zones; A zone is a large geographic area containing many regions, and covering one or more astronomical districts. These are the zones in NaughtNet: Solar System -- 0 Rest of Milky Way -- 0 Andromeda Galaxy -- 0 Rest of Local Group -- 0 Rest of Universe -- 0 o NaughtNet; This indicates nothing at all, as should be self- evident. 0.0 The Levels of NaughtNet FidoNews 5-06 Page 9 8 Feb 1988 NaughtNet has no real levels, because it has weak legs and can't climb stairs, and is claustrophobic and can't ride elevators. But the following will suffice: o The International Coordinator; The International Coordinator can compile all of the node lists from all of the regions and creates the master node list, which could then be distributed over NaughtNet if the International Coordinator really wanted to for some reason. The following is a sample nodelist (with widths wrapped around): Region,00,Around_Nowhere,Nowhere_Much,Nobody,-Unpublished- ,000,#00: ,00,Zilch,Blank,Null,-Unpublished-,000,#00: Down,00,Naught,Absence,Tabula_Rasa,-Unpublished-,000,#00: ,00,Nihility,Cipher,Not_Me_Dude!,-Unpublished-,000,#00: ,00,Insubstantiality,Oblivion,Nominis_Umbra,-Unpublished- ,000,#00: o The Zone Coordinator; In some cases the International Coordinator will appoint a Zone Coordinator to oversee FidoNet operations in a given zone. There are no duties or responsibilities of Zone Coordinators, so usually there aren't any. In fact, the appointment of a Zone Coordinator is grounds for removal of any particular IC, so it's not done a lot; it is however an easy way to resign. o The Regional Coordinator; The Regional Coordinator maintains the list of nodes in his region. Usually any given RC won't bother, since all the nodes in NaughtNet are unpublished, but sometimes he gets bored. o The Network Coordinator; Anyone claiming to be a Network Coordinator is summarily shot in regions where no other legal jurisdiction exists. In other regions that person will simply be forced to do thirty pushups, unless that person is (as well as being part of NaughtNet) an ice-cream salesman, in which case he will have to eat thirty Frozen Yogurt Push- Ups . o The Network Routing Hub; Network Routing Hubs exist only in three-tiered networks. Since in NaughtNet there are no networks, there are obviously no Network Routing Hubs. Anyone claming to be a Network Routing Hub will suffer the same fate as his Network Coordinator, or if there is no Network Coordinator, will be placed in the nearest planetary mental institution. o The system operator (sysop); The sysop formulates his own policy for running his board and dealing with his users, so that will not be discussed in this document. However, the sysop must also do everything the IC wants and not argue about it, even if the sysop feels it's none of the IC's business. FidoNews 5-06 Page 10 8 Feb 1988 o The user; Policy and procedures for the individual user on any given board is determined by that user. Sysops can't do anything about it, that's just tough. These levels act to put everybody under the thumb of whoever takes charge; this is considered desireable because the author of this document is in charge. For example, a Regional Coordinator is solely responsible to the International Coordinator for anything that may or may not happen in his region. From the point of view of the International Coordinator, the Regional Coordinator is totally and completely responsible for the smooth operation of his region. Likewise, from the point of view of anybody else, the International Coordinator is just as much an interfering jerk as he is to the Regional Coordinator. If a person at any level is unable for any reason to properly perform his duties, then he will suffer the fate of a Net Coordinator. That's the breaks. ----------------------------------------------------------------- FidoNews 5-06 Page 11 8 Feb 1988 Ed note: This is one of several proposals for the new POLICY4 document which is being published for review by FidoNet Sysops and the subcommittee of Membership Services. It was prepared by Thom Henderson prior to his departure into AlterNet. Publication of these proposals will take place in FidoNews weekly until they have all been seen. Discussion regarding the new POLICY4 is taking place in the POLICY4 EchoMail conference. --------------------------------------------------------------- F I D O N E T Policy and Procedures Guide Version 4 * * * P R O P O S A L * * * 1 Overview 1.1 The Levels of FidoNet 1.2 Coordinators 2 Sysop Procedures 2.1 How to get a node number 2.2 If you are going down 2.3 How to form a network 3 Coordinator Procedures 3.1 Administrative tasks 3.1.1 Maintaining the node list 3.1.2 Assigning node numbers 3.1.3 Problem resolution 3.1.4 Formulating local policy 3.2 Node list distribution 3.3 Newsletter distribution 3.4 Network mail distribution 3.5 Anything else 3.6 Specific coordinator procedures 3.6.1 International Coordinator procedures 3.6.2 Zone Coordinator procedures 3.6.3 Regional Coordinator procedures 3.6.4 Network Coordinator procedures 3.6.5 Hub Coordinator procedures 4 Resolution of Disputes 4.1 Case Histories 4.1.1 The Case of the Crooked Node 4.1.2 The Case of the Hacker Mailer 4.1.3 The Case of the Network Mutiny 4.1.4 The Case of the Bothered Barker 4.1.5 The Case of the Busy Beaver 4.1.6 The Case of the Sysop Twit 4.1.7 The Case of the EchoMail Junkey key key 4.1.8 The Case of the Bouncing Board Chapter 1 FidoNews 5-06 Page 12 8 Feb 1988 OVERVIEW FidoNet is an amateur electronic mail system. As such, all of its participants and operators are non-paid volunteers. From its early beginnings as a few friends swapping messages back and forth, it has now grown to (August 1987) over 2000 different systems on four continents. FidoNet is large enough that it would quickly fall apart of its own weight unless some sort of structure and control were imposed on it. Multinet operation provides the structure. Decentralized management provides the control. This document is an attempt to describe the procedures which have been developed to manage the network. 1.1 The Levels of FidoNet FidoNet nodes are grouped on several levels. These are as follows: o FidoNet; This indicates the entire public amateur mail network, as administered by the International FidoNet Association, and as defined by the weekly node list. o Zones; A zone is a large geographic area containing many regions, and covering one or more countries and/or continents. o Regions; A region is a well defined geographic area containing nodes which may or may not be combined into networks. A typical region will contain many nodes in networks, and a few independent nodes, which are not a part of any network. o Networks; A network is a collection of nodes, usually in a relatively small geographic area. Networks coordinate their mail activity to decrease cost and increase mail throughput. o Hubs; A hub is a subdivision of a network that assists in network management by routing mail to, and by coordinating for, a collection of nodes in that network. In general only the larger networks will have hubs. o Nodes; A node is a single FidoNet address, and is the smallest recognized unit of FidoNet. o Points; A point is a node on a private network which is accessible through a node on FidoNet. 1.2 Coordinators Each subdivision at each level is managed by a coordinator. A coordinator is a person who coordinates the technical aspects of network mail. This entails both administrative and technical tasks, which will be described later. The following levels of coordinators are currently recognized: FidoNews 5-06 Page 13 8 Feb 1988 o The International Coordinator; The International Coordinator compiles all of the node lists from all of the regions and creates the master node list, which is then distributed over FidoNet. o The Zone Coordinator; A Zone Coordinator maintains the list of administrative nodes in his zone and accepts node lists from the Regional Coordinators in his zone. He compiles these lists to create a zone node list, which he then sends to the International Coordinator for inclusion in the master node list. A Zone Coordinator is also responsible for overseeing any zone gateways in his zone. o The Regional Coordinator; A Regional Coordinator maintains the list of independent nodes in his region and accepts node lists from the Network Coordinators in his region. He compiles these lists to create a regional node list for his region, which he then sends to his Zone Coordinator. A Regional Coordinator does not perform routing services for any nodes in his region. o The Network Coordinator; A Network Coordinator maintains the list of any nodes in his network that are not served by a hub and accepts node lists from the Hub Coordinators in his network. He compiles these lists to create a network node list for his network, which he then sends to his Regional Coordinator. A Network Coordinator is also responsible for forwarding any mail addressed to nodes in his network. o The Hub Coordinator; A Hub Coordinator maintains the list of nodes in his hub and sends it to his Network Coordinator. A Hub Coordinator is also responsible for forwarding any mail addressed to nodes in his hub. o The Point Coordinator; Any node in FidoNet can act as a gateway to a point network. The Sysop (or system operator) of that node then acts as the coordinator for his point network. o The Sysop; A Sysop formulates his own policy for running his board and dealing with his users, so that will not be discussed in this document. However, a Sysop must also mesh with the rest of the FidoNet system if he is to send and receive mail, and that will be discussed here. These levels act to distribute the administration and control of FidoNet to the lowest possible level, while still allowing for coordinated action over the entire mail system. Administration is made possible by operating in a strict top-down manner. That is, a coordinator at any given level is responsible to the coordinator immediately above him, and responsible for everyone below him. For example, a Regional Coordinator is solely responsible to his Zone Coordinator for anything that may or may not happen in his region. From the point of view of the Zone Coordinator, the Regional Coordinator is totally and completely responsible for the smooth operation of his region. Likewise, from the point of FidoNews 5-06 Page 14 8 Feb 1988 view of the Regional Coordinator, the Network Coordinators are totally and completely responsible for the smooth operation of their networks. If a coordinator at any level above sysop is unable for any reason to properly perform his duties, he can be replaced by his coordinator at the next level up. For example, if a Regional Coordinator is failing to perform his duties, then his Zone Coordinator can appoint a new Regional Coordinator to replace him. The primary responsibility of any coordinator is technical management of network operations. Management decisions should be made strictly on technical grounds. Chapter 1 SYSOP PROCEDURES A sysop of an individual node can pretty much do as he pleases, as long as he observes the mail events, is not excessively annoying to other nodes on FidoNet, and does not promote the distribution of pirated copyrighted software. National Mail Hour is the heart of FidoNet, as this is when network mail is passed between systems. Any system which wishes to be a part of FidoNet must be able to receive mail at this time. A system which is a member of a network may also be required to observe additional mail events, as defined by his Network Coordinator. Failure to observe the proper mail events is sufficient grounds for any node to be dropped from FidoNet without notice (since notice is generally given by FidoNet mail). Network mail systems generally operate unattended and place calls at odd hours of the night. If a system tries to call an incorrect or out of date number, it could cause some poor citizen's phone to ring in the wee hours of the morning, much to the annoyance of innocent bystanders and civil authorities. For this reason, a sysop who sends mail is obligated to obtain and use the most recent edition of the node list as is practical. A system which has been dropped from the network is said to be excommunicated (i.e. unable to communicate). A node which has been excommunicated may or may not be listed for a time in the "dog house", which is included in the comments at the end of the node list. If you find that you have been excommunicated without warning, then that means that your coordinator was unable to contact you. You should rectify the problem and report back. The exact timing of National Mail Hour is set for each zone by the Zone Coordinator. In the United States, National Mail Hour is observed from 0900 to 1000 GMT every day, weekends included. In each of the United States time zones, this would be as follows: FidoNews 5-06 Page 15 8 Feb 1988 Eastern Standard Time 4 AM to 5 AM Central Standard Time 3 AM to 4 AM Mountain Standard Time 2 AM to 3 AM Pacific Standard Time 1 AM to 2 AM Hawaii Standard Time 11 PM to Midnight FidoNet does not observe daylight savings time. In areas which observe daylight savings time the FidoNet mail schedules must be adjusted in the same direction as the clock change. Alternatively, you can simply leave your system on standard time. 2.1 How to get a node number You must first obtain a current node list so that you can send mail. You do not need a node number to send mail, but you must have one in order for others to send mail to you. The first step in obtaining a current node list is to locate a FidoNet bulletin board. No help there; you're on your own. Most bulletin board lists include at least a few FidoNet systems, and usually identify them as such, so this shouldn't be too hard. If the sysop of any FidoNet system does not have a node list available for downloading, then he can probably tell you where to get one. Once you have a node list, you must determine which coordinator to apply to. The coordinator of any network or region is always node zero of that network or region. A Hub Coordinator will always be indicated in the node list by a "HUB" prefix. You should apply to the lowest-level coordinator that covers your area. For example, if you are located within the hub of a network, then you would apply to the Hub Coordinator. If there is no network that covers your area, then you would apply to the Regional Coordinator for your region. Your application for a node number must be sent to the coordinator by FidoNet mail, and must include at least the following: 1) Your name. 2) The name of your system. 3) The city and state where your system is located. 4) The phone number to be used when calling your system. 5) Your hours of operation. 6)The maximum baud rate you can support. Your coordinator may want additional information. If so, he will contact you. Please allow at least two to three weeks for a node number request to be processed. 2.2 If you are going down FidoNews 5-06 Page 16 8 Feb 1988 If your node will be down for an extended period (more than a day or two), then you should inform your coordinator as soon as possible. If you do not do this, then other systems will still try to reach you while you are down, much to the annoyance of everyone. Do not under any circumstances put an answering machine or similar device on your phone line while you are down. If you do, then calling systems will get the machine repeatedly, racking up large phone bills, which is very annoying. See the section on Resolution of Disputes for details on what happens to annoying people. If your system goes down without warning, then you may be placed in the dog house, or even removed from the node list completely. If you will be leaving your system unattended for an extended period of time (such as while you are on vacation), you should notify your coordinator. Systems do have a tendency to "crash" now and then, so you will probably want your coordinator to know that it is a temporary condition if it happens while you are away. 2.3 How to form a network If there are several nodes in your area, but no network, then you may wish to form your own. You may also be requested to form a network by your Regional Coordinator. Your first step is to contact the other sysops in your area. You must decide which nodes will comprise the network, and which of those nodes is going to be the Network Coordinator. Your next step is to inform your Regional Coordinator. You must send him a FidoNet message with the following information: 1) The region number(s), or network number(s) if a network is splitting up, that are affected by the formation of your network. The Regional Coordinator will inform the coordinators of any affected networks that a new network is in formation. 2) The name that you wish to call your network. Please try to select a name that relates to your grouping. For example, SoCalNet for nodes in the Southern California Area and MassNet for Massachusettes Area. Remember if you call yourself DOGNET it doesn't help others know what area of the country (or even what country) your group is in. 3) A copy of the proposed network's nodelist. The nodelist file should be named Frrr-nnn.NET where rrr is the proposed host's current region or network number and nnn is his current node number. For example, if the proposed host is currently listed as node 5 in region 13, then you would name the file F013-005.NET. This file should be sent attached to the message of Application for a Network Number. SAMPLE FORMAT OF A Frrr-nnn.NET FILE (Ed note: Sample of St. Louis format NODELIST.BBS goes here.) FidoNews 5-06 Page 17 8 Feb 1988 Granting of a network number is not automatic. Your Regional Coordinator will review your application and inform you of his decision. Do not send a network number request to the International Coordinator. All network number requests must be processed by the Regional Coordinator. Chapter 3 COORDINATOR PROCEDURES This chapter describes the procedures followed by all coordinators at all levels. Later we will go into more detail on those procedures which are specific to any given type of coordinator. All coordinators have four primary duties. In order of decreasing importance, they are: 1) Administrative tasks. 2) Node list distribution. 3) Newsletter distribution. 4) Network mail distribution. At first glance it would seem that network mail distribution should be the highest priority, since after all that's why we're running a network in the first place. But the first three priorities are needed to ensure smooth operation of the network, and hence must have a higher priority. 3.1 Administrative tasks First and foremost, every coordinator is also the sysop of his own node. It must be possible for others to reach you by network mail. So in addition to the other tasks of a coordinator, you must also observe all of the requirements for being a node. 3.1.1 Maintaining the node list A coordinator at any level must maintain his portion of the node list. Almost any coordinator will have some nodes in his node list which are not a part of any subgroup. For example, a Zone Coordinator must maintain a list of administrative nodes for his zone, and a Regional Coordinator must maintain a list of independent nodes in his region. A Hub Coordinator (or the Network Coordinator in a network without hubs) must maintain the list of all nodes in his area. A coordinator is responsible for seeing to it that his portion of the node list is kept reasonably accurate. You should attempt to implement name changes, phone number changes, and so FidoNews 5-06 Page 18 8 Feb 1988 forth in this node list as soon as possible. You should also check from time to time to ensure that all of the listed nodes are in fact capable of accepting network mail. How best to accomplish this is left to your discretion. If a node turns out to be "off the air" with no prior warning given to you, then you can either mark the node as down, place it in the dog house, or remove it from the node list completely, at your own discretion. 3.1.2 Assigning node numbers You may assign node numbers to new nodes in your list, but keep in mind the following: 1) It is your responsibility to ensure that the node number you assign is unique within that region or network. 2) You should try to avoid assigning node numbers when an existing subdivision of your area already covers the location of the new node. For example, a Regional Coordinator should try to avoid assigning independent nodes in a city that has its own network. You may also change the numbers of existing nodes in your area, though you should check with the respective nodes before doing so. You should not under any circumstances assign a node number to any system until you have received a formal request from that system by FidoNet mail. This will ensure that the system is at least minimally operational. The strict maintenance of this policy has been one of the great strengths of FidoNet. It is also recommended, though not required, that you call a board which is applying for a node number before assigning it a node number. You should use network mail to inform a new node of his node number, as this helps to insure that he is capable of receiving network mail. 3.1.3 Problem resolution From time to time you may be called on to resolve a problem in your area. This could be a technical problem relating to the four primary duties of a coordinator, or it could be related to annoying behaviour on the part of someone in your area. If the problem is caused by a node or a coordinator immediately under you, then it is your responsibility to resolve the problem in whatever manner you deem fit. If the problem is in a subdivision of your area, then you should first refer it to the appropriate coordinator. If that coordinator does not resolve the problem satisfactorily, then you can appoint a replacement. FidoNews 5-06 Page 19 8 Feb 1988 3.1.4 Formulating local policy It is your responsibility to formulate any local policies which are required for the smooth operation of your assigned area. Any policies you establish must not conflict with any policies established by a coordinator above you or with this policy document. 3.2 Node list distribution The node list is posted weekly on Saturday, along with a "difference file" giving the changes for the week. It is your responsibility to obtain the difference file from your coordinator every week and to distribute it to the coordinators below you. The method of distribution is left to your discretion. It is also desirable that you make it available for downloading by the general user, but this is not required. 3.3 Newsletter distribution The newsletter, called FidoNews, is published weekly on Monday and is distributed as an archive named FNEWSvnn.ARC, where "v" is the volume number and "nn" is the issue number. It is your responsibility to obtain this archive from your coordinator every week and to distribute it to the coordinators below you. The method of distribution is left to your discretion. It is also desirable that you make it available for downloading by the general user in both archived an unarchived form, but this is not required. 3.4 Network mail distribution It is your responsibility to ensure that network mail in your area is operating in an acceptable manner. Exactly what this involves will depend on what level you are at, and will be discussed in more detail below. 3.5 Anything else You should encourage sysops and users in your region to contribute to FidoNews. If you receive any submissions, you should forward them to the FidoNews publisher. Think of yourself as being a regional bureau chief on the FidoNews editorial staff. FidoNews and the node list are the glue that holds us together. Without them, we cease to be a community, and become just another random collection of bulletin boards. 3.6 Specific coordinator procedures The above outlines the procedures which are followed by all coordinators. We will now discuss additional procedures followed by specific types of coordinators. 3.6.1 International Coordinator procedures FidoNews 5-06 Page 20 8 Feb 1988 The International Coordinator is appointed by the Board of Directors of the International FidoNet Association, Inc. The Board of Directors can appoint a replacement for the International Coordinator at any time. The International Coordinator is responsible for the weekly creation of the master node list, and the creation of a weekly difference file listing node list changes. This difference file is to be distributed to the various Zone Coordinators on Saturday morning. The International Coordinator is responsible for allocating zones, assigning zone numbers, and for appointing the Zone Coordinator for each zone. 3.6.2 Zone Coordinator procedures A Zone Coordinator is responsible for dividing his zone into regions, assigning region numbers, and for appointing the Regional Coordinator for each region. A Zone Coordinator also assigns a pool of numbers to each Regional Coordinator for use in assigning network numbers. A Zone Coordinator is responsible for locating nodes willing to act as zone gates for passing mail between his zone and the other zones, if at all possible. A Zone Coordinator should not appoint any node as a zone gate unless the sysop of that node is willing and able to provide reasonably reliable interzone mail. Zone gates are highly desirable, but if provided they must be reasonably reliable. A Zone Coordinator maintains the list of administrative nodes within his zone. The administrative nodes will always have a region number the same as the zone number. For example, the administrative nodes for Zone 3 will always be in Region 3. A Zone Coordinator may use administrative node addresses for whatever he likes, except that any node number which is the same as another zone number is reserved for the zone gate to that zone. For example, in Zone 3 the network address "3/2" is reserved for use by the zone gate that passes mail from Zone 3 to Zone 2. A Zone Coordinator may not assign a region number that is the same as any other zone number. This is because administrative regions are, by definition, present in all zones. 3.6.3 Regional Coordinator procedures A Regional Coordinator is responsible for approving new networks, assigning network numbers, and for appointing a Network Coordinator for each network. Each Regional Coordinator will be assigned a pool of numbers to use when assigning network numbers. A Regional Coordinator should never assign a network number outside of this pool, and FidoNews 5-06 Page 21 8 Feb 1988 should never assign the same number to more than one network. If a Regional Coordinator assigns all of the numbers in his pool, he should apply to his Zone Coordinator for additional numbers. A Regional Coordinator should try to avoid the needless proliferation of networks. Networks should not be allocated on any basis other than technical and practical considerations relating to network mail operations. For example, persons wishing to establish networks on the basis of special interests or for company mail should be encouraged to investigate the alternatives, such as echomail conferences and point networks. A Regional Coordinator is responsible for maintaining the list of independent nodes within his region. This will consist primarily of those nodes which are not within the coverage area of any network. There are, however, certain cases where a node should not be a member of a network, such as a commercial system with a large volume of traffic which would clog the network. The resolution of such special cases is left to your own discretion. If several independent nodes in a region are in a "clump", then the Regional Coordinator should encourage or require them to form a network. Refer to the sysop procedure on forming a network for more details. Note that this does not mean that a Regional Coordinator should encourage the formation of trivial networks. Obviously, one node does not make a network. The exact number of nodes required for an effective network must be judged according to the circumstances of the situation, and is left to the discretion of the Regional Coordinator. It is the responsibility of a Regional Coordinator to ensure that the networks within his region are operating in an acceptible manner. This does not mean that he is required to operate those networks; that is the responsibility of the Network Coordinators. It means that he is responsible for seeing to it that the Network Coordinators within his region are acting responsibly. A Regional Coordinator is obligated to maintain direct and reasonably frequent contact with the networks in his region. The exact method of accomplishing this is left to the discretion of the Regional Coordinator. 3.6.4 Network Coordinator procedures A Network Coordinator is responsible for assigning node numbers to any nodes within his network which are not managed by a Hub Coordinator. A Network Coordinator is also responsible for allocating any hubs within his network and for appointing a Hub Coordinator for each hub. If a Network Coordinator assigns any Hub Coordinators, then he also assigns a pool of numbers to each Hub Coordinator for use in assigning node numbers. FidoNews 5-06 Page 22 8 Feb 1988 It is the responsibility of a Network Coordinator to receive all inbound mail for nodes in his network and to forward it to its recipients. How to accomplish this is left to the discretion of the Network Coordinator. However, there are a few exceptions: 1) Once in awhile a node will try to make a "bombing run" (sending one message to a great many nodes). Bombing runs are considered to be annoying, and may be dealt with accordingly. 2) Occasionally a user will appear who receives a great deal of traffic. If a single node is receiving enough mail to interfere with mail delivery to the other nodes in his network, then his Network Coordinator can refer him to his Regional Coordinator for reassignment as an independent node. 3) The most common source of routing overload is echomail. Echomail is a nice invention, and offers great benefits, but it cannot be allowed to degrade the ability of FidoNet to handle normal message traffic. If a node in a network is routing large volumes of echomail, the sysop can be asked to either limit the amount of echomail, or even to stop routing his echomail completely. The design of echomail is such that it is a simple matter to do either of these. A Network Coordinator is responsible for assigning any additional mail events which may be required for operation of his network. Any node in a network may be excommunicated for failing to observe these additional mail events. A Network Coordinator may appoint a node as the outbound gateway for his network if he so desires and if one can be found. In no case should a node be appointed as an outbound gateway unless the sysop of that node is willing and able to provide reasonably reliable service. Note that a Network Coordinator is not required to appoint an outbound gateway. If a Network Coordinator chooses to appoint an outbound gateway, then it is left to the Network Coordinator to establish any rules, policies, and procedures relating to its use. 3.6.5 Hub Coordinator procedures A Hub Coordinator is responsible for assigning node numbers to nodes in his area. Each Hub Coordinator will be assigned a pool of numbers to use when assigning node numbers. A Hub Coordinator should never assign a node number outside of this pool, and should never assign the same number to more than one node. If a Hub Coordinator assigns all of the numbers in his pool, he should apply to his Network Coordinator for additional numbers. It is the responsibility of a Hub Coordinator to receive all inbound mail for nodes in his hub and to forward it to its recipients. How to accomplish this is left to the discretion of the Hub Coordinator. However, the same exceptions apply here as for a Network Coordinator. FidoNews 5-06 Page 23 8 Feb 1988 A Hub Coordinator may have additional duties, as assigned by his Network Coordinator. Chapter 4 RESOLUTION OF DISPUTES The world not being perfect, sometimes troubles crop up. Any organization larger than a cub scout pack needs some sort of grievance procedure, and FidoNet is no exception. The FidoNet judicial philosophy can be summed up in two rules: 1) Thou shalt not excessively annoy others. 2) Thou shalt not be too easily annoyed. In other words, there are no hard and fast rules of conduct, but reasonably polite behavior is expected. Also, in any dispute both sides are examined, and action could be taken against either or both parties. ("Judge not, lest ye be judged!") In any case of annoying behavior the person to complain to is the coordinator of the person who is annoying you. For example, if you have a problem with a point or a user you would complain to his sysop, or if you have a problem with a Regional Coordinator you would complain to his Zone Coordinator, and so on. If the coordinator you complain to fails to resolve the problem, then you can complain to his coordinator. For example, if you had a problem with a Hub Coordinator, you would first complain to his Network Coordinator. Then if the Network Coordinator does not resolve the problem, you would complain to his Regional Coordinator. Do not ever skip over a coordinator when filing a complaint. That in itself is annoying. 4.1 Case Histories A few actual case histories of past disputes may be instructive to show general procedures and methods. Names have been left out to protect the guilty. 4.1.1 The Case of the Crooked Node A sysop of a local node was using network mail to engage in unethical business practices. His Network Coordinator became very annoyed at this, and dropped the local from his node list. The local appealed to his Regional Coordinator for assignment as an independent node. The Regional Coordinator, on checking with the Network Coordinator, decided that the Network Coordinator was within his rights to be annoyed. Independent status was denied. FidoNews 5-06 Page 24 8 Feb 1988 4.1.2 The Case of the Hacker Mailer A sysop of a local node made use of file attaches for extra users to mail himself the USER.BBS file from several local boards. The sysops of these boards felt annoyed at this, and appealed to their Network Coordinator, who agreed and dropped the offending node from the node list. The Regional Coordinator was not consulted. The International Coordinator did not intervene. 4.1.3 The Case of the Network Mutiny Several local nodes became annoyed with their Network Coordinator for failing to provide services. They complained to him, but nothing was done. They appealed to their Regional Coordinator, who decided that they were justified in their annoyance and accepted their application for a new network number. 4.1.4 The Case of the Bothered Barker A local node became annoyed with his Network Coordinator for failing to provide services. Repeated complaints to his Network Coordinator did not satisfy him, so he appealed to the International Coordinator. The International Coordinator, on seeing that the Regional Coordinator had not been consulted, dismissed the complaint out of hand. The local node submitted his complaint to his Regional Coordinator, who investigated the case and discovered that there was some justice to the complaint. He advised and assisted the Network Coordinator in configuring his system to provide an improved level of service to the local nodes. The Regional Coordinator also decided that the local node was being too easily annoyed, in that he was expecting services not normally required of a Network Coordinator. The local node was informed as to the true duties of a Network Coordinator, and was advised to lower his expectations. 4.1.5 The Case of the Busy Beaver A local node which was operated by a retail establishment was engaged in making "bombing runs" to mail advertisements over FidoNet. His Network Coordinator felt annoyed and handling the outgoing traffic for a commercial operation, and asked the local node to leave the network. The local node applied to the Regional Coordinator, and was granted status as an independent node in his region. FidoNews 5-06 Page 25 8 Feb 1988 4.1.6 The Case of the Sysop Twit A patron of various local nodes had been roundly recognized by all sysops as a twit. The user obtained his own system, became a sysop, and applied for a node number. The Network Coordinator denied the request. No appeals were made. 4.1.7 The Case of the EchoMail Junkey key key A local node became enamored with EchoMail and joined several conferences, routing his outbound mail through his network. He then started an EchoMail conference of his own and began relaying EchoMail between several systems, again routing it all through his network. His Network Coordinator observed that network performance was becoming seriously impaired. The offending node was told to hold it down. A compromise was reached whereby much of the EchoMail traffic was no longer routed through the network, and routed EchoMail was limited to twenty messages per night. No appeals were made. 4.1.8 The Case of the Bouncing Board A local user decided to establish a node to promote a worthy charity. The machine being used was also used for various other activities during the day, and the sysop was often called away. His coworkers would often forget to bring the board up at the end of the day while he was away, so the node was often down for extended periods. The Network Coordinator, on finding the node unable to receive mail, would mark it as down. The sysop would return, restart the board, and ask to be reinstated as a node. The Network Coordinator eventually decided that the sysop was not able to maintain a reliable system, and removed him from the node list completely. Future requests for a node number from the same sysop were turned down. No appeals were made. ----------------------------------------------------------------- FidoNews 5-06 Page 26 8 Feb 1988 ================================================================= COLUMNS ================================================================= The Apple Core Alan Applegate The Short Line, 1:104/36 (Mail Only) I've given a lot of thought lately to starting my own column here in FidoNews. I contacted Dale Lovell (FidoNews Editor) shortly after his first editorial appeared in FidoNews 5-01, and after some difficulty getting started, here I am in all my written glory. For the overly curious, I operate a mail only node, formerly an Opus system until I grew tired of my users. I am Editor of Net 104 News (a twice-quarterly newsletter for the Denver net), as well as a quarterly newsletter for my employer. I am proud to have written the documentation for one of the most powerful software packages available to FidoNet: BinkleyTerm. My last appearance in FidoNews was issue 4-25, where I sputtered on about archiving programs. Although I'm proud of what I write, believe me, I do not consider myself a world class writer, or anything even close. In upcoming columns, I hope to cover a wide variety of topics from software reviews, to giving a good dose of mindless dribble on current issues. I will always welcome your comments and feedback; send your input to me at the node address listed above. Flames will not be dignified with a response; general comments will be replied to if warranted, and as time allows. I promised Dale that I would shoot for bi-weekly with the column, we'll see how that unfolds. Now on to column number one. ---------- I had written-up my first column for FidoNews several weeks ago, and although the column is still timely, I've decided to shift it down a couple of weeks in favor of something more appropriate. In my introduction, I mentioned "some difficulty getting started." I was referring to getting off to a rough start in my attempts to communicate with Dale Lovell about starting my column. Although I'm no old timer to FidoNet, I'm also no spring chicken. I'd like to believe, however accurate or inaccurate, that I have played and continue to play a role in the shaping of FidoNet. What's been built here is a marvel of modern technology. Inexpensive, real-time, rapid, easy, convenient written communication at our fingertips. Inexpensive is the one element that strikes me most; that, and being rapid. I can send a message overnight (or even quicker) to a friend on the other side of the country for less than the cost of a postage stamp. If I FidoNews 5-06 Page 27 8 Feb 1988 wanted to get the same message there by conventional means, say Federal Express, I'd drop a ten-spot every time I got the urge to communicate. No, FidoNet isn't going to be threatening Federal Express' dominant role in overnight delivery, or closer to our genre, MCI Mail and other such services. It's not that the potential isn't there, it's our system. When trying to contact Dale about my column, I sent at least three messages over the course of two weeks or so. I never did receive a response back from Dale. Since I personally witnessed my mail being sent to Dale's SEAdog, I assumed that he might harbor some sort of antagonism toward me for some reason, and I dropped the idea of writing a column. A week or so ago in a burst of renewed interest, I decided to ship-off one more message (my fourth) to Dale to 'give him one more chance' to explain the reason he never wrote me. I believe I said something to the effect that he 'owed me an explanation.' Not 10 minutes after I crashed the message to him in the early morning hours, I received a response back via crash mail that plainly stated that it was his fourth response... He explained that he normally routes his outbound mail through someone in his net, and was certain (I believe he'd already checked) that the mail did make it out of his net, and we assume, to my local net coordinator. I never received the mail. After sending a message to my coordinator (a very dedicated man), I remembered that he had had some problems with his hard disk over the past few weeks, and the responses could simply have slipped through the cracks. There is not a single point to this article, but several. First, FidoNet is not a for-profit system. It works most of the time because it just happens to. No one "owes" anyone anything. People volunteer, and they are expected to carry out their duties or pass along the baton to someone else. That doesn't mean that our systems are always free of hardware or software problems...that's part of the nature of our hobbiest roots. PROBLEMS DO OCCUR. Second, when problems occur, be patient. Just because it would appear that there's some sort of obvious problem or situation, doesn't mean that one's assessment is necessarily correct. Patiently investigate where the problem might be, but don't point fingers. WHEN PROBLEMS OCCUR, BE PATIENT. Third, just because you don't get a response from someone doesn't mean they hold anything against you. People are busy, and sometimes don't get around to responding. Occasionally, messages are accidently deleted before one has a chance to respond. Sometimes, as in my case, people DO respond, you just don't know it because you never got the response (see the first item). WHEN FidoNews 5-06 Page 28 8 Feb 1988 YOU GET NO RESPONSE, DON'T ASSUME ANYTHING. I learned the hard way I guess, and in the process, kind of made an ass out of myself (I always reserve the right to do that). Dale was particularly understanding, and sent me a considerate, patient response (and I finally received it). He could just as easily have told me where to stick my FidoNews columns. People too often do just that...respond to flames with more fire. Folks, two wrongs do not make a right...one of the oldest proverbs in the book. In most of the documentation I write (including this column, see my introduction) I say, "Flames not dignified with a response." I try my hardest to hold by that. I may write a response then erase it, just to get it out of my system, but generally, I simply don't respond. I refuse to stoop to the level of people who insist upon tearing apart what I say. Sending flames does no one any good. What the person is trying to say is lost because it's so heavily engulfed in flames, and the person who receives the fireball is too busy screaming about it to make an appropriate response. This is not productive. I don't mind constructive criticism. I strive to do well with whatever it is that I do. Constructive criticism helps me improve and understand. But the minute the match touches the can of Sterno, forget it. I'll take my criticism like I take my pizza...room temperature. So I've decided not to respond to flames. Now all I need to do is be a little more careful about starting them in the first place. My apologies to Dale...he's obviously a nice guy. After all, my column's in print, isn't it? See you again in another couple weeks. ----------------------------------------------------------------- FidoNews 5-06 Page 29 8 Feb 1988 ================================================================= WANTED ================================================================= -- VIRUS QUERY -- Reporter writing an article for the NY Times on the threat of "virus' ("mole,) "worm" and/or trojan horse "attack code" programs seeks reports of real experiences with these often distructive, sometimes playful, devices. I'm interested in any reports about incidents involving PCs, minis or micros. Please forward replies to Vin McLellan at Fido 101/154, (voice) 617-426-2487, or Snail : 125 Kingston St., Boston, Ma. 02111. ----------------------------------------------------------------- FidoNews 5-06 Page 30 8 Feb 1988 TRW Real Estate Information Systems, in Anaheim, CA is seeking a creative Senior Programmer/Analyst to aid in the analysis, design and implementation of a new generation of micro/mainframe systems running in an IBM PC-AT compatible multitasking environment. We are looking for motivated, independent thinker with a minimum of two years MS-DOS micro programming in C or Macro Assembler and two years mini/mainframe programming. Experience in structured development techniques and systems analysis/design required. Familiarity with micro-mainframe communications, micro hardware, and networks is desirable. Direct customer interface is common, so good written and oral communication skills are needed. Please forward your resume with work history and references to: TRW Real Estate Information Systems, Professional Employment, Dept. DL-101, 2000 S. Anaheim Blvd., Suite 100, Anaheim, CA 92805. An equal opportunity employer. ----------------------------------------------------------------- FidoNews 5-06 Page 31 8 Feb 1988 ================================================================= NOTICES ================================================================= 5 March 1988 The Area Code for Southern Colorado changes to 719. Be sure to change your script files as necessary. ----------------------------------------------------------------- The Interrupt Stack 19 Feb 1988 Start of the International FidoNet Associations Board of Directors meeting in St. Louis. Meeting runs through the 21st. 25 Aug 1988 Start of the Fifth International FidoNet Conference, to be held at the Drawbridge Inn in Cincinnatti, OH. Contact Tim Sullivan at 108/62 for more information. This is FidoNet's big annual get-together, and is your chance to meet all the people you've been talking with all this time. We're hoping to see you there! 24 Aug 1989 Voyager 2 passes Neptune. If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. ----------------------------------------------------------------- Latest Software Versions BBS Systems Node List Other & Mailers Version Utilities Version Utilities Version Dutchie 2.80* EditNL 3.3 ARC 5.21 Fido 12e* MakeNL 1.10 ARCmail 1.1 Opus 1.03a Prune 1.40 ConfMail 3.31* SEAdog 4.10 XlatList 2.85* EchoMail 1.31 TBBS 2.0M MGM 1.1 BinkleyTerm 1.30* * Recently changed Utility authors: Please help keep this list up to date by reporting new versions to 1:1/1. It is not our intent to list all utilities here, only those which verge on necessity. ----------------------------------------------------------------- FidoNews 5-06 Page 32 8 Feb 1988 __ The World's First / \ BBS Network /|oo \ * FidoNet * (_| /_) _`@/_ \ _ | | \ \\ | (*) | \ )) ______ |__U__| / \// / Fido \ _//|| _\ / (________) (_/(_|(____/ (tm) Membership for the International FidoNet Association Membership in IFNA is open to any individual or organization that pays a specified annual membership fee. IFNA serves the international FidoNet-compatible electronic mail community to increase worldwide communications. Member Name _______________________________ Date _______________ Address _________________________________________________________ City ____________________________________________________________ State ________________________________ Zip _____________________ Country _________________________________________________________ Home Phone (Voice) ______________________________________________ Work Phone (Voice) ______________________________________________ Zone:Net/Node Number ____________________________________________ BBS Name ________________________________________________________ BBS Phone Number ________________________________________________ Baud Rates Supported ____________________________________________ Board Restrictions ______________________________________________ Your Special Interests __________________________________________ _________________________________________________________________ _________________________________________________________________ In what areas would you be willing to help in FidoNet? __________ _________________________________________________________________ _________________________________________________________________ Send this membership form and a check or money order for $25 in US Funds to: International FidoNet Association c/o Leonard Mednick, MBA, CPA 700 Bishop Street, #1014 Honolulu, Hawaii 96813-4112 USA Thank you for your membership! Your participation will help to insure the future of FidoNet. Please NOTE that IFNA is a general not-for-profit organization and Articles of Association and By-Laws were adopted by the membership in January 1987. The first elected Board of Directors was filled in August 1987. The IFNA Echomail Conference has been established on FidoNet to assist the Board. We welcome your input to this Conference. ----------------------------------------------------------------- FidoNews 5-06 Page 33 8 Feb 1988 INTERNATIONAL FIDONET ASSOCIATION ORDER FORM Publications The IFNA publications can be obtained by downloading from Fido 1:1/10 or other FidoNet compatible systems, or by purchasing them directly from IFNA. We ask that all our IFNA Committee Chairmen provide us with the latest versions of each publication, but we can make no written guarantees. Hardcopy prices as of October 1, 1986 IFNA Fido BBS listing $15.00 _____ IFNA Administrative Policy DOCs $10.00 _____ IFNA FidoNet Standards Committee DOCs $10.00 _____ SUBTOTAL _____ IFNA Member ONLY Special Offers System Enhancement Associates SEAdog $60.00 _____ SEAdog price as of March 1, 1987 ONLY 1 copy SEAdog per IFNA Member Fido Software's Fido/FidoNet $100.00 _____ Fido/FidoNet price as of November 1, 1987 ONLY 1 copy Fido/FidoNet per IFNA Member International orders include $10.00 for surface shipping or $20.00 for air shipping _____ SUBTOTAL _____ HI. Residents add 4.0 % Sales tax _____ TOTAL _____ SEND CHECK OR MONEY ORDER IN US FUNDS: International FidoNet Association c/o Leonard Mednick, MBA, CPA 700 Bishop Street, #1014 Honolulu, HI. 96813-4112 USA Name________________________________ Zone:Net/Node____:____/____ Company_____________________________ Address_____________________________ City____________________ State____________ Zip_____ Voice Phone_________________________ Signature___________________________ -----------------------------------------------------------------