Volume 8, Number 17 29 April 1991 +---------------------------------------------------------------+ | _ | | / \ | | /|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 1991, 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 and for the Members of the FidoNet (r) International Amateur Electronic Mail System. 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. EDITORIAL ................................................ 1 Otto-Pilot ............................................... 1 2. ARTICLES ................................................. 2 2nd Democratic Election in Zone-4 ........................ 2 Looking for (Artificial) Intelligence .................... 4 Reply to Snooze 815 ...................................... 7 Your dog walks on water?!? ............................... 11 Z1EC Initial Report ...................................... 19 3. LATEST VERSIONS .......................................... 31 Latest Software Versions ................................. 31 4. NOTICES .................................................. 36 And more! FidoNews 8-17 Page 1 29 Apr 1991 ================================================================= EDITORIAL ================================================================= I'm not really here. I'm in Houston. If you get to read this, it means that MY version of Honey was able to put up with me and with a computing instrument other than a Macintosh for long enough to create your newsletter. She did it while I was screaming into the phone at her ("no, not THAT button! The OTHER button!"), so please be forgiving if the result is less than stellar. Let me apologize in advance, though, if something you sent me didn't get into the newsletter. She's doing a good job, but fixing batch files and (more to the point) reformatting stuff that MAKENEWS doesn't like is not her cup of tea. It will be published next week. All my best from (deep in the heart of) Texas, Vince ----------------------------------------------------------------- FidoNews 8-17 Page 2 29 Apr 1991 ================================================================= ARTICLES ================================================================= Coordinator Elections in Zone-4 Elecciones de Coordinador en la Zona-4 Eleicoes de Coordenador na Zona-4 Next May 12th, Zone-4 Latin America will celebrate its second birthday. I think this time is appropriate for me to resign as Zone Coordinator and call for new elections to choose my successor. The process of election of the new Zone-4 Coordinator will be identical to the one held in November 9th, 1990 in which I was re-elected. The procedures defined for the democratic election process are the following: - All the FidoNet members will be able to present themselves as candidates to the zone coordinator position, by sending netmail to Elecciones at node 4:4/444 until May 10th. - On May 11th, the list of all candidates will be published on the official echomail conference LATIN.SYSOP and on May 13th, on NotiFido, the official Zone-4 sysops' electronic newsletter. From then until the voting closes on May 31st, 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 May 11th until May 31st, all the members of FidoNet Zone 4 will be able to vote for their preferred candidate -voting for someone that is not a candidate will void the ballot- for Zone Coordinator. They will do so by sending a message to Elecciones at node 4:4/444 (region-routing will be enabled to reduce the cost of voting), whose subject will be a special "secret password" and the text will indicate the sysop's choice. 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: Jose Corzo Gomez (4:900/789) | To: Elecciones (4:4/444) | Subj: guantelimpio <---------------| text | ZC: Roque Santeiro <--------------------| - The results from the election will be published on June 2nd on the official echomail conference LATIN.SYSOP and on June 3rd on NotiFido and FidoNews. A comprehensive list with every ballot listed, to grant the accurateness of the results, will be posted on June 2nd on the echomail conference LATIN.SYSOP. This is an example of how a ballot will be published in the comprehensive list: FidoNews 8-17 Page 3 29 Apr 1991 Password ZC Status ------------------------------------------------ guantelimpio R.Santeiro OK(*) (*) Will say "VOID" if the ballot is not correct - The candidate with more votes will become the newly elected Zone Coordinator and will take over his/her new position as arranged with the current ZC. Pablo Kleinman Latin American FidoNet Coordinator Buenos Aires, April 23, 1991 ----------------------------------------------------------------- FidoNews 8-17 Page 4 29 Apr 1991 Looking for (Artificial) Intelligence Bill Keller 1:129/124.0 I guess I should begin this article by introducing myself and stating my reasons for submitting this article. My name is Bill Keller and I run a bbs called ShadeTree in Pittsburgh, PA 15221 (412-244-9416). ShadeTree is oriented solely towards artificial intelligence (AI). Mostly, the people who log on are beginners or amatuers, but they are all enthusiasts. I originally got into AI by way of a "free" magazine. I'm sure you've all received these type of offers, "Try our magazine, the first issue for FREE, if you don't like it, mark "cancel" on the invoice and send it back, there will be no further obligation on your part". Sometimes, I felt almost criminal (notice I said "almost") but it is a good way to take a look at a new magazine before deciding to subscribe. Anyway, the magazine ad I answered was one for PC AI, one of the two big AI related magazines. The issue I received was one of their first on neural nets. Immediately, I was HOOKED!! I started to look around for an inexpensive way to get started in AI. What I found was over priced, over complicated, over hyped programs. Knowing the computer community, I figured that SOMEWHERE, there had to be either shareware or public domain programs available to help me get started. The quest started! What I found was more than a little disheartening. There was VERY little of either type of software out there. Oh, I managed to locate a few expert system shells here and there, and some other miscellaneous files, but there was no CENTRAL place I could go to find the latest release of a shareware program or a new public domain program that had just been released or that maintained a large library of AI oriented programs and files. It was at that point I conceived of ShadeTree. I had been using bbs's for several years, not a lot (I knew from experience how addicting it can be!) but enough to have a very general idea how it worked. One of the local Pgh SysOps helped me get started with OPUS (a GREAT piece of software) and to get my mail and echos set up. At this point, I started searching very seriously. There's the back ground, now for the reason or more correctly, the request. FidoNews 8-17 Page 5 29 Apr 1991 I am asking all the SysOps and users who read this newsletter, to provide me with the following information: 1. What is your FIDONet address and any particulars about your bbs, max baud rate, phone number, hours of operation, city, state and zip code (no addresses unless you want to provide it but with just the city and zip code, many people will be able to tell how close they are to your board), with this info I intend to compile and distribute a file containing a list of boards carrying the various AI related echos so that people can find a bbs close to them 2. Do you participate in any other networks and if so, which ones and what AI related echos are available on that network, for example the RIME network, or RBBS, etc 2. What FIDONet "backbone" AI related echos are you receiving? (The only ones I am aware of are AI, NEURAL_NET, ROBOTIX, if you are aware of any others, please let me know) 3. What "local" AI echos do you have on your board and is there a possibility of that echo becoming a "backbone" echo or would you consider some alternative method of allowing users from all over access to your echo 4. What AI related files do you currently have on your board, please give the program name, author name, version number, size in kb, and a brief description if possible, I am interested in both text files, program files, descriptive files, tutorial files, data files, etc 5. Any of the following topics would be considered AI (although some by only very loose standards): Expert systems / inference engines Neural nets / neural modeling Problem solving Natural language processing Machine vision Pattern processing Decision analysis Robotics Machine learning / understanding Logic and uncertainty / fuzzy logic Genetic algorithms LISP and all it's dialects PROLOG and all it's dialects SmallTalk and all it's dialects Hypertext Speech recognition Speech to text translation and vice versa This list should cover most of the major areas of interest in AI but if you have a file that you're not sure of, better to let me know than to not include it. FidoNews 8-17 Page 6 29 Apr 1991 What I intend to do is start a consolidated repository of AI related materials and keep them as up to date as possible. This can only be accomplished with the help of the network and the individual's willingness to contribute a little time to initially get the project off the ground. Evenutally, I hope to automate the process as much as possible (after all, isn't that what computers are for?) and use some sort of database to track version numbers and releases, etc. I can be reached at either my FIDONet address, 1:129/124.0 or via the U. S. Mail at: ShadeTree BBS c/o Bill Keller 417 Peebles Street Pittsburgh, PA 15221 At this time, ShadeTree is only running from 8:30 PM until 8:30 AM and only at a maximum of 2400 buad. That is another reason to suggest the regular mail as an alternative. I would like to thank you all, in advance of any assistance rendered, for your help and participation in this project. Bill Keller ----------------------------------------------------------------- FidoNews 8-17 Page 7 29 Apr 1991 Garth Kidd 3:680/828@fidonet garth_kidd@f828.n680.z3.fidonet.org Ages ago, I posted a few articles about POLICY, WorldPOL, and whether Z3 should throw some kind of revolution and crawl out from under Z1's wing. This is *nothing* to do with them :-) Well, ok, it is. It's also rather different. This is partially because I'm talking about a few different items. The fact that some rather nice people took the time to debate a couple of issues with me probably helped, too. Thanks, guys. You know who you are. I digress. === AutoNews sounds interesting, Vince. Make sure you put in something that'll flag suspiciously large articles, though. I can just imagine some twit sending you 40k of ^g. === Bob, I like the idea. The main problem is that your proposal is HUGE. It'd be really nice if you trimmed it down to something the average human being couls sit down with, read and comprehend within an hour or two. [Ideally, we should be able to reduce it to "Act Sensibly" :-)] I would have tried to make suggestions and comments on your proposal, but it was simply too large to deal with. Apologies. === Alexander, the main problem with passing the ambiguity buck to the ZCs is that it's exactly that -- passing the buck. Why not correct the problems once now, rather than have to do it in each Zone (or Region, or Net, or...) === Mike, just a point: > WorldPol would have made it much easier to fix. WorldPol > would have given the *Cs more reason to be responsive to > the valid needs of a sysop. FidoNews 8-17 Page 8 29 Apr 1991 To be a member of the *C structure, you need to have a fair bit of time, expertise, and equipment you're willing to donate to the cause. Unfortunately, there aren't a huge number of people who have all the necessary elements handy. The result is a very small number of people to choose from when having an election. Now, when your city has an election, there are a huge number of people who'd like to be the Mayor, and who have the necessary equipment (that is, they're a citizen with spare time). This means that you *can* pressure your Mayor with the threat of being voted out next time 'round, because there are people available to fill their place. You can't so easily discard a *C. First, you have to find someone with the technical nouse and spare time that's willing to take on the job, and that's going to be fairly difficult in a lot of places. It seems to me that a lot of *C's are going to be fairly safe. Ergo, they're not going to be terribly more responsive. === Don, I couldn't agree more. For those who missed what he said, here's perhaps the most important bit: > In sum, I think that WorldPol could probably be reduced > to a third of the current size, and we would end up with > a smaller, more effective document. Take a few moments > and look at WorldPol again. Ask yourself if each section > is absolutely necessary to be controlled at the inter- > national level? If not, why include it? === Dick, I know the feeling. Something's not working quite right. As for the BOMBRUN kludge -- I like it! Take it to NET_DEV and see how people react to it. I'd have a bash, but due to a feed interruption of a strange nature [Paul, I'll netmail you as soon as I've got the time and inclination, but I'll condense: your netmail on the matter *NEVER REACHED ME*, reasons unknown :-(] I won't be able to. Main problem: too much exception handling :-) Also, until people catch on to installing session passwords for anyone they connect to on a regular basis, there's the potential for people to insert fake BOMBRUN messages, which would be a Bad Thing. === Finally, Jack. Incidentally, yours was the article that prompted me to start this multiple reply in the first place. FidoNews 8-17 Page 9 29 Apr 1991 Agreed, we need to get some new software up and running, quick. Correct me if I'm wrong, but it seems that this won't be able to be quickly grafted on at the mail processor level, unfortunately -- we'll need a couple of sneaky changes to the mailers themselves (domain-style addressing, here we come! :-), and some change to BBS software to handle the new-fangled ideas of fully moderated conferences [*] and conference hierachies. Unfortunately, even if you manage to implement a decent replacement [**], you'll still have to get people to switch to it. You don't need me to tell you that this isn't going to be the easiest thing to accomplish. > Trouble is, it seems that all the topics I am > interested in fall into one of three categories: 1) > There's no echo covering it, 2) There's an echo > covering it but it's a dead (or nearly dead) echo, 3) > There's an echo covering it but it's so large and has > so many off-topic or "useless" messages that I just > don't have the time to keep up with it. Is there anyone here who *doesn't* have that feeling? I like the method the USEnet uses to cope. [Warning: this is from what I've seen only. I may have been temporarily visually challenged at the time]. You have the comp.* groups, and various other "official" conference trees. To create a new group in here requires a lot of discussion and manoeuvering. You also have the alt.* tree, in which you create a conference by posting a message to it. All the systems who have the alt.* tree enabled [***] [****] will get it, until they turn it off. I think the software also automatically kills conferences that have been dead for a sufficiently long time. Just excuse me whilst I catch up on my footnotes. === [* Note to people who think that fully-moderated conferences mean double the throughput: this is the case only if you're directly between the moderator and the rest of the world, and the moderator isn't all that choosy. For people at the far reaches, the difference would be negligible, and probably advantageous.] [** Even this is going to be near impossible. I was one of the participants in a rather active discussion in NET_DEV about potential Fido/3 technology. Unfortunately, I've suffered from a "minor" feed cut. Ironically, one of the contributing factors (apart from a rather badly timed and \extremely\ badly placed argument I had with someone) was that transmission failures meant that netmail and echomail warnings on the matter simply didn't make it to my system.] FidoNews 8-17 Page 10 29 Apr 1991 [*** Apart, that is, from the people who've disabled the part of the tree you're in. Example: to create alt.swedish would be fine as long as people didn't have it already in their kill file. Now, creating alt.swedish.chef would be ok, but systems who'd already turned off alt.swedish would never see the new subconference. swedish.chef.bork.bork.bork would be for the true diehards :-) Oh yeah; some people save lots of time and just kill alt.*] [*** Apologies for all of these footnotes. I can't seem to get my text in order these days.] === > But will our software authors ever be able to agree on > any new standard that might be proposed along these > lines? I think not. At least, not in NET_DEV, from what I'd seen just before I left. At the time the feed bottomed out, people were still debating whether a timestamp should be stored as seconds since 1970, a 32-bit bitmapped struct, plaintext, ISO, and if anything remotely binary, which wordsex to use :-( There is one way in which I think it could all be accomplished. Unfortunately, it doesn't leave much of Fido standing :-(. Since a change would be extremely difficult to orchestrate piecemeal, it seems vaguely reasonable to start a new network with the new technology and let it gradually "eat" FidoNet, gating the major conferences and so on. Can anyone think of a better method? Please? That'll do for today. Have a nice day, all. gk ----------------------------------------------------------------- FidoNews 8-17 Page 11 29 Apr 1991 Jack Decker 1:154/8 Fidonet YOUR DOG WALKS ON WATER?!? Well, last week I tried out the AutoNews program that Vince uses, by sending an article via netmail. It worked, but it threw out the blank spaces that I had left between paragraphs. I think that may have happened because my message editor only put a single after each line, no 's anywhere, so this week I'll try manually creating the message to make sure that each line terminates with a CR/LF and see if that helps. In the meantime, Vince, you may want to see if AutoNews recognizes two 's in a row as a blank line. However, for a first attempt, the program worked admirably. [I spoke to the author and he thanks you, both for your kind comments and for your assistance in getting everything straightened out -- Vince] Besides, I did want to make one little comment on Vince's Editorial in FidoNews 8-16. In Vince's reply to Pablo Kleinman, we see the following exchange: [Begin quote:] > I want to believe that Jack Decker's last article is really > pessimistic and not the harsh reality of our network. It's sort of redundant to call Jack a pessimist. Can you see this? Jack goes hunting with you. You shoot a duck. Your dog goes after the duck. When it reaches the water, your dog walks on top of the water, never even leaving a ripple. The dog gets the duck and brings it back to you. Jack says nothing. This happens twice more. You finally ask Jack if he has noticed anything unusual. Jack says, "Yeah. Your dog can't swim." [End quote] What strikes me as amusing about this is that the other day I happened to have the radio on when Rush Limbaugh was on, and he made a comment to the effect that when liberals run out of substance, they start in with personal attacks (for those outside of the U.S.A., Rush Limbaugh is a conservative radio talk show host that is carried on well over 300 radio stations in the U.S. for three hours a day, and who is most noted for having an ego about the size of the planet Jupiter). Anyway, I thinks to myself, that sounds a lot like Fidonet... when they can't assail the logic of what you have to say, they start in with the personal smears. FidoNews 8-17 Page 12 29 Apr 1991 Actually, I realize that my messages may, if taken out of context, sound a bit pessimistic. What I see is that we have a potentially wonderful communications medium here... one that allows people from all corners of the earth to converse with each other with reasonable speed and at fairly low cost. Yet there are problems and in some cases they need to be quantified and solutions need to be found. Consider what would have happened if the Ford Motor Company, after having come out with the Model "T" had said "Now, you folks have something that is better than the horse, and you can afford to buy it, so you should be grateful and not ask for anything more." Actually, from what I've read, that was EXACTLY the attitude of some in that company (I believe it was Henry Ford who said "they can have any color they want, as long as it's black!"). Would anyone doubt that we are better off now because some folks looked at the Model "T" and dared to say "it's wonderful, but it can be improved upon"? So it is with Fidonet... it is wonderful, but it can be improved upon. I have felt, and expressed on many occasions, that there are about four basic things wrong with Fidonet: First, it is too politically motivated. What folks like Vince and some others seem to have a hard time grasping is that there ARE people in the world who seek to acquire any sort of power over others that they can get, and since there are only so many countries in the world, not all of them can aspire to be world dictators. Some will try and manipulate their way to the top of the office political structure at their place of employment, others will try and rise to the top of a local service club, charitable organization, or political group, and still others will try to cling to the top spot of a hobbyist group. Some of these folks get into Fidonet and do manage to get a *C spot and once they get there, they will oppose any policy change that might lessen their supposed power. I think those who have trouble understanding this have simply never been in an organization where one person has clawed their way to the top and then manipulated people like crazy to keep the top spot. I have, and I can tell you that it's no fun to see an organization disintegrate because the top person is driving everyone away. Second, it makes a god (small "g") out of geography. This is out and out idiocy, when referring to an electronic network (no, Vince, I can't vote in Duluth when I live in Sault Ste. Marie... but Fidonet isn't providing my water, fixing my streets, or regulating the zoning around my home. You can't compare physical structures to a structure that can quite reasonably exist in a configuration that pays little regard to geography). (Side note to Pablo... no, I truly believe that MOST common sysops in Zone 1 DON'T want geographic restrictions... and that is EXACTLY why a few are so opposed to WorldPol, because they will lose their enforced power base. FidoNews 8-17 Page 13 29 Apr 1991 They know that if common sysops are given a vote on a Zone-wide policy, they'll never vote for one that contains geographic restrictions, and that scares a few of them to death). Third, it is getting technically stagnant... Fidonet is SO large that we find that we're unable to refine the system to get rid of SEENBY's in messages, have true 5D addressing instead of endless kludge lines, have truly moderated conferences so that the signal-to-noise ratio of conferences can be improved, communicate with the ubiquitous FAX machines around us, enter non-text data in messages, and any of a hundred other improvements that WILL come in time. Just as the Model "T" owner might never have dreamed of having air conditioning, a stereo audio system and cruise control, so we can't imagine what future online communicators will be able to do. The question is, will these advances come from within Fidonet, or will those who want something better be forced into other networks? And if the latter happens, will those in Fidonet then stubbornly snub them and ignore what they're accomplishing? Fourth, it is intolerant of certain political viewpoints. Vince at one point raised the specter of a "whites only" net run by the KKK. Well, far be it from me to defend that group, since I find their ideas repugnant, but since you're so concerned about law, Vince, you ought to ask your lawyer friends about the "slippery slope" principle. Basically, it says that if you can deny any one group the right to be heard (or, in this case, to freely associate) then you have set up a principle that can be used against ANY group. So suppose you write something into Policy that says that special interest nets cannot be formed... not only are you attempting to unreasonably limit freedom of association for no real good reason, but any such policy could be used against groups you might happen to AGREE with. Not only that, but you haven't really stopped the subversive groups from operating - it is very easy to set up and operate a private net using Fidonet technology, that is totally invisible to Fidonet as a whole - so now you've driven them underground where their activities can't be monitored, and where they're less likely to be influenced by those in the larger net that might be able to explain to them and convince them of the error of their ways. In the meantime, is it right to let our fear of extremist groups cause us to set up a mechanism whereby those who hold political viewpoints we find simply disagreeable may be harassed or excluded? I'm hoping for better things from Fidonet... but it's not going to happen as long as we operate as though all that HAS been achieved is all that CAN be achieved. We've come through the Model "T" stage, but there are a lot of improvements that can be made, both in the technology and the political structure of Fidonet (and hopefully we can avoid the tailfins!). FidoNews 8-17 Page 14 29 Apr 1991 ***** A couple of other notes only semi-related to the above: First, Pablo mentioned Jason Steck, who was at one point working on another Policy document. My impression is that Jason has decided that his time would be better spent working in MetroNet, an alternative Fidonet-technology network that's a bit unique in some ways. For example, Jason tells me that they have their own UseNet-MetroNet gateway and are the only Fidonet-technology network other than Fidonet itself to have a registered domain in the Internet (I hope I'm stating this correctly, I'm repeating this from my memory of a phone conversation). Also, I gather that the MetroNet folks are working on a practical implementation of a new packet type that will be backward compatible with existing Fidonet technology, but that will offer several of the innovations that have been suggested in various forums from time to time. In any event, if you are interested in furthering the technology and are running into roadblocks (political or otherwise) in Fidonet, you might contact Jason Steck at Fidonet 1:104/424 and see what they're up to (however, if you're the typical NET_DEV type that like to argue about formats, structures, etc. ad nauseum but never gets around to writing a line of code, don't bother... I don't think they either need or want those types around!). Second, I have to wonder why some of the sysops who believe in carrying political discussions that cover all sides of the political spectrum haven't asked for some political echoes to balance out some of the echoes that are already carried. Please consider that there are plenty of "issues oriented" echoes such as ABORTION, ANIMAL_RIGHTS, BEYOND_WAR, ECOLOGY, ECONET, ENVIRO, ENVIRON, FEMINISM, GAYLINK, GAYNEWS, ICGAL, INDIAN_AFFAIRS ... and on and on, and if you understand the difference between the political right and the political left, you can easily see that Fidonet is pretty one sided (not necessarily from the TITLES of some of the echoes, but from their content). Now maybe this is intentional, but I certainly hope not. So I'd like to suggest that maybe we should think about having some echoes that might bring more of a political balance to Fidonet. Here are some ideas I've had, you might think of more: EDU_CHOICE - For those who support the idea of parental choice in education, and would like to discuss the reasons for it and the ways in which it could be implemented. PEOPLE_FIRST - An echo to keep track of and expose the activities and motives of some of the fringe groups that believe that humanity is a cancer on the planet (such as the groups that believe that animal research is never justified, even if it means we never find a cure for AIDS, etc.). In other words, to count the cost to people and society if some of the goals of the far left groups are achieved, without necessarily having to rely upon their statistics. FidoNews 8-17 Page 15 29 Apr 1991 DITTOS - an echo for listeners and fans of the Rush Limbaugh radio talk show, for further discussion of issues that have been raised on that program. Those who've heard the program will recognize the significance of the tag. If we can have echoes for fans of "Star Trek", why not one for fans of a popular talk show host? (by the way, in case you're wondering, no I do NOT agree with everything he says... but it's certainly an INTERESTING show to listen to, when I get the chance). My point is that if we are going to carry issue-oriented political echoes, let's have them cover the whole political spectrum and not be quite so one-sided. There ARE two (or more) sides to most issues, after all. Well, that's enough for one week. Let's see if Autonews eats the blank lines in this article! [It did. I did a quick once-over to put at least some of them back -- Vince] --- via AutoNews 0.1 ----------------------------------------------------------------- FidoNews 8-17 Page 16 29 Apr 1991 "Ramblings of a Dictatorial Megalomaniac" or "It's about time for Policy6, Godammit" Luke Kolin, NC250 1:250/714@fidonet "I thought it sucked, but Wayne here thought it sucked donkeys." -- Dana Carvey, playing Garth on SNL's "Wayne's World" Garth may be talking about movie reviews, but perhaps Worldpol is also appropriate in this case. As a Zone 1 *C, I've been quite offended by the rhetoric that's been floating around regarding WorldPol, and I feel that it's time that I speak my two bits' worth. Before I begin, I want to state for the record that regardless of wether WorldPol passes or fails, we will be planting the seeds for future discontent within FidoNet. If it fails, it will be widely perceived as yet another example of Zone 1 imposing its will upon FidoNet. If it passes, it will be further proof that the largest group of FidoNet sysops have been effectively disen- franchised by a gerrymandered voting system. Net 250 is larger than quite a few regions, but while they may have 2 to 4 votes, we only have one. Is that fair? So I think it's time to look beyond WorldPol. Because if we look upon this vote as the be-all and end-all, there will be a lot of po'd people in FidoNet. We got that with Policy4, and what came out of that was Policy5, aka WorldPol. Documents created out of resentment and frustration are inherently flawed, and unless we look beyond WorldPol NOW, Policy6 will end up the same way. For the record, I voted against WorldPol. I don't support making a completely new policy. I believe that Policy4 can do the job, with ammendments. Why start from scratch when we have the cumula- tive efforts of many man-years lying around, only to be modified as needed? Therefore, I support a Policy6 based on Policy4, with the following fundamental changes. Call them a Sysop's Bill of Rights. o DEMOCRATIC ELECTION OF THE *C STRUCTURE. FidoNet's a hobby. Or a club. And it only stands to reason that FidoNet sysops should be able to choose their representatives. Therefore, Policy4 should be ammended to ensure that NCs and RCs are elected by a vote of all sysops within their respective Net/Region. ZCs will be elected by a vote of all *Cs within their Zone. o GEOGRAPHICAL NETWORK BOUNDARIES. Within Region 12, we have been attempting to institute strict geographic boundaries for networks. For people to say in FidoNews that geographic boundaries force people to deal with bad *Cs is a blatant insult to the efforts of the NCs and RCs of Region 12 since 1988. Allowing nodes to join any network they wish only encourages the rise of cliques, and networks based on politics and infighting. It encourages NCs to discriminate on who they wish to accept into "their" Nets. If we FidoNews 8-17 Page 17 29 Apr 1991 make georgraphy the sole criterion for network membership, we make sure that FidoNet is accessible to all. Equally. If an NC cannot live with that, he should be axed immediately. o FIDONET IS FREE. Several previous articles in FidoNews have mentioned several networks who charge an admissions fee to join. No node should be forced to pay to join or remain in FidoNet, nor should they be forced to pay for any mandatory echo conferences. We are an amatuer network, accessible to all at least at a basic level. That should be a fundamental right. o A NEW AMMENDING FORMULA. There's a problem with the way FidoNet is structured right now. Zone 1 has a grand total of ten regions and six thousand people, while Zones 4 and 5 have regions that are hard pressed to qualify as networks up here. So why should they have the same voting rights? I think it's time for an ammending formula that protects both minorities in FidoNet: a minority of sysops outside Zone 1, and a minority of *C beings inside Zone 1. Let's keep the method of putting ammendments up for vote the same. A lot of RCs are good people who'll support a vote even if they are going to vote NO. However, when it comes down to the actual vote, why don't we say that to pass, a policy must meet with the approval of a majority of *Cs in each zone. To boot, the NCs' votes must represent a majority of sysops in that zone. That way, policies cannot be passed by the simple virtue that one zone has a plethora of tiny zones. So let's drop WorldPol. It reeks of an atitude saying, "Let's make sure Zone 1 never screws us over again." Let's go back to the time-honored method of taking what we have, and improving it, to make something even better. I also support the idea of condensing policy. For example, in Net 250 I have published a little 2K guide to FidoNet. I don't see why we should force all sysops to read the entire policy document, when most of the time a little guide will do. To this end, I propose two versions of Policy6. The first would be a very short explanation of FidoNet to the new sysop, and the second could be as large as you want. Since most sysops will never read the second, it can be *C-oriented, taking into account all facets of FidoNet. Rather than taking about demo- cratic elections according to "western standards", let's write a full elections policy. We have. Rather than making provisions for zonal, regional, or network policies, let's just make one broad-based one. If you follow the basic principles in it, and the few specifics (like elections), the other stuff is up to you. WorldPol must fail. Much bitterness will be aroused pass or fail, but I'd rather be bitter that a flawed document did not pass. Let's start with Policy4 again, change it to reflect the new FidoNet, and live with that. FidoNews 8-17 Page 18 29 Apr 1991 ----------------------------------------------------------------- FidoNews 8-17 Page 19 29 Apr 1991 Tony Davis Z1EC 1:1/200 After the first month of performing the duties of Zone One Echomail Coordinator, I felt some information on how the system is progressing was in order. The first month has been extremely interesting. In the first 30 days, I have received in excess of 200 netmail messages concerning policies, procedures, complaints, suggestions, adding an echo to the backbone, removing an echo to the backbone, moderators requesting links be cut, users requesting moderators be replaced, etc. Very few (less then 5) actually concerned with coordination of traffic flow. One fact became the extremely clear. That was that in the absence of a recognized, approved echo policy and no other documentation; that I would be subject to making many judgement calls. The only mathematical certainty is that if many judgement calls are made, some will be incorrect. In an effort to remove myself from the position of judge, jury, and executioner that the numerous requests asked me to be and place me in the position of administrator that I was elected to, I contacted all the RECs and asked their guidance of exactly how they wanted me to handle the position. The general opinion that came from these discussions was that the *EC structure did not have the right to dictate a mandatory Echo Policy. It also became obvious that even if we could not set a zone wide policy, that a document that described the operation of the backbone, and explained to the general sysop exactly what they could expect from the backbone was necessary. A set of backbone procedures was written, and put up to a vote of all RECs. The procedure were adopted by an absolute majority of current RECs. The document prepared is not intended to be a general echo policy, it is designed as an informational document to explain the self-imposed rules the Zone One Backbone will operate under. If at any time, the net does adopt a general echo policy, the net approved policy will either replace this Backbone Operation Procedure document or changes in the document will be made for it to comply with the general echomail policy. The document lays out specific requirements that an echo must meet in order for it to be distributed by the backbone, on the balance side, it also lays out exactly how to remove the echo from any restrictions the moderator of an echo feels the backbone places on him (or her). FidoNews 8-17 Page 20 29 Apr 1991 Any one that disagrees with any segment of that document, and would like to see a change, deletion, or addition, please contact your REC. The document itself was designed to be a "living" document, and changes may be made to it quickly and easily. The procedures to initiate changes are described in the document itself. One side note: The document was not authored by the ZEC, it is a collection of parts supplied by different RECs. As ZEC, I accepted the mandate of the RECs to implement the document. Respectfully, Tony Davis Z1EC ZONE ONE BACKBONE OPERATION PROCEDURES Revision: 1.01 Effective Date: May 1, 1991 PROLOGUE This document sets forth procedures followed by the Zone One Backbone Echomail System. If any item in this document are in conflict with any existing or subsequent General Fidonet Policy, then General Fidonet Policy will be in effect. This document addresses echomail at the zone level. It is not a General Echomail Policy. This document makes no attempt to address any issues below the "Backbone Level". 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 at the zone level, the Backbone was formed. As a result of the growth of Fidonet and the increase in the volume of echomail, it has become necessary to set forth operational procedures to allow the general Fidonet sysop to know what services he can expect from the Backbone. FidoNews 8-17 Page 21 29 Apr 1991 II. DEFINITIONS 1. GENERAL FIDONET POLICY: The document which governs Fidonet as adopted by Fidonet. The document as of this writing is Policy 4 and is subject to change. 2. NODE: A Fidonet member, as per General Fidonet Policy. 3. ECHOMAIL: A form of mail in which message bases are shared between independent systems with unique Net/Node addresses. 4. ECHOMAIL CONFERENCES: An echomail conference is a message base or forum, distributed under a specified echomail conference name, dealing with a defined area of interest. Echomail conferences are hereafter referred to simply as conferences. Examples include COMM, an inter-zone telecommunications conference, and POLITICS, a zone level political conference. 5. ZONE ECHOMAIL COORDINATOR: This individual is responsible for coordination of echomail at the zone level. The Zone Echomail Coordinator is hereafter referred to simply as the ZEC. 6. REGION ECHOMAIL COORDINATOR: This individual is responsible for coordination of echomail at the region level. The Region Echomail Coordinator is hereafter referred to simply as the REC. 7. NET ECHOMAIL COORDINATOR: This individual is responsible for coordination of echomail at the net level. The Net Echomail Coordinator is hereafter referred to simply as the NEC. 8. ECHOMAIL HUBS: These are nodes who distribute echomail. The Echomail Hubs are hereafter referred to simply as Hubs. The Zone Hubs distribute echomail at the zone level. The Region Hubs distribute echomail at the region level. The Net Hubs distribute echomail at the net level. 9. CONFERENCE MODERATORS: These individuals preside over conferences. Conference Moderators are hereafter referred to simply as Moderators. 10. RESTRICTED DISTRIBUTION CONFERENCE: A restricted distribution conference is one which is restricted only to eligible recipients. Examples include MODERATOR, a pre-register conference for Moderators, and MEADOW, a conference for Opus Sysops. 11. ZONE ONE ECHOMAIL BACKBONE: The Zone One Echomail Backbone consists of Zone Hubs (commonly referred to as "Stars") and the Regional Hubs (who directly connect to the "Stars"). The Zone One Echomail Backbone is hereafter referred to simply as the Backbone. FidoNews 8-17 Page 22 29 Apr 1991 12. ZONE ONE ECHOMAIL CONFERENCE LIST: The Zone One Echomail Conference List identifies the registered zone level conferences. The Zone One Echomail Conference List is hereafter referred to simply as the Echolist. 13. ZONE ONE ECHOMAIL CONFERENCE LIST COORDINATOR: This individual is responsible for the Zone One Echomail Conference List. The Zone One Echomail Conference List Coordinator is hereafter referred to simply as the Zone Echolist Coordinator. 14. ECHOMAIL GATEWAYS: These are nodes whose systems are used to exchange mail with other groups. The term Echomail Gateway, as used hereafter, shall include all forms of gating, including, but not limited to, zone-gating, inter-network gating, and domain-gating. 15. VOTE: Any vote shall be carried out in a fair and decent manner. A good faith attempt shall be made to make all eligible voters aware that a vote is about to occur and to make available all necessary information. At a minimum, this notice shall be posted in the REC conference 7 days prior to the start of the voting period. The voting period shall be 7 days. 16. ABSOLUTE MAJORITY: The term absolute majority means more than 50 percent of those eligible to vote. III. DUTIES OF ZONE ECHOMAIL COORDINATOR, ZONE HUBS, ZONE ECHOLIST COORDINATOR, REGIONAL COORDINATORS AND MODERATORS 1. DUTIES OF ZONE ECHOMAIL COORDINATOR: The ZEC shall coordinate echomail distribution at the zone level. This includes coordinating the transmission and routing of echomail so that it is done in a manner so as to avoid creation of duplicate messages within a conference. The ZEC shall make available, to any region, any conference which that region is eligible to receive. If for any reason the ZEC does not have access via recognized distribution channels to a specific conference, he can not be expected to provide it. An exception is that the ZEC is not required to make available any conference which routinely contains messages which are encrypted or illegal. Nothing in this provision requires that a ZEC or Zone Hub must import any conference to the extent of adverse economic impact. The ZEC shall recognize conferences at the zone level. The ZEC shall maintain a list of available conferences at the zone level as well as the requirements of each conference as supplied by the Moderator (Echolist). FidoNews 8-17 Page 23 29 Apr 1991 The ZEC shall appoint Zone Hubs (Stars) to distribute echomail at the zone level. The ZEC may also serve as a Zone Hub, but is not required to do so. The ZEC shall make available a minimum of one connection to each "Star", to each region. Each Region is not required to use all available connections, but it is the ZEC's responsibility to insure that the connections are available. 2. DUTIES OF ZONE HUBS: All systems designated as Zone Hubs (Stars) by the ZEC will be required to allow a single direct connection from each region as requested by the REC of each region. Zone Hubs may act as Regional Hubs and/or File Distribution systems only if such actions do not interfere with the primary duties of Zone Echomail Distribution. Zone Hubs will make any conference available that has been designated a "Backbone Conference" by the ZEC. Zone Hubs will distribute a text file named "FIDONET.NA" that is a list of all Conferences available from the Zone Hubs. 3. DUTIES OF ZONE ECHOLIST COORDINATOR: The Zone Echolist Coordinator shall compile and make available the Echolist. This is a registry of zone level and inter-zone conferences, updated monthly, and optionally, conferences at various other levels. The content and format of the Echolist will be at the sole discretion of the Zone Echolist Coordinator, except that it shall include the conference name, the Moderator's name, a netmail address listed in a publicly available nodelist of any network where the Moderator may be reached, a general description of the conference topic, eligibility requirements for restricted conferences, network of origin for conferences which originate outside of Fidonet, distribution plan if other than via the Backbone, and rules for each conference. 4. DUTIES OF REGIONAL ECHOMAIL COORDINATORS: This Document details the REC's duties in relationship to the Backbone, only. The REC shall coordinate echomail distribution at the regional level. This includes coordinating the transmission and routing of echomail so that it is done in a manner so as to avoid creation of duplicate messages within a conference. The REC shall make available, to any net, any conference which that net is eligible to receive. If for any reason the REC does not have access via recognized distribution channels to a specific conference, he can not be expected to provide it. An exception is that the REC is not required to make available any conference which routinely contains messages which are encrypted or illegal. FidoNews 8-17 Page 24 29 Apr 1991 Nothing in this provision requires that a REC or Regional Hub must import any conference to the extent of adverse economic impact. The REC shall appoint Regional Hubs to distribute echomail at the regional level. The REC may also serve as a Regional Hub, but is not required to do so. The REC designates the systems that will have the direct connections to the Zone Hubs. In the event the REC feels his region needs more than one connection per Zone Hub, he may request an additional connection. Any such connection will be granted on a space available basis. Each such request will be looked at on a case-by-case basis. 5. DUTIES OF MODERATORS: Moderators shall make, in good faith, every reasonable effort to insure that their conferences do not distribute or promote illegal activities or information as defined in Section V, Paragraph 2. Moderators shall publish the conference rules in their conferences at least once a month. Moderators shall be responsible for seeing that messages contained in their conferences correspond to the conference's theme. Moderators shall not fail to perform their duties for a period of more than 10 days without failing to designate proxies. Moderators are encouraged to appoint Co-Moderators to assist them in their duties. If the Moderator is not a member of Fidonet, he must list an address in a publicly available nodelist of any network, that he may be contacted if the need arises. Moderators shall report any violations of these procedures to the proper Echomail Coordinators and lodge any appropriate policy complaints as provided for in General Fidonet Policy. If a Moderator believes that a Node is violating a conference rule, he may authorize the feed to that Node be severed. This authorization shall be made in direct written form (netmail), to the Hub feeding the offending Node, with a copy to the offending Node. IV. SELECTION OF ZONE ECHOMAIL COORDINATOR, ZONE ECHOLIST COORDINATOR AND MODERATORS 1. GRANDFATHER CLAUSE: The ZEC, Zone Echolist Coordinator and Moderators currently holding these positions as of the date of acceptance of this document shall continue to serve in said capacity. FidoNews 8-17 Page 25 29 Apr 1991 For the purpose of calculating the term of office, such term will be deemed to have started on the date that this document goes into effect. 2. SELECTION OF THE ZONE ECHOMAIL COORDINATOR: The ZEC shall serve for a term of 1 year. He shall be elected as follows: A) Upon resignation or replacement of the existing ZEC, the Zone Coordinator (ZC) shall oversee the election of the new ZEC. B) After the nominees are selected, an election shall be held. The ZEC will be elected by a absolute majority of the RECs. The current ZEC can be identified from the 1/200 listing in the Nodelist. 3. REMOVAL OF THE ZEC: The ZEC may be removed from his position by a absolute majority of the RECs. The ZC will oversee the recall election in the same manner as prescribed for electing the ZEC. The ZEC may only be subject to recall for failure to properly carry out his duties described above, or if he is no longer a member of Fidonet. A promise of "free" echomail delivery from another source is not considered an acceptable reason for recall. A ZEC may be removed by the ZC for continued violations of policy or for gross misconduct. 4. SELECTION OF THE ZONE ECHOLIST COORDINATOR: The ZEC shall appoint the Zone Echolist Coordinator. The current Zone Echolist Coordinator can be identified from the 1/201 listing in the Nodelist. 5. SELECTION OF A MODERATOR: A Moderator shall be selected as follows: A) Upon formation of a conference, the person who forms the conference is the Moderator. B) Upon resignation or replacement of an existing Moderator, the conference's rules shall define how the new Moderator is selected. A Moderator need not be either a sysop, or a member of Fidonet. A Moderator must have an netmail address in a publicly available nodelist where netmail concerning the conference may be sent. FidoNews 8-17 Page 26 29 Apr 1991 V. STATEMENT OF POLICIES 1. BASIC ECHOMAIL POLICY: The basic policy of echomail is to promote communication in conferences in a lawful, friendly manner consistent with the general principles of Fidonet. 2. PROHIBITION ON ILLEGAL ACTIVITIES: Knowingly distributing, or allowing to be entered into conferences, any messages containing or promoting illegal activities or information, is a serious violation of this document. 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. CENSORSHIP: Removing a message from a conference, or altering its contents, in the passing or distribution of echomail, is considered a serious violation of this document. An exception to this provision is the deletion of messages, by any Node, which may lead to legal action against that Node. Textual changes to such messages are not allowed. An additional exception to this provision is the deletion of messages, by any Node, which do not meet the echomail message standards in Section V, Paragraph 13. Textual changes to such messages are not allowed. Under no circumstances shall echomail be modified in any manner which could potentially cause duplicates. 4. COUNTERFEIT MESSAGES: Entering or knowingly distributing counterfeit messages is a serious violation of this document. 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. 5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit from the passing or distribution of echomail shall be deemed to be excessively annoying and in violation of General Fidonet Policy. Profit is defined as the charging for echomail distribution in excess of the 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. Nodes who charge users for access to their BBSs shall not be in violation of this paragraph. 6. RESTRICTED DISTRIBUTION CONFERENCES: Participating Nodes shall honor and support the restrictions placed upon restricted distribution conferences. Violation of this restriction by individual Nodes is a violation of this document and shall result in suspension of that Node from the violated echo in accordance with Section III. FidoNews 8-17 Page 27 29 Apr 1991 A violation of the restrictions placed on a restricted distribution conference will be a violation of this document only if the Moderator has posted the restrictions governing the conference both in the conference and in the Echolist. 7. PATHLINE OPTION: The PATHline (as defined in FTS-0004), is recommended for all Nodes, but is required for any node directly connected to a Zone Hub (Star). 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 ZEC feels that the topology allows their use. The stripping of SEEN-BYs (except by Echomail Gateways) is not allowed unless approved by the ZEC. Echomail Gateways shall strip the SEEN-BYs of the exporting group to reduce addressing conflicts. 9. ECHOMAIL SOFTWARE: using echomail software which does not conform to the minimum acceptable standards as defined by the Fidonet Technical Standards Committee (FTSC), and by this Section, is a violation of this document. 10. INTER-NETWORK CONFERENCES: It is the general policy of Fidonet to encourage the development of Inter-Network Conferences. Inter-Network Conferences shall conform to General Fidonet Policy, as well as the provisions of this document, in addition to any foreign network's provisions. It shall be the duty of those providing the Inter-Network Conference links to remove foreign network distribution identifiers which will adversely effect the distribution of the conference while in Fidonet. The Inter-Network Conference links maintained in Fidonet shall be operated such that they do not interfere with the foreign network's distribution of echomail. Conferences which originate outside of Fidonet must be designated as such in the Echolist. Echomail Gateways must be able to pass netmail through the Gateway into the other network, unless it is technically impossible to do so. 12. ADDING OR REMOVING CONFERENCES FROM THE BACKBONE: A conference may be added to the Backbone only at the request of the Moderator. A conference must have a Moderator, be listed in the Echolist, and its addition requested by two or more RECs, before it is added to the Backbone by the ZEC. The Moderator may, at his discretion, request that his conference be removed from the Backbone. The ZEC shall honor such requests. FidoNews 8-17 Page 28 29 Apr 1991 A conference will be removed from the Backbone when fewer than 2 RECs carry it. The ZEC may also remove a conference from the Backbone due to lack of traffic (under 10 messages over a two month period). A conference is subject to removal from the Backbone when the Moderator fails to properly carry out his duties, as described as described in Section III, or violates Section V. A conference is subject to removal from the Backbone if its listing in the Echolist is not current. NOTE: To allow time for all existing Backbone conferences to be listed in the Echolist, no such conference will be removed from the Backbone for a grace period of 120 days from the issuance of this document. 13. ECHOMAIL MESSAGE STANDARDS: Until the adoption of a superseding 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) There should be only one tear line in a message. Tear lines should be limited to 25 characters including the required "--- " lead-in. Tear lines 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. C) There should be only one origin line in a message, except as noted in the next paragraph. Origin lines should be limited to 79 characters including the required " * Origin: " lead-in and ending of a proper network address (i.e. Zone:Net/Node.Point with zone and point being optional), enclosed in parenthesis. D) "Extra" origin lines are allowed when a message is gated. The original origin line's lead-in should be changed to " # Origin: ", and the Echomail Gateway's origin line added. There may be more than one extra origin line in the case that a message passes through multiple Echomail Gateways. FidoNews 8-17 Page 29 29 Apr 1991 The Echomail Gateway's origin line is limited to essential information only. This consists of the required lead-in, the network name, "Gateway", a proper Fidonet address (i.e. Zone:Net/Node with zone being optional), enclosed in parenthesis. Example: " * Origin: TComm Gateway (1:372/666)". E) SEEN-BY addresses should be in sorted order. 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. 14. NETMAIL ROUTING: It is important that users have access to routed netmail in order to facilitate private replies to echomail messages. This helps reduce overall echomail message volume by allowing off-topic replies, flames and other types of messages which don't belong in the conference, to be sent via routed netmail. Until such time as a new General Fidonet Policy is adopted which defines and codifies the routed netmail scheme, the following shall be in effect: A) Zone Hubs and Regional Hubs shall accept routed netmail from any Node or Hub who exchanges Backbone conferences with them. Routed netmail may be routed along echomail paths, or to a ZC, RC, or NC who has agreed to handle such mail. Any netmail message with a valid Fidonet destination will be accepted. Refusal of netmail based a non-Fidonet origin will not be allowed. B) At the present time, routed netmail is provided by both the Coordinator and Echo Coordinator structures. The ZEC shall cooperate with the Coordinators and the Echo Coordinators in further developing and maintaining a routed netmail scheme. 16. FEEDING SEVERED NODE: Knowingly feeding a conference to a Node who has been severed for violations of this document or at the request of the Moderator, where such feed is intended to subvert either the provisions of this document or the authority of the moderator, is considered a serious violation of this document. VI. ENFORCEMENT FidoNews 8-17 Page 30 29 Apr 1991 Enforcement of this document shall be under the provisions of General Fidonet Policy. Serious violations of these procedures shall be considered excessively annoying under General Fidonet Policy. Complaints concerning violations defined under these procedures may be filed by the aggrieved individual, the Moderator or by any level of Echomail Coordinator to the appropriate IC, ZC, RC or NC level. All complaints made pursuant to this document 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 ZEC or respective REC, as appropriate. Enforcement of these procedures are immediate, with any currently existing software allowed 90 days to conform (from the date this document goes into effect). 30 day extensions 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 is a serious violation of this document. VII. CHANGES Future changes to these procedures may be proposed by any Node, by submitting the proposal to any REC. The REC will then determine if the proposal should be brought before the rest of the RECs. If two RECs concur with the proposed change, the change must be brought to a vote of all RECs. A absolute majority vote of the RECs is required in order for a change to be implemented. ----------------------------------------------------------------- FidoNews 8-17 Page 31 29 Apr 1991 ================================================================= LATEST VERSIONS ================================================================= Latest Software Versions MS-DOS Systems -------------- Bulletin Board Software Name Version Name Version Name Version DMG 2.93 Phoenix 1.3 TAG 2.5g Fido 12s+ QuickBBS 2.66 TBBS 2.1 GSBBS 3.02 RBBS 17.3B TComm/TCommNet 3.4 Lynx 1.30 RBBSmail 17.3B Telegard 2.5 Kitten 2.16 RemoteAccess 1.00* TPBoard 6.1 Maximus 1.02 SLBBS 1.77A Wildcat! 2.55 Opus 1.14+ Socrates 1.10 WWIV 4.12 PCBoard 14.5 SuperBBS 1.10 XBBS 1.17 Network Node List Other Mailers Version Utilities Version Utilities Version BinkleyTerm 2.40 EditNL 4.00 ARC 7.0 D'Bridge 1.30 MakeNL 2.31 ARCAsim 2.30 Dutchie 2.90C ParseList 1.30 ARCmail 2.07 FrontDoor 1.99c Prune 1.40 ConfMail 4.00 PRENM 1.47 SysNL 3.14 Crossnet v1.5 SEAdog 4.60* XlatList 2.90 DOMAIN 1.42 TIMS 1.0(Mod8) XlaxDiff 2.35 EMM 2.02 XlaxNode 2.35 4Dog/4DMatrix 1.18 Gmail 2.05 GROUP 2.16 GUS 1.30 HeadEdit 1.18 IMAIL 1.10 InterPCB 1.31 LHARC 2.10 MSG 4.1 MSGED 2.06 MSGTOSS 1.3 Oliver 1.0a PK[UN]ZIP 1.20 QM 1.0 QSORT 4.03 ScanToss 1.28 Sirius 1.0x SLMAIL 1.36 StarLink 1.01 TagMail 2.41 FidoNews 8-17 Page 32 29 Apr 1991 TCOMMail 2.2 Telemail 1.27 TMail 1.15 TPBNetEd 3.2 TosScan 1.00 UFGATE 1.03 XRS 4.10* XST 2.3e ZmailH 1.14 OS/2 Systems ------------ Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Maximus-CBCS 1.02 BinkleyTerm 2.40 Parselst 1.32 ConfMail 4.00 EchoStat 6.0 oMMM 1.52 Omail 3.1 MsgEd 2.06 MsgLink 1.0C MsgNum 4.14 LH2 0.50 PK[UN]ZIP 1.02 ARC2 6.00 PolyXARC 2.00 Qsort 2.1 Raid 1.0 Remapper 1.2 Tick 2.0 VPurge 2.07 Xenix/Unix ---------- BBS Software Mailers Other Utilities Name Version Name Version Name Version BinkleyTerm 2.30b Unzip 3.10 ARC 5.21 ParseLst 1.30b ConfMail 3.31b Ommm 1.40b Msged 1.99b Zoo 2.01 C-Lharc 1.00 FidoNews 8-17 Page 33 29 Apr 1991 Omail 1.00b Apple II ---------- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version GBBS Pro 2.1 Fruity Dog 1.0 ShrinkIt 3.23* DDBBS + 5.0 ShrinkIt GS 1.04 deARC2e 2.1 ProSel 8.66* Apple CP/M ---------- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Daisy v2j Daisy Mailer 0.38 Nodecomp 0.37 MsgUtil 2.5 PackUser v4 Filer v2-D UNARC.COM 1.20 Macintosh --------- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Red Ryder Host 2.1 Tabby 2.2 MacArc 0.04 Mansion 7.15 Copernicus 1.0 ArcMac 1.3 WWIV (Mac) 3.0 LHArc 0.41 Hermes 1.5 StuffIt Classic 1.6 FBBS 0.91 Compact Pro 1.30 Precision Systems 0.95b* TImport 1.92 TeleFinder Host 2.12T10 TExport 1.92 Timestamp 1.6 Tset 1.3 Import 3.2 Export 3.21 Point System Software Sundial 3.2 PreStamp 3.2 Name Version OriginatorII 2.0 FidoNews 8-17 Page 34 29 Apr 1991 AreaFix 1.6 Copernicus 1.0 Mantissa 3.21 CounterPoint 1.09 Zenith 1.5 Eventmeister 1.0 TSort 1.0 Mehitable 2.0 UNZIP 1.02c Zip Extract 0.10 Amiga ----- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Falcon CBBS 0.45 BinkleyTerm 1.00 AmigArc 0.23 Paragon 2.082+ TrapDoor 1.50 AReceipt 1.5 TransAmiga 1.07 WelMat 0.44 booz 1.01 ConfMail 1.12 ChameleonEdit 0.10 ElectricHerald1.66 Lharc 1.30 Login 0.18 MessageFilter 1.52 oMMM 1.49b ParseLst 1.64 PkAX 1.00 PolyxAmy 2.02 RMB 1.30 Roof 44.03 RoboWriter 1.02 Rsh 4.06 Skyparse 2.30 Tick 0.75 TrapList 1.12 UNZIP 1.31 Yuck! 1.61 Zippy (Unzip) 1.25 Zoo 2.01 Atari ST/TT ----------- Bulletin Board Network Node List Software Version Mailer Version Utilities Version FIDOdoor/ST 2.2.3* BinkleyTerm 2.40l ParseList 1.30 QuickBBS/ST 1.02 The BOX 1.20 Xlist 1.12 Pandora BBS 2.41c EchoFix 1.20 GS Point 0.61 sTICK/Hatch 5.50* LED ST 1.00 MSGED 1.96S FidoNews 8-17 Page 35 29 Apr 1991 Archiver Msg Format Other Utilities Version Converters Version Utilities Version LHARC 0.60 TB2BINK 1.00 ConfMail 4.03 LHARC2 3.18* BINK2TB 1.00 ComScan 1.02 ARC 6.02 FiFo 2.1m* Import 1.14 PKUNZIP 1.10 OMMM 1.40 Pack 1.00 FastPack 1.20 FDrenum 2.2.7* Trenum 0.10 Archimedes ---------- BBS Software Mailers Utilities Name Version Name Version Name Version ARCbbs 1.44 BinkleyTerm 2.03 Unzip 2.1TH ARC 1.03 !Spark 2.00d ParseLst 1.30 BatchPacker 1.00 + Netmail capable (does not require additional mailer software) * 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 8-17 Page 36 29 Apr 1991 ================================================================= NOTICES ================================================================= The Interrupt Stack 12 May 1991 Fourth anniversary of FidoNet operations in Latin America and second anniversary of the creation of Zone-4. 15 Aug 1991 5th annual Z1 Fido Convention - FidoCon '91 "A New Beginning" Sheraton Denver West August 15 through August 18 1991. 8 Sep 1991 25th anniversary of first airing of Star Trek on NBC! 7 Oct 1991 Area code 415 fragments. Alameda and Contra Costa Counties will begin using area code 510. This includes Oakland, Concord, Berkeley and Hayward. San Francisco, San Mateo, Marin, parts of Santa Clara County, and the San Francisco Bay Islands will retain area code 415. 1 Nov 1991 Area code 301 will split. Area code 410 will consist of the northeastern part of Maryland, as well as the eastern shore. This will include Baltimore and the surrounding area. Area 301 will include southern and western parts of the state, including the areas around Washington DC. Area 410 phones will answer to calls to area 301 until November, 1992. 1 Feb 1992 Area code 213 fragments. Western, coastal, southern and eastern portions of Los Angeles County will begin using area code 310. This includes Los Angeles International Airport, West Los Angeles, San Pedro and Whittier. Downtown Los Angeles and surrounding communities (such as Hollywood and Montebello) will retain area code 213. 1 Dec 1993 Tenth anniversary of Fido Version 1 release. 5 Jun 1997 David Dodell's 40th Birthday If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. FidoNews 8-17 Page 37 29 Apr 1991 -----------------------------------------------------------------