Volume 7, Number 41 8 October 1990 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | FidoNet (r) | | \ \\ | | International BBS Network | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Vince Perriello Editors Emeritii: Thom Henderson, Dale Lovell Chief Procrastinator Emeritus: Tom Jennings Copyright 1990, Fido Software. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact Fido Software. FidoNews is published weekly by the System Operators of the FidoNet (r) International BBS Network. It is a compilation of individual articles contributed by their authors or authorized agents of the authors. The contribution of articles to this compilation does not diminish the rights of the authors. 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. 1:1/1 is a Continuous Mail system, available for network mail 24 hours a day. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, Box 77731, San Francisco CA 94107, USA and are used with permission. Opinions expressed in FidoNews articles are those of the authors and are not necessarily those of the Editor or of Fido Software. Most articles are unsolicited. Our policy is to publish every responsible submission received. Table of Contents 1. ARTICLES ................................................. 1 EchoPol Revisited ........................................ 1 Conserve paper with 2 sided printing ..................... 14 Call New York Update #1 .................................. 16 General Elections in Zone 4 .............................. 17 Summary of FidoCon in Zone 5 ............................. 19 Home Schooling Echo on the Backbone ...................... 23 Loglan Language and Echo ................................. 24 MACINTOSH ALTERNATIVE CONNECTIONS LIST (MACLIST) - UPDA .. 26 OTHERNET NEWS ............................................ 29 2. LATEST VERSIONS .......................................... 30 And more! FidoNews 7-41 Page 1 8 Oct 1990 ================================================================= ARTICLES ================================================================= Introducing the Old Echomail Policy George Peace 1:1/0 Many of us have seen the document. Many use it every day to help us choreograph the flow of echomail. But until a real Echomail Policy is enacted as a formal Zone 1 Policy, we're all simply operating the backbone; moderating our conferences; and choosing our Echomail Coordinators independently, inconsistently, and without administrative support. Echopol isn't perfection -- Policy never does seem to be. Some parts of it give some of us heartburn while others evoke our applause. What most of us do agree on is the need to enact an Echomail Policy. The Zone 1 Region Echomail Coordinators have banded together to offer the April 1989 Echopol to the Zone 1 Coordinator for adoption. I've joined them in this effort after witnessing and even being part of situations that would have had a much different outcome if we'd finished the job we started 18 months ago. So what we've proposed is that the document be adopted as the Zone 1 General Echomail Policy effective October 22, 1990. For the first 60 days following its adoption, Zone 1 will operate under that Policy. During that time, the Zone 1 RECs will accept our constructive comments and requests for change. Comments and RFCs will be accepted by any Zone 1 REC in a two part Situation / Solution format that includes a proposed change to the Policy. At the end of the 60 day period, the RECs will work with change submitters, Conference Moderators, and NECs to determine which solutions/changes will be implemented. A *C/*EC ratification referendum for the revised EchoPol will be conducted between January 15 and January 31. If that referendum fails, the Zone 1 Echomail Coordinator will coordinate efforts to submit another document for ratification. The document presented here is also available for file request as ECHOPOL from 1:1/0, 1:157/200, 1:12/12, 1:13/13, 1:114/5, 1:322/1, 1:105/310+311+312, 1:151/1003, 1:382/1, and 1:396/1. GENERAL ECHOMAIL POLICY 1.0 October 22nd, 1990 FidoNews 7-41 Page 2 8 Oct 1990 PROLOGUE This document sets forth policy governing Echomail conferences and their distribution. If any item in this policy is in conflict with any existing or subsequent General FidoNet Policy, then General FidoNet Policy will be in effect. This Policy applies to Zone One Backbone Echomail conferences and to any other conferences for which the Moderator desires it to be applicable. Future changes to Echo Policy may be proposed by any FidoNet Sysop by submitting the proposal to their REC. The REC will then determine if the proposal should be brought before the rest of the RECs. If an REC decides not to bring a proposed change before the rest of the RECs, a message stating why must be sent. If 10% or more of the NCs and NECs in a region request that a proposal be brought before the RECs then that proposal must be submitted to the RECs. A majority vote of the Regional Echomail Coordinators is required in order for a proposal to be formally voted on. If 10% or more of the NCs and NECs in the Zone request that a proposal be formally voted on, then that proposal must be formally voted on. Those eligible to vote on any proposals made by the REC structure will be the ZEC, RECs, NECs, NCs, RCs and ZC. Only one vote per person is allowed. Adoption of changes will require a simple majority of those voting to pass. In this document, "a simple majority" means more than 50 percent of those voting. A good faith attempt must be made to make all potential voters aware that a vote is occurring and make available all necessary information. I. HISTORY Echomail consists of the sharing of message bases or conferences between various independent network addresses. The Echomail concept started with a series of programs by Jeff Rush. Since the original implementation, many authors have written programs improving on the original idea. In spite of worries that the flow of Echomail would increase Netmail traffic to the point that the Network would collapse under its own weight, Echomail has been a success. To simplify the distribution of Echomail, a national Echomail Backbone formed whose primary purpose is the distribution of Echomail at a national level. Of recent introduction to the Backbone system has been the generous contribution of the Echomail Stars. As a result of the growth of Fidonet and the increase in the volume of Echomail, it has become necessary to set forth a formal policy governing Echomail. FidoNews 7-41 Page 3 8 Oct 1990 II. DEFINITIONS 1. ECHOMAIL: The process of sharing message bases between independent systems with unique net/node addresses. 2. ECHOMAIL CONFERENCES: An Echomail conference is a message base of forum design distributed under a specified conference name dealing with a defined area of interest. Notable examples include TECH, the National Technical Conference and COMM, the National Telecommunications Conference. 3. MODERATED CONFERENCE: A moderated conference is an Echomail conference for which a moderator has been appointed to supervise the flow and content of the conference. All conferences carried on the Backbone must be moderated. 4. SYSOP-ONLY CONFERENCE: A Sysop-Only Conference is one in which the Moderator has decided that the conference will be made available only to Sysops and not to users. 5. RESTRICTED DISTRIBUTION CONFERENCES: A restricted distribution conference is one which is restricted only to eligible recipients. Notable examples include REGCON, the Regional Coordinators Conference, COORD, the National Echomail Coordinators Conference, and MAGICK, a pre-register Echomail Conference. 6. ZONE ECHOMAIL COORDINATOR (ZEC): This individual is responsible for coordination of Echomail on a FidoNet Zone level. 7. REGIONAL ECHOMAIL COORDINATOR (REC): This individual is responsible for coordination of Echomail within his region. 8. NET ECHOMAIL COORDINATOR (NEC): This individual is responsible for coordination of Echomail at the Local Net level. 9. ECHOMAIL Backbone: The Echomail Backbone consists of voluntary members who provide services to enhance the national distribution of Echomail. The Backbone consists of nodes which handle a high volume of Echomail traffic and are responsible for distribution of Echomail down to the regional level. 10. NATIONAL ECHOMAIL LIST: The National Echomail List identifies the available national conferences, the conference moderator and requirements of the specified conference. The ZEC will appoint the keeper of the National Echomail List. 11. AUTOMATED CENSORSHIP: The term Automated Censorship refers to programs which cause messages to be removed from the intended conference or have their content altered. FidoNews 7-41 Page 4 8 Oct 1990 12. FIDONET POLICY: The document which governs Fidonet as adopted by Fidonet. The document as of this writing is Policy4 and is subject to change. This policy is intended to become a part of general Fidonet policy. Until it is incorporated into General Fidonet policy, this document shall serve to define policy violations occurring in Echomail. 13. OPEN ACCESS CONFERENCE: This is a non-restricted conference open to all users who are willing to follow the posted conference rules. 14. TERMINAL NODE: A system which does not process echomail for pickup by another system. III. DUTIES OF ECHOMAIL COORDINATORS 1. GENERAL: It is the duty of the *ECs to make available to any Fidonet Sysop, any conference which the Sysop is not prohibited from receiving by not meeting requirements as mandated by the conference moderator. If for any reason the *EC does not have access via recognized distribution channels to a specific conference, they can not be expected to pass it on. If a *EC fails to make available any conference to qualified lower distribution levels, this shall be deemed to have violated the outlined duties of the position held. Such violation is cause for the removal as provided by this document. Nothing in this provision requires that a *EC must import any conference to the extent of adverse economic impact. It is recommended that cost sharing arrangements be employed. Where financially feasible for the supplier any conference on the Backbone must be made available (other than restricted conferences) when requested. An exception is when a *EC cuts a link to end unauthorized distribution of a conference. In this case, some otherwise authorized nodes may temporarily lose their link. A *EC shall do everything in their power to insure that: 1. All downstream links are educated as to this policy. 2. Downstream links know how to properly link into conferences. 3. Acceptable and unacceptable behavior in echomail conferences is explained. 4. Downstream links are not engaging in topologies that increase the risk of duplicate messages. 2. DUTIES OF ZONE ECHOMAIL COORDINATOR: It is the duty of the ZEC to coordinate the connections between the Echomail Backbone on both an inter-Zone and intra-Zone level as well as coordination of inter-regional connections. The ZEC will coordinate transmission of Echomail and to provide for routing in a manner that will avoid the transmission of duplicate messages FidoNews 7-41 Page 5 8 Oct 1990 within the same conference. It is also the duty of the ZEC to monitor compliance with this policy on both a national and international basis. 3. DUTIES OF REGIONAL ECHOMAIL COORDINATOR: It is the duty of the REC to provide for regional Echomail distribution. In addition, the REC will coordinate any inter-regional cross-linking of conference feeds with the REC of the participating region with the direct knowledge of the ZEC. The REC will provide for transmission and routing of Echomail within his/her region in a manner to avoid creation of duplicate messages within the same conference. It is the duty of the REC to monitor compliance with this policy at a regional level. 4. DUTIES OF NET ECHOMAIL COORDINATOR: It is the duty of the NEC to coordinate the intra-net Echomail and to cooperate with the REC and NECs of other nets to arrange for the inter-net transmittal of echomail. The REC may require the NEC to provide links for independent (regional) nodes. The NEC shall maintain a list of available Echomail Conferences within the net as well as the requirements of each Conference area as supplied by the conference moderator (Echolist). The NEC shall also monitor compliance with this policy at a net level. 5. DUTIES OF ECHOLIST COORDINATOR: It is the duty of the Echolist Coordinator to compile and make available a listing of national and international Echomail conferences and optionally, conferences at various local levels. The content and format of the Echomail listing shall be at the sole discretion of the Echolist Coordinator, but shall include the conference name and moderator for each conference. The Echolist Coordinator shall also maintain a list of requirements applicable to each listed conference. 6. DUTIES OF ECHOMAIL CONFERENCE MODERATOR: It shall be the duty of the Echomail Conference Moderator to make in good faith every reasonable effort to insure that the moderated conference does not distribute or promote illegal activities or information as defined below in Section V Paragraph 2. The Moderator shall be responsible for insuring that messages contained in the conference corresponds to the conference theme. The Moderator shall report any violations of this policy to the proper Echomail coordinators and lodge any appropriate policy complaints as provided for in policy documents adopted by Fidonet. The Moderator shall post the conference rules in the conference at least once a month. The Moderator is to authorize the disconnection of the conference feed. Any Sysop the moderator believes is violating policy shall be reported to the offending node's nearest local echomail coordinator (may be a NEC, REC or in extreme situations a ZEC); and the moderator shall formally authorize the feed to the offending node to be severed. The conference moderator is the sole judge, subject to review only by the ZEC (or his delegates), if a complaint is filed by the banished party. The Moderator may request in direct written form (netmail) that the *ECs disconnect a node from the conference when that node refuses to follow the published conference rules FidoNews 7-41 Page 6 8 Oct 1990 after at least 3 warnings. Knowingly feeding a conference to a node that has been severed by the Moderator is considered a violation of this echomail policy and is subject to suspension. The length of this suspension will be determined by a joint decision of the conference moderator and the nearest local echo coordinator of the node illegally feeding the conference to the original offending node or point. Echo conference complaints from a Sysop should be filed at the net level (NEC) or if the complaining party is an independent node then with their REC. The NEC or REC receiving such a complaint must take action in accordance with the provisions of this echomail policy. For severe or chronic infractions the NEC, REC or ZEC may file a complaint under general Fidonet policy for excessively annoying behaviour. IV. APPOINTMENT AND ELECTION OF ECHOMAIL COORDINATORS AND MODERATORS 1. GRANDFATHER CLAUSE: Those Zone, Regional, and Net Echomail Coordinators and Echomail Coordinators currently holding these positions as of the date of acceptance of this Echomail Policy shall continue to serve in said capacity until resignation or replacement under this policy. 2. ELECTION OF ZONE ECHOMAIL COORDINATOR: The ZEC shall be elected as follows: a) upon resignation or replacement of the existing ZEC, the FidoNet Zone Coordinator (ZC) shall nominate at least five individuals to be voted upon. b) 10 days after the nominees are selected, an election shall be held. The ZEC will be elected by a simple majority of IC, ZC, RCs, NCs, RECs, and NECs in their Fidonet zone. An individual holding more than one position can only cast one vote. That is, if an individual is both a NC and a NEC, they may cast only one vote. 3. ELECTION OF REGIONAL ECHOMAIL COORDINATOR: The REC shall be elected as follows: a) upon resignation or replacement of an existing REC, the ZEC shall nominate at least 3 individuals for election. b) 10 days after the nominees are selected, an election FidoNews 7-41 Page 7 8 Oct 1990 shall be held. The REC will be elected by a simple majority of the RC, NCs and NECs in their FidoNet Region. An individual holding more than one position may only cast one vote. 4. NET ECHOMAIL COORDINATOR: The NEC shall be appointed by the FidoNet Net Coordinator (NC) or in such alternative manner as determined by the NC. If a NEC is not appointed within 30 days, the REC will appoint the NEC. 5. REMOVAL OF A *EC: A *EC may be removed from their position\ by a simple majority of those allowed to vote for their successor. For a NEC, the members of the Net may vote by simple majority to remove the NEC. The position directly above (in the *EC structure) will oversee the recall election in the same manner as prescribed for electing successors. A *EC may only be subject to recall for failure to properly carry out their duties described above, or if they are no longer a member of Fidonet. A promise of 'free' echomail delivery from another source is *not* considered an acceptable reason for recall. A *EC may be removed by the level above for continued violations of policy or for gross misconduct. 6. RECOGNITION OF CONFERENCES: The *EC corresponding to the appropriate level recognizes a conference at his level. Examples: The NEC recognizes a conference as local. The REC recognizes a conference to be regional. A ZEC recognizes a conference to be zonal. 7. REMOVAL OF AN ECHOMAIL CONFERENCE MODERATOR: An Echomail Conference Moderator may be removed from their position by a three fourths (3/4) vote of the *EC structure voting. This vote must be carried out in a fair and decent manner while giving at least ten (10) days notice to the entire *EC structure of the upcoming vote. The ZEC shall notify the RECs who in turn shall notify the NECs in their region of any upcoming vote. Notice must be given via NetMail. Additional postings in such conferences as COORD and regional conferences are encourgaged. An Echomail Conference Moderator may only be subject to recall for failure to properly carry out their duties described above or continued pre-meditated violation of this documents section V. Statement of Policies as seen below. Failing to perform the above duties of a conference moderator for a period of 3 or more months and/or failing to designate a proxy in his absence shall be in violation of this policy and be subject to recall. A vote may only be callable by the ZEC (or his delegate). This delegate should not be from the region or net of the affected conference moderator. FidoNews 7-41 Page 8 8 Oct 1990 Membership in Fidonet need not be a paramount issue, but is highly recommended. V. STATEMENT OF POLICIES 1. BASIC ECHOMAIL POLICY: The basic policy of Echomail is to promote communication in Echomail Conferences in a lawful, friendly manner consistent with the general principles of FidoNet. 2. PROHIBITION ON ILLEGAL ACTIVITIES: Any Node which knowingly distributes or allows to be entered into echomail conferences any messages containing or promoting illegal activities or information shall be deemed to have violated general FidoNet policy as being excessively annoying. As used in this paragraph, "illegal activities" includes activities which are a violation of civil law as well as activities which would result in criminal prosecution. 3. AUTOMATED CENSORSHIP: The use of Automated Censorship in the passing or distribution of echomail will be considered a violation of this policy and will not be tolerated. Disciplinary action will be as referred to in General Fidonet policy as being excessively annoying. An exception to this provision shall be the deletion and not censorship of messages by any Sysop which may lead to legal action against that Sysop. No echomail shall be modified in any manner which could potentially cause duplicates. 4. INTER-NETWORK CONFERENCES: Inter-Net conferences shall conform to general Fidonet policy as well as the provisions of this policy document in addition to any foreign network's provisions. Conferences which originate outside of FidoNet must be designated as such in the list of conferences kept by the Echolist Coordinator. 5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit from the distribution (passing from system to system) of echomail shall be deemed to be excessively annoying and in violation of Fidonet policy subject to enforcement under existing Fidonet policy. Profit as defined in this paragraph is the charging for echomail distribution that exceeds actual cost to obtain and distribute the Echomail over a sustained period. The cost of the equipment used to obtain and distribute echomail may only be recovered on a strictly voluntary basis. A Sysop that charges users for access to their BBS shall NOT be in violation of this paragraph. FidoNews 7-41 Page 9 8 Oct 1990 Implementation of cost recovery plans may vary greatly. In general cost recovery plans should not be overly restrictive. 6. RESTRICTED DISTRIBUTION CONFERENCES: Participating Nodes shall honor and support the restrictions placed upon restricted distribution conferences. Violation of this restriction by individual nodes and points shall be a violation of this echomail policy and result in suspension of the violated echo in accordance with the above paragraph in Section III Duties of the Echomail Conference Moderators. A Sysop-only conference shall be made available only to the Sysops or Co-Sysops of Fidonet or other nets with which inter-net conferences exist. A violation of the restrictions placed on a RESTRICTED DISTRIBUTION CONFERENCE will be a violation of this policy if and only if the moderator has posted and specified the restrictions governing the conference. 7. PATHLINE OPTION: The PATHline (as defined in FTS-0004), originally implemented by SEA in the MGM package, is recommended for all nodes. If your current Echomail scanner supports the pathline you should enable it. While the pathline does not eliminate duplicate messages, it can be a very useful tool in determining where a topology problem exists. Systems operating as Echomail Stars, Backbone nodes, or Echomail Hubs must implement the PATHline option (as defined in FTS-0004 within 30 days of adoption of this policy. Since these system are operating beyond the scope of the typical FidoNet system, they are required to implement features that are otherwise optional. 8. SEEN-BY LINE: Under the current technology and topology (the routing structure of echomail), SEEN-BY lines play an important part in reducing duplicate messages. Tiny SEEN-BYs will not be allowed until the respective ZECs feel topology will allow their use. Nor will the stripping of SEEN-BYs (except Zone-Gates and Inter-Network EchoGates) be allowed unless approved by the ZEC. Violation of the above shall be excessively annoying behavior enforceable under general Fidonet policy. Zone-Gates and Inter- Network EchoGates SHOULD strip the SEEN-BYs of the exporting Zone or Network to reduce addressing conflicts. 9. COUNTERFEIT MESSAGES: Entering or knowingly distributing counterfeit messages shall be considered excessively annoying and a violation of Fidonet policy enforceable under the terms of Fidonet policy. As used in this paragraph, a counterfeit message is defined as any message entered using another person's name, handle or node address with the intent of deceiving others about the true author of the message. No handles shall be used to enter messages to knowingly provoke, inflame, or upset participants in a conference with the purpose of deceiving others about the true identity of the author. FidoNews 7-41 Page 10 8 Oct 1990 10. SYSOP'S RESPONSIBILITY: It is the responsibility of each Sysop to make every reasonable effort to assure that the users on his board conform to the provisions of this policy document. A Sysop may be held responsible for the acts of his users unless the Sysop can show that a reasonable attempt was made to conform to this policy document. 11. ECHOMAIL SOFTWARE: Echomail software which does not conform to the minimum acceptable standards as defined by the Fidonet Technical Standards Committee (FTSC) shall lead to disciplinary action as described previously in this document. 12. HOST ROUTING OF ECHOMAIL: Host routing of Echomail without the prior consent of both the Sending and Receiving Hosts shall lead to disciplinary action as described previously in this document. See Section III. 13. INTER-NETWORK CONFERENCES: It is the general policy of Fidonet to encourage the development of INTER-NETWORK CONFERENCES. It shall be the duty of those providing the INTER-NETWORK CONFERENCE links to remove foreign net distribution identifiers which will adversely effect the distribution of the Echomail Conference while in Fidonet. The INTER-NETWORK CONFERENCE links maintained in Fidonet shall be operated in a manner not to interfere with the foreign network's distribution of Echomail. INTER-NETWORK CONFERENCE links maintained in FidoNet must also conform to General FidoNet Policy. 14. DEFAMATORY POSTING: The posting of any DEFAMATORY MESSAGE other than in conferences dedicated to this purpose (i.e. FLAME) shall lead to disciplinary action as described previously in this document. See Section III. The posting of substantiated facts shall not be considered a violation under this section. 15. ADDING OR REMOVING CONFERENCES FROM THE BACKBONE: A conference may be added to the Backbone only at the request of the RECOGNIZED Conference Moderator. A conference must be registered with the Echolist Coordinator before it can be added to the Backbone. A conference may be removed from the Backbone by lack of traffic. The recognized conference moderator may, at their discretion, request removal from the backbone any conference that same moderator initially placed in backbone distribution. 16. TOPOLOGY and DUPLICATE MESSAGES: Cross Regional links should be avoided as they increase the risk of improper linking and generation of duplicate messages. Cross Regional links may only be established with the knowledge of the REC in both regions. The REC must be notified prior to or at the time of the link being established. If an REC determines that a cross regional link is contributing to the creation of duplicate messages, the REC may request that the link be terminated. FidoNews 7-41 Page 11 8 Oct 1990 The use of the PATHline option is required for all out of region links. If a sysop has a prior history of creating duplicate messages because of out of region links, the REC may require prior notification and approval before an out of region link can be established. Cross Regional links are permitted without notifcation if one of those systems is a dead-end. Should the status of this link change, then notification is required. Each REC will do their best to make available high speed hubs, out of state hubs, PC Pursuit hubs, etc, to facilitate the low cost, efficient movement of mail within their respective Region. Any Sysop who willfully and knowingly establishes links that either create duplicate loops (topology that creates circular feeds) or who refuses to break such links upon request by their NEC, REC or ZEC shall be subject to disciplinary action as described previously in this document. See Section III. 17. MESSAGE STANDARDS: Until the adoption of a superceding standard by the Fidonet Technical Standards Committee, the following Echomail message standards are recommended: a) Eight-bit characters (ASCII 128-255) and non-printing low-order codes (ASCII 2-31) are prohibited, except the use of 8Dh(soft character) per FTS-0004. This is not intended to discourage participation of foreign zones or networks, which may permit said characters. Any echomail processor should pass information exactly as it was received, without stripping any non-standard characters. b) Origin lines should be limited to 79 characters including the required ending of a proper network address (i.e. Zone:Net/Node.Point with zone and point being optional). c) Tear lines should be limited to 35 characters including the required "--- " lead-in. These should only contain packer or editor program identification. Tear lines for message editors are discouraged. If an editor adds a tear line, it should also add an origin line to avoid multiple tear lines. d) "Extra" origin lines (ZoneGating) are limited to essential information only. This consists of the required lead-in plus the network name "Gateway" and optionally the software ID followed by a Zone:Net/Node FidoNews 7-41 Page 12 8 Oct 1990 address. Example: " * Origin: FidoNet Gateway (TComm 88:372/666)" e) SEEN-BY addresses should be in sorted order. Multiple AKA's are not allowed in SEEN-BY lines unless you have more than one address which processes mail. Or for one month during change of an existing address (to avoid duplicates to the previous address). Node 0 addresses should not be used for echomail distribution. f) All current FTSC specifications must be followed. VI. ENFORCEMENT Enforcement of this policy document shall be under the provisions of General FidoNet policy. Complaints concerning Echomail violations defined under this policy may be filed by the aggrieved individual, the conference moderator or by any level of Echomail Coordinator to the appropriate *C level. All complaints made pursuant to this policy must be made within 60 days of the date of occurrence or discovery. Complaints shall be filed under the provisions of General Fidonet Policy, with a copy to the respective *EC. Enforcement is immediate, with any currently existing software allowed 60 days to conform (from the date EchoPol1 goes into effect). A 30 day extension may be granted solely at the discretion of the ZEC if efforts to bring about compliance are clear. Continued use of aberrant software after this period shall be deemed excessively annoying. VII. ADOPTION OF POLICY 1. ADOPTION: This policy shall become effective upon ratification by a simple majority of those voting. Those eligible to vote shall be the IC, ZCs, RCs, NCs, ZECs, RECs, and NECs. Those individuals holding more than one position can cast only one vote. 2. GRANDFATHER CLAUSE: Within 60 days of adoption of this policy, moderators shall be appointed for all existing Echomail Conferences which do not now have a moderator. Moderators shall be appointed by the ZEC from those volunteering as moderator or if no volunteer is available then the ZEC shall request and appoint a moderator for the conference. In the case where more than one individual claims to be the conference moderator and no agreement can be reached, the ZEC may order the conference retired and ban the further use of the specific conference name. Failure of the individuals to retire the conference name shall be deemed excessively annoying behavior. FidoNews 7-41 Page 13 8 Oct 1990 VI. BACKBONE STRUCTURE This section is for information purposes only. It gives a plain English description of the current structure and operation of the Backbone. The ZEC may change this structure without amending this document. At the top of the Echomail distribution network, there are systems commonly called Stars. These systems are usually dedicated to passing Echomail. The stars operate at the discretion and direction of the ZEC. At the time of this writing there are 3 stars, each has a backup system/plan in the event of a failure. In general, the Stars link to one another and feed the RECs. The RECs are then responsible for distribution of the echomail within their Region. Normally, the REC will feed the NECs in that region. The NEC is responsible for distribution of Echomail to the individual Sysops within a net. Note that the RECs and NECs can appoint Hubs to help in the distribution of Echomail. That is, they do not have to directly feed the lower level. This is the distribution GOAL. Because of less expensive phone rates and other reasons, this distribution method is not followed exactly. Any change to the above requires agreement of the *EC's involved. All *ECs will use all the tools at their disposal, such as hubs, high speed modems, ROA, Wide Area Calling plans, PC Pursuit, corporate sponsorship, etc., to provide fast, efficient, and cost effective movement of echomail. Echopol Committee Mike Ratledge Norm Henke Rick McWilliams Barry Shatswell ----------------------------------------------------------------- FidoNews 7-41 Page 14 8 Oct 1990 Dave "who likes to jump out of airplanes" Appel Just a user on 1:231/30 [bych mode on] Personally, I'm getting sick and tired of all the non- computer-related articles appearing in FidoNews. Especially the ones by the eco-freaks, the left-wing-commie-pinko- conspiracy-theorists, either side of the abortion issue, and 30K .GIF files of some stranger's ugly mug. (However, an occasional missing child announcement is fine by me.) If you can't relate it to computers, or the network, find someplace else to publish it, please. I even prefer bashing/defending the editor about LHARC versus ARC than the completely off-topic junk. [bych mode off] Well, here's how conservation CAN be applied by computer users. Print on both sides of the paper. As an arch-conservative anal-retentive capitalist pig I see it as a way to save dollars on my paper costs. Bottom line, you know. For you tree-hugging vegetarian environmentally correct eco-geeks, you might even save a few trees so you can continue your smug sense of moral superiority. There are several utilities that are specific to certain printers or to certain word processing packages. There are even utilities to split text files into 2 files, one containing odd-number pages, and the other containing even-number pages. An example of such an "evironmentally conscious" (cost conscious to me) utility is 4PRINT for the HP LaserJet. It prints 4 66-line pages per sheet of paper, 2 each, front and back. You have to run the paper through twice. It's shareware. Some word processors such as XYWRITE have built-in macros for printing odd and even pages. The LaserJet IID prints on both sides of the paper, but not many people have these printers. For the rest of us, we need to print the odd pages, turn the paper around, feed it back into the printer, then print the even pages. The lazy way that I used to print documentation was to: COPY myfile.DOC LPT1 Since I decided to do double sided printing, I always bring the doc file into my word processor and print it from there, where I have control over which pages to print. MS-Word 5.0 doesn't have a built-in macro to do this so I wrote my own. Here it is: FidoNews 7-41 Page 15 8 Oct 1990 jp[SET lastpage = field] [ASK pageno=?Enter starting page] [WHILE pageno <= lastpage] pop[pageno] [SET pageno=pageno+2] [ENDWHILE] You need to substitute the "[" and "]" symbols with the chevrons by pressing Control-[ and Control-]. (The chevrons are special characters, 174 and 175, that ARTSPEC.DOC says not to include in FidoNews articles.) You can store this macro in your macro glossary. Load your paper, run the macro, tell it page "1", when the printing is done, reload the paper backwards, run the macro, tell it page "2". If you do everything right, and your printer doesn't jam, you just cut your paper usage in half, with only about an extra 42.5 seconds of effort. If something goes wrong, like a printer jam, or you re-edit the document in between printing the two sides (thereby shifting the page breaks), you just screwed up the whole thing, wasted even more time, and wasted more paper than you were going to save in the first place. Another benefit of two-sided printing is that when the document becomes obsolete, you aren't tempted to keep it around as clutter hoping to someday use the blank side as scrap paper. You can chuck the whole thing with the satisfaction of knowing that you squeezed every last use out of it, or you can even (*gasp*) recycle it. ----------------------------------------------------------------- FidoNews 7-41 Page 16 8 Oct 1990 Ronnie Toth FidoNet 1:135/71 October 3, 1990 ** CALLNY Update ** We've done it! CALLNY is on the FidoNet backbone now and all you have to do is pester your wonderful NEC to get it for you! He can then pester his/her also wonderful REC and there you are! You can be in New York too! TAG: CALLNY Topic: Anything New York Moderator: Ronnie Toth FidoNet 1:135/71 We will be listed in ELIST011. For those who called the two originating systems, thank you. This should make it simple for all. An official thank you goes to: Ray Vaughan who started the whole ball rolling Michele Hamilton who taught me how to go about echo-making and assisted whenever needed. (Lots.) Amnon Nissan who freely gave words of encouragement John Cottrell More words of encouragement Fabian Gordon More words of encouragement and the spreader of the word up NY way Roger Bonenfant Our first actual NY link, (even though he's in NJ) Thank you one and all. See ya in NY! Ronnie ----------------------------------------------------------------- FidoNews 7-41 Page 17 8 Oct 1990 Pablo Kleinman FidoNet 4:4/0 General Elections in Zone 4 Elecciones Generales en la Zona 4 Eleicoes Gerais na Zona 4 As the result of an agreement reached by ZC4 and the rest of Zone 4's coordinators, on November 9th 1990 the members of FidoNet Zone 4 "Latin America" will be able to vote for the renovation of the whole coordination structure of the zone, and elect Network coordinators, Region coordinators and Zone coordinator. The procedures defined for the democratic election process are the following: - All the FidoNet members will be able to present themselves as candidates to a single coordination position, by sending netmail to Elecciones at node 4:4/444 until October 20th, stating the position they intend to run for. - On October 21st, the list of all candidates will be published on the official echomail conference LATIN.SYSOP and on October 22nd, on FidoNews. From then until the voting closes on November 9th, the candidates will be able to debate ideas on the LATIN.SYSOP echo, as well as on the other region and local sysops' echomail conferences. - From October 22nd until November 9th, all the members of FidoNet Zone 4 will be able to vote for the different candidates -voting for a someone that is not a candidate will void the entire ballot- for the domain where the member is registered (for example, a FidoNet member in Net 900 can vote for NC 900, RC 90 and ZC 4), and they will do so by sending a message to Elecciones at node 4:4/444, whose subject will be a special "secret password" and the text will indicate the different choices. THE VOTE IS SECRET, AND ITS CONTAINTS WILL NEVER BE REVEALED. This is an example of how a ballot must be issued: secret password From: Pedro Picapiedras (4:900/789) | To: Elecciones (4:4/444) | Subj: piedradura <----------------| text | NC: Johny Tolengo <---------------------| RC: Isidoro Canones ZC: Juancho Lagarto - The results from the election will be published on November 11th on the official echomail conference LATIN.SYSOP and on November 12th on FidoNews. A comprehensive list with every ballot listed, to grant the accurateness of the results, will be posted on November 11th on the echomail conference LATIN.SYSOP. This is an example of how a ballot will be published in the comprehensive list: FidoNews 7-41 Page 18 8 Oct 1990 Password NC RC ZC Status ----------------------------------------------------------------- piedradura J.Tolengo I.Canones J.Lagarto OK | will say "VOID" if the ballot is not correct-----------| - The newly elected coordinators will take over their new positions with the nodelist update of November 16th. Pablo Kleinman Latin American FidoNet Coordinator Buenos Aires, October 3, 1990 ----------------------------------------------------------------- FidoNews 7-41 Page 19 8 Oct 1990 Niel Uys FidoNet 5:5/200 FIDOCON 1990 - ZONE 5 Held on 7 September 1990 to 9 September 1990 It is with great pleasure, that I will try and give you a summary of what actually happened at FidoCon 1990! Yes, you would ask, what was the fuzz all about, but let me tell you, it was a great thrill to meet and actually see the faces behind the messages, that we so often take for granted. First and foremost, I would like to thank Grahamstown, and particularly the Rhodes people, for their hospitality, and all the arrangements they made, to please all the delegates, that attended the convention...the very first held on the African continent! At 08:00, we all got registered for the convention, and everybody start to take there seats, while the camera-man puts up his video equipment to record everything to be said and done. First of all, we had Henk Wolsink, our Zone 5 Coordinator, opening the very first convention, in Zone 5. He introduced himself, and mentioned the fact that two speakers couldn't make it. They were Anthony Walker and Stephan Davies. Fortunately, Anthony knew beforehand, that he would probably not make it, and made a video tape, for all to watch, during the convention. He was also the chairman for the first session till tea time. He then talked a bit about the history of FidoNet, and particular , how it started in Southern Africa. He also mentioned how FidoNet grew throughout the world, and how it affected sysops in Zone 5. Then he introduced the Grand Daddy of FidoNet Zone5, Bryan Haefele, who gave a thorough speech about the history of FidoNet in the now called Zone 5 area. It is just a pitty that this speech was not recorded properly, as the sound of the video camera, was not on for this and the next session...but never the less, the people that were there, would hopefully not forget the history lesson. Pat Terry, better known to his students as Professor Terry, gave us a very in depth insight on UFGATE, and how the interfaces between UNIX boxes and FidoNet works. He also talked about the specific connections between zone 1 and zone 5, where Randy Bush was providing the porting of UNIX networks to the zone 1 zonegate, then sending it to Rhodes, using the normal FidoNet dial-up links. FidoNews 7-41 Page 20 8 Oct 1990 Then we had tea...and I got lost while trying to find the lecture room again :-) After tea, and discovering that the camera failed to record sound of the previous session, Pat Terry, the chairman of the second session, introduced Randy Bush, the main speaker of the convention. Pat mentioned about his relationship with Randy, and how he got stuck into Modula-2, first with the Apple II computers, and later the bigger buggers. Randy started off with, a bit of history (again:-) on FidoNet, but talked about Tom Jennings, the father of FidoNet, and how FidoNet started, with his program called Fido (because it was such a dog of a program ). Randy mentioned when he got involved, and mentioned Ben Baker, also one of the pioneers of the olden days. He talked about how regions, and later zones started all over the world, to reduce cost mainly as well as to make distribution more effective. Echomail was also mentioned and how the first echo's came about. IFNA was also mentioned, and what the reason was, why it was started. Echomail wars also started, and IFNA eventually collapsed. He then mentioned the fact that many non-clone machines were used to port FidoNet software, and those users writing their own software, etc. Politics power and policy, is probably one of the biggest problems in FidoNet, Randy mentioned. Zone 5 will have to get more countries connected, so as to change perspective of the rest of the FidoNet world. He talked about all the various zones, and how they operated. Also the fact that zone 3 will split up in to zone 3 and 6 in a friendly manner, also to concentrate the mail links, etc. Zone 4 has a big problem financially, while zone 2 seems the most organised. He then also talked about various other networks, and the fact that FidoNet addressing, were not very intelligent, compared to UUCP, etc. For instance, sending a message to USA.ORIGON.PORTLAND.RANDY would make more sense, than sending it to 1:105/42! This makes sense to me, but might not to others, etc. Bitnet, was for instance based on the IBM proprietary protocols, using 7 bit data bytes, etc. USENET is not a network, and all networks receiving USENET news files, actually belongs to USENET, like FidoNet! FidoNews 7-41 Page 21 8 Oct 1990 Internet was also discussed, and RFC's a bit explained, as well as the current FTS documents, which are to become RFC's eventually. Vic Shaw, of the FRD, was then summoned to give his talk on Uninet. He explained, that the relation between Uninet and Fidonet was excellent. Uninet's mission is to, development, implementation and promotion of an academic and research computer network in Southern Africa. This means, that it's intended for use by Universities, and higher education institutions, etc. This network, is of course sponsored by the FRD (Federation for Research and Development). He then gave credit to FidoNet, which made UNINET into what it is today, although, FidoNet (Zone 5) got quite a few benefits, financially, from Uninet as well. Anthony Walker's tape was then played, where he gave us a chat about his COMNET system, and how it is interfaced with BELTEL, the local prestel dailup system, operated by the P&T. We all, then partook in a general discussion, about FidoNet in general, and ways and means in expanding FidoNet, to the lower levels, like schools, etc. Lunch was then served at the 1820 Settlers Monument building. The Chairman for the afternoon, was Dave Pedler, who is the region 49 Coordinator. He introduced himself, and talked about how zone 5's *C sysops were elected and appointed, when Zone 5 got off the ground in September 1989, etc. Henk Wolsink, our Zone 5 Coordinator, was then called to give his talk about Zone 5, and how it started, etc. The discussion then also turned to why and when points and super users (users using Silver Xpress or XRS) are used, the pros and cons thereof. I then stepped in to give a chat on how echomail links are connected throughout Zone 5 and the rest of the world. We also discussed a bit of history on Zone 5, and what made echomail to be 'magic'. All Zone 5 *C sysops then gathered at the Hotel (Not to drink :-), but to discuss various aspects of the network, mostly difficult to sort out over the network itself. 1. We basically decided that Henk should keep on being the ZC for Zone 5 for another year, unless someone has a complaint about him:-) 2. We also decided, not to allow a Beltel gateway for FidoNet, FidoNews 7-41 Page 22 8 Oct 1990 unless it is going to be READ-ONLY on the BELTEL side. 3. Changing of echo tags like ECHOMAIL, which was always confusing to users. 4. We also decided to follow Randy Bush's advice in changing pick-up and poll times for echomail, excluding the zonegate. This will have a drastic effect on the turnaround time of all echomail in Zone 5. We then drank ourselves, under the table, while the other crowed looked at the Rhodes computer equipment, until the dinner in the same Hotel. No, not really, we just sat there waiting for them :-) And so the day came to a halt? No, we still had a very nice dinner, and it carried on till very late. We had some photo sessions, we even had food! Very nice too, although, I can't remember what we ate, as it was more interesting to chat to each other, about...PC's and computers and FidoNet and BBS's...what else? :-) Anyway, to rap it up, I personally think it was a great success, and I would like to thank each and everyone, attending FidoCon 1990. I sure hope to see you all, and many more, with the next FidoCon. Also great thanks to Rhodes, for hosting the convention, and for the FRD, who sponsored Randy's visit to our Zone. Also many thanks to Randy to take the trouble in getting the FidoCon... great to have had you here, Randy! ----------------------------------------------------------------- FidoNews 7-41 Page 23 8 Oct 1990 C.Lee Duckert & Bruce A. Casner FidoNet 1:139/600 HOMESCHOOL - WHO WOULD DO THAT! A Home Schooling Echo Conference (HOMESCHL) is available on the backbone. There are many reasons for educating children at home. In fact, there are more reasons for educating children at home than there are parents. Who teaches their children at home? There are families who travel or are living overseas. Some think there is too much or too little religion in the public schools. Some live too far out even for school buses to reach them. Still others think that learning and education are two separate activities. Large families, families with an only child, single parents, the rich, the poor, professors and high school drop-outs, atheists and fun- damentalists, capitalists and socialists --- the only things homeschoolers seem to have in common is a particularly strong (but varying) view of the importance of their families and a com- mitment to that oldest form of education - learning at home. The laws regarding home schooling vary from state to state and are always changing. Basically, it is legal. Some localities require curriculum plans filed with school boards and overseen by certified teachers. Others only require an attendance sheet (after all, only school attendance is mandated). Alaska provides home schools with materials and California provides assistance from the local school district; but in most states, you are on your own. Some states require testing or external evaluations. Children who re-enter traditional schools have been doing quite well. This echo is available for all who wish to share ideas, support one another, ask questions and answer them, adults and "students". Child development issues, curricula and methods of dealing with the legal requirements from state to state have all come up for discussion. (Arguments about religion, politics not relating to homeschool issues or the role of public education already have their own echoes and need not call in here.) If you have a child, may some day have a child, know a child or were a child and ever learned or wished to learn anything, homeschooling might interest you. There have been several local echoes across the country dealing with home schools and we are trying to unite them. Voice mes- sages can reach us in the evening (Central Time) at (414)722- 4046. ----------------------------------------------------------------- FidoNews 7-41 Page 24 8 Oct 1990 Rob Duff FidoNet 1:153/713 Loglan Language, Loglan Echo I recently became involved with learning the Loglan language and I decided to support the Loglan Institute by submitting an article about the language in FIDONEWS. James Cooke Brown, the creator of Loglan has given me permission to upload the following article. I have also created a one node ECHO for "lo logli" (loglan people) called as you probably guessed LOGLAN. It is available at 1:153/713. I first heard of Loglan in R.A.Heinlein's book "The Moon Is A Harsh Mistress". When I saw their advertisement in Scientific American magazine, I immediately called the Institute and asked for a price list. When the list came I sent away for just about everything. I am now in the process of learning the language. If you are interested in Loglan, please contact me or the Institute. Rob Duff 1:153/713 What is Loglan?[1] Loglan[2] is a speakable, human language originally designed to serve as a test of the Sapir-Whorf hypothesis that the structure of local human languages places local constraints on the development of human thought, and hence, on human cultures. If this hypothesis is correct, a language which "lifted" those constraints--that is to say, which reduced them to some formal minimum--should in a certain sense "release" the human mind from these ancient linguistic bonds and, in any case, have notable effects on both individual thinking and on the development of a global human culture. Since its original development in the late 1950's and 1960's Loglan has acquired certain other properties that make it interesting to computer science, principally (1) its total freedom from syntactic ambiguity. This feature of the language, together with with (2) its audio-visual "isomorphism" (which means that the Loglan speechstream breaks up automatically into fully punctuated strings of separate words) and (3) its borrowing algorithm (by which the International Scientific Vocabulary goes into Loglan virtually ad libitum) makes it an ideal medium for three uses: (i) for international information storage and retrieval, (ii) for machine-aided translation between natural languages, and (iii) for spontaneous interaction between computer-users and their machines. Finally, Loglan is (4) culturally and politically neutral in the sense that its basic predicate vocabulary has been engineered to be maximally memorable to speakers of the eight most widely spoken languages: English, Chinese, Hindi, Russian, Spanish, French, Japanese and German. FidoNews 7-41 Page 25 8 Oct 1990 All these features taken together have suggested to many loglanists that their adopted language is ideally suited to become a second language for the world. For others, conducting a scientific test of the Whorf hypothesis with Loglan has the highest priority. For still others, its use at the human/machine interface is the most challenging role for Loglan in the years ahead. [1] Reprinted with permission [2] Loglan is a registered trademark of The Loglan Institute, Inc. Books, software, tapes, membership in the institute, and other items are available from: The Loglan Institute, Inc. A Non-Profit Research Corporation 1701 Northeast 75th Street Gainesville FL 32601 U.S.A (904) 371-9574 ----------------------------------------------------------------- FidoNews 7-41 Page 26 8 Oct 1990 Ralph Merritt 1:269/102 Tom Heffernan 1:107/554 On October 27, 1989, a new, MacIntosh oriented network was formed. Named the 'MacIntosh Alternative Connection List', MACLIST was established in the last remaining single-digit Zone address, Zone 6. The current MACLIST nodelist is available to all interested. Just file request 'MACLIST.ARC' from 1:107/554 or 1:269/102. Why was MACLIST formed? There are several reasons we decided to form the MacIntosh Alternative Connection List. Here are some that inspired us to form MACLIST: o The MacIntosh is rapidly entering the world of computer networking. MacIntoshes are located in many different networks, but how to find them? The MACLIST nodelist is a centralized source for you to communicate with other MacIntoshes - simply compile the