Volume 5, Number 5 1 February 1988 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief Dale Lovell Editor Emeritus: Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Contributing Editors: Al Arango FidoNews is published weekly by the International FidoNet Association as its official newsletter. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. Copyright 1987 by the International FidoNet Association. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact IFNA at (314) 576-4067. IFNA may also be contacted at PO Box 41143, St. Louis, MO 63141. The contents of the articles contained here are not our responsibility, nor do we necessarily agree with them. Everything here is subject to debate. We publish EVERYTHING received. Table of Contents 1. ARTICLES ................................................. 1 A Message off Usenet ..................................... 1 AUTOECHO A ECHOMAIL Utility Version 1.00 ................. 2 The Binkley Chronicles ................................... 3 The Search For The BitNet Gateway ........................ 11 Fido's Net, Would he have wanted it this way? ............ 12 Como Obtener un Numero de Nodo ........................... 14 POLICY4 Suggestions from Bob Hartman ..................... 16 2. WANTED ................................................... 19 3. NOTICES .................................................. 21 The Interrupt Stack ...................................... 21 Latest Software Versions ................................. 21 FidoNews 5-05 Page 1 1 Feb 1988 ================================================================= ARTICLES ================================================================= From ptsfa!vixie!uunet!steinmetz!davidsen Fri Dec 18 10:05:56 1987 Return-Path: Date: Wed, 16 Dec 87 12:30:20 est From: uunet!steinmetz!davidsen(William E. Davidsen Jr) Message-Id: <8712161730.AA04733@steinmetz.steinmetz> To: hoptoad!pozar Subject: Re: FidoNET Newsletter, Volume 4, # 46 Newsgroups: comp.org.fidonet In-Reply-To: <3623@hoptoad.uucp> Organization: General Electric CRD, Schenectady, NY I really must point out the incomplete nature of the article on archivers, and question the concluson reached. There may be people who have disks full of EXE and COM files, but after checking a few home machines and some business machines at work, I conclude that many people have at most 50% files of this type. These files are very dense and show little improvement by compression, as the tests show. A more meaningful test would include databases, lots of text, both letters and source code, and a representative sample of other non-executable files. This would be more informative and useful. The issue of portability was very lightly mentioned. Some archivers are limited to MS-DOS by virtue of being written in assembler. Some will not run on OS/2 (except in compatibility mode). If the intension was to present information on which the reader could base a decision, I feel that it was inadequate. The user interface was not mentioned. Finally, the DWC archiver was not even considered. As PKARC it is limited to DOS currently, but the source is available and it is not shareware. My benchmarks show that it slightly faster than PKARC and produces slightly smaller archives, but I would like to see a test on the specific test files used for the other programs. I can't claim the the conclusions in the article were wrong, but I do believe that they were based on a very small number of data points, omitting both file type and programs. The tst should be repeated and the results posted. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me ----------------------------------------------------------------- FidoNews 5-05 Page 2 1 Feb 1988 Ben Mann / Paul Pappas OPUS 151/1000 AUTOECHO(tm) AutoEcho version 1.00 has now been released. Thanks to all the "beta" testers. Your bug reports and suggestions have made it all worth while. AutoEcho is a program that stems from the needs of all ECHOMAIL HOST and HUB sysops. It allows a NODE to send a message to the HOST system and turn on and off ECHO's that he/she would like to recieve or not recieve without the intervention of the HOST system sysop. A message is sent to AUTOECHO with a password in the subject field. This password MUST agree with a password the HOST system defines in a file called AUTOECHO.PWD. The body of the message contains the ECHO's the requester wants turned on or off. If the ECHO is preceeded by a minus sign the ECHO is turned off. If no sign is there the ECHO is turned on. AutoEcho then modifies the HOST systems AREAS.BBS or ECHO.CTL file and adds/deletes the ECHO being sent to that requestor. It also send a message to the requestor informing him/her what action was taken. A message is also send to the "SYSOP" of the HOST system or to his "real name" if environment varable SYSOP=[your name] is set. The orginal message is marked RECEIVED and will NOT be procesed by AutoEcho again. If the requestor enters QUERY on the first line of the message, AutoEcho send the requestor a list of echos available. AutoEcho now supports "levels" in the AUTOECHO.PWD file. This makes it so you can make certain echos unavailable if desired. All actions taken by AUTOECHO can be redirected to a log, AUTOECHO >> AUTOECHO.LOG, so the HOST sysop can tell what ECHO has been picked up or deleted. AUTOECHO.A00 may be requested from 151/1000 or 151/100. A .DOC file and examples are included. Can you say "AUTOECHO?", I thought you could. ----------------------------------------------------------------- FidoNews 5-05 Page 3 1 Feb 1988 Cards on the table This is about Binkley from a personal perspective. It would not be fair to call it a review, because I am hardly an unbiased observer. I use Binkley, and beta test it. Hopefully, this will be the first column of a series on Binkley and Opus related information. We are looking for volunteers! Get in touch with me at 321/202 if you are interested. Yet another front end You've probably heard people talking about BinkleyTerm as a front end. You've probably asked yourself: "Why would we WANT another front end?" Binkley is a terminal program or BBS/Point front end that unifies the two different technologies of session protocol in the network -Bark, and WaZoo. It handles WaZoo flawlessly, and handles Bark quite well. Binkley is descendant from OpusLink, by Wynn Wagner III, which was incorporated into OConnect, by Bob Hartman, which eventually was gobbled into BinkleyTerm, by Vince Perriello, later re-joined by Bob Hartman. The package draws heavily on sources released by Wynn Wagner, with contributions by others. It is distributed on about the same terms as Opus - that it must be used in a lawful and friendly manner. Rather than say what Binkley is, perhaps we should spend a little time saying what it is not. Binkley is NOT a full featured mail package, or point system. It is a mailer in the purest sense. It has no packing, unpacking, routing, or message browsing/composition features. You will need some sort of a message editor: RoverMsg, Dutched, Sirius, Mail, or anything similar. Binkley is a terminal plus a whole lot more. To quote an opening screen, BinkleyTerm is "A Companion Package for communicating with the Opus CBCS". But that's not all .. it's also "A Public Domain FidoNet Compatible Mail Utility". General Features Full Screen Interface One of the major features of Binkley is a full screen interface while in mailer mode. While most other mailers just scrolls information by, Binkley puts it in windows. Full Source Code Perhaps the most important feature of Binkley is the release FidoNews 5-05 Page 4 1 Feb 1988 of 100% of the source code with the package. Be warned, however, that Binkley was developed using MS-C 4.0. Due to some size differences in the MS-C 5.0 library, the program will not link under 5.0. The program, which was done in small model, is VERY close to the edge of memory, and the differences push it over. Bob and Vince eagerly await some person taking the source and solving the problem! (The next "official" version of Binkley will probably be overlaid.) Unlike Opus, very little of Binkley is in assembly. And it uses the MS-C libraries, not the WWIII version thereof! Improved Documentation Alan Applegate reworked the documentation. Where even experienced users had problems with the old docs, they should find the 1.20 docs to be quite usable. (I have talked to a couple of other sysops who have said that as good as they are, they are still not what a beginning sysop would need.) Multitasker Aware Binkley detects a number of popular multitaskers, and releases time slices to them. Session Level Information Protocols, etc. Supported Bark Binkley supports Bark file requests 100%, on the inbound side. Since Binkley uses Opus' outbound message structure, there is no mechanism for initiating an update request. Depending on your definition, Binkley does qualify for the XP flag. WaZOO This will come as no news to someone who runs pure Opus - but for those of us who ran SEADog over Opus, or TBBS, (or RBBS ...) the difference is breathtaking. Especially at 9600 baud. SEALink with Overdrive This is one of the weaker features of Binkley. For some connections, it works fine. In others, it breaks down. FidoNews 5-05 Page 5 1 Feb 1988 According to Bob Hartman, the timing problems between a SEADog (in SLO) and Binkley are largely due to the differences in code, mandated by the flexibility maintained on the Binkley side. Remember, though, that SLO only kicks in at 9600, and it can be disabled in Binkley.Cfg. Restartable Transfers Binkley supports restartable file transfers in a WaZOO session. If you get 200K of a 300K file, and lose carrier, so long as the chunk you have and the file sent are not changed, Binkley will pick up where it left off. This will be supported in Opus 1.10 as well, and is partially supported by Opus 1.03. The method used is NOT the same as is being used by Dutchie 2.80, and is not known to be compatible with any other mailers on the streets. Scripting Binkley also supports scripting. I am not at all familiar with this, we are hoping that in a future version of the "Binkley Chronicles", we will have an extensive example of how to use Bink's scripting. Magic File Names Binkley supports "magic file names". For example, the current version of Binkley (executable) can be obtained from most any Binkley distribution point under the name "BINKLEY". Magic file names may expand to more than one file, and may have passwords associated with them. Security Binkley uses Opus style session security. If passwords are being used between two nodes, they are exchanged before ANY mail is transferred, and if they are incorrect, the session is terminated. Configuration A Hybridization of Control Style and Operation Binkley is in most respects, a hybridization of the technologies extent in the network. Binkley is potent partly because its authors have had the value of 20/20 hindsight- they have been able to look over the design decisions in this product and that, and combine the best of them into one FidoNews 5-05 Page 6 1 Feb 1988 product. Binkley has a very nice, simple set of controls. The primary one is Binkley.Cfg, which is very similar to SEADog's Config.Dog. There are some differences, however. For the most part, "security related" information is isolated outside of the primary files. For example, session level passwords are contained in OpusNode.Pwd, and file level passwords are contained in the OKFile.Lst file. This makes it much simpler to package a copy of one's files to give to another sysop as an example. While this SEADog user was far more comfortable with Binkley's style of defining and running events (as opposed to Opus'), there are some important and powerful differences. Binkley gives you the ability to exit with a specified errorlevel the first time an event is encountered, a different one when mail is taken in, and yet another when arcmail is taken in. These errorlevels can be uniquely specified on an event by event basis, or omitted. There is also more control over the handling of events "passed over" due to a long transfer, or some other down time. Where SEADog will execute each and every event (very time consuming with all the packing and unpacking), Binkley will only execute those events classified as "forced". Otherwise, it simply jumps into the "current" event. Combined with less time spent packing and unpacking, my system is left with (much) more uptime, and much less wear and tear. (Although in all fairness, my system is weirder than most. When it was running SEADog, it ran events every 20 minutes, 24 hours a day.) Binkley.Cfg The Binkley.Cfg file is editable with a simple text editor, much the same as SEADog's (and the new Fido's, or so I'm told.) This is ALL that Binkley proper needs to operate, other than an Opus format nodelist. BT_CTL A program is provided with Binkley, BT_CTL, which takes the Binkley.Cfg file and cranks out the .PRM and Mail.Sys files you need to run echomail and oMMM. You can live without this if you are running Opus proper. FOSSIL driver Like Opus, Binkley has no inboard ability to talk to the comm ports (or the screen or keyboard, for that matter.) All such processing is handled by an externally installed FOSSIL driver. The FOSSIL driver of choice for most PC users is FidoNews 5-05 Page 7 1 Feb 1988 X00, by Ray Gwinn. oMMM as a packer As mentioned before, you need some kind of a packer to take the messages out of the mail area(s) and put them into the holding directory that Binkley uses. Binkley works just like Opus in this respect - it looks for files with various extensions, and sends them on the basis of the file name part or the contents. All scheduling and routing is accomplished by changing the extensions and arcing packets bound for a common destination into a single arc. oMMM (the Opus Matrix Message Masher) is the tool generally used to do this. There have been some efforts made to allow other packers to be used, particularly Dutchie's, but there are some problems on that front. OpusNode flavor nodelists Binkley uses Opus flavor nodelists. This means you will need OpusNode to compile your nodelists, and either the latest and greatest XlatList, or the quasi-released ParseList. The session level security is handled using OpusNode.Pwd, just as it is with Opus. If you are using Dutched or Mail as your message editor, you will need nodelists for them, in addition to your Opus style list. If you are running in a true point configuration, it is worth your while to have a "dummied" nodelist with just your Boss for OpusNode, and a full nodelist for your editor. Otherwise, you will need to kiss off an extra quarter to half a megabyte. Opus Style File Access Controls The file request information is handled Opus style. An "OKFile.Lst" style file is used to determine what files may be downloaded, and what passwords must be used for them. There is an extension for "magic file names", where the magic name is prefixed with an @ sign. Binkley also supports the "ABOUT" file, and the "FILES" files in the same manner as Opus. Terminal Features ANSI Terminal Emulation FidoNews 5-05 Page 8 1 Feb 1988 Binkley will do a very good job of emulating a VT-100 if you have a complete ANSI driver installed. FANSI-CONSOLE is mentioned as the driver of choice, as it takes care of remapping keys as well as remapping video strings. Many file transfer protocols In the terminal mode, Binkley supports a wide range of file transfer protocols - all the protocols that are "core" to network mail transfers in any flavor. Who should use Binkley, and who should not? People who should consider Binkley Any system serving both Bark and WaZoo systems If you run a system that supports a mixture of Bark and WaZoo systems, you would do well to consider running Binkley as your front end. By doing so, the systems you support will have to do that much less work to request files, etc. Power Point talking to a barefoot Opus If you have a "power user" acting as a point, and you are running Opus or Binkley over Opus, you might consider having that point use Binkley as his mailer. This is particularly true if high speed modems are involved. Dutchie is written in Turbo Pascal, and is not fast enough to support 9600 baud transfers at full speed. Anyone wanting more security than SEADog offers Currently, SEADog ONLY secures the handing out of mail. It will TAKE mail from anyone. With Binkley, as with Opus, any and all sessions can be secured. Although relatively minor, every little bit helps. People who might be better off with something else Most point users At the current time, most point users would be better off using an integrated, fully functional package, such as Dutchie or SEADog. Being a point is a complex enough task without having to integrate a whole bunch of different tools, some of which are not documented quite as well as they could be. Highly mobile point users FidoNews 5-05 Page 9 1 Feb 1988 SEADog has a wonderful ability - to handle phone number de- prefixing (stripping the 1- and 1-aaa) at the MAILER, as opposed to nodelist compilation phase. Binkley does not have this ability, and I've been told it never will. While you can override the number for your boss node in the Binkley.Cfg file, if you want to be truly and correctly mobile without recompiling nodelists all the time, you're better off with SEADog. Anyone happy running Opus barefoot Any sysop who is happy running a barefoot Opus is probably better off staying that way. If Bark requests are not important to you, all you will add with Binkley is a 20 second loading the Opus software delay to annoy your users. Anyone using their system for Real Business Binkley is part of the BBS project. As such, it is available on an as-is basis. If you are using your system to do real, commercial work that requires 100% functionality, you should think twice about using ANY unsupported tools. People who are still in a quandary TBBS Users There have been varying reports on whether or not Binkley works with TBBS. There is reputedly at least one system on the net that is running this combination, but MANY who have tried it and failed. There is apparently a conflict between some FOSSIL drivers and TBBSDVR. The authors are very interested in supporting TBBS. They are looking for a few good beta testers on that front. If you're interested, send netmail here - Bob and Vince are in the crunch phase now, in more ways than one. Other "Funny" BBS's Most of the gateways to other BBS's make some assumptions along the lines of Fido/SEADog style message packing. Adaptations have to be made somewhere along the line to compensate for these assumptions. To the best of my knowledge, Binkley is not yet being used as a front end for anything other than "traditional" net compatible BBS's. (PLEASE PROVE ME WRONG!) It's only a matter of time ... Conclusions and the sad state of political affairs Binkley is a superb technical statement. It's actually a FidoNews 5-05 Page 10 1 Feb 1988 shame that it is also a point of controversy, posed as competition for this package or that. It's rather depressing that one must consider political positions in viewing such a wonderful technical statement. Binkley is not a "third camp" of mailer. Binkley is not "something different" that some accuse the "WaZoo types" of trying to do. It's an attempt to demonstrate that quite a bit can be accomodated in 100K or so of code. ----------------------------------------------------------------- FidoNews 5-05 Page 11 1 Feb 1988 The Search for the BitNet Gateway By Chris Candreva 107/35 I've got this little problem: I'm addicted to FidoMail. This was no problem until last September, when I went to college. See, us lowly Freshmen can't have phone lines in our rooms, which makes it almost impossible to call BBSs. But, it seems there is a possible solution! Stevens (the college I attend) has a rather large networked VAX system, which is hooked into Bitnet. Now, rumor has it that there is a FidoNet <=> Bitnet Gateway. This would be great! I could send mail to my friends on PHALSE and Excalibur back home. The computer dept. would even allow me to have the space to receive Echo conferences, assuming we could work out the technical problems of routing. Fantastic! Except, I can't for the life of me FIND this gateway! I remember reading FidoNews articles on it a while ago, but my collection of old FidoNews is a little unorganized, and I haven't been able to find the article I am thinking of. If someone out there knows where the nearest FidoNet<=>Bitnet gateway is in the New York/New Jersey area (or if you actually ARE this gateway), would you please drop me a line at PHALSE QBBS 107/35? I would be very grateful! Thanks for taking the time to read this. And have fun -- that's what we're here for, right? ----------------------------------------------------------------- FidoNews 5-05 Page 12 1 Feb 1988 Ben Mann 151/0 FIDOSNET As alot of you know region 18 went thru alot of flexing and turnoil in the last several months. For those who don't know, our regional coordinator was replaced without hardly a wisper in the middle of the night. We had no say. The zone coordinator said it and it was done. The new region 18 coordinator is a nice guy. Means well and all that, but I have to wonder if FIDO would have wanted it that way. I mean you know what happened in Boston some years ago. Something about the rights of the governed. Well I didn't like it AND don't like it now. I would like a say in who I work with AND who I don't. If the regional coordinator wasn't doing his job then don't you think that I should have know? I was one of the 28 network coordinator that work with him for the last three years. 22 of which still support him as being the regional coordinator. And I was always satisfied of the responce times and decisions made, even if I didn't agree with them. I thought FidoNet was a sort of big club. Run by and for the members. NOT a dictatorship. Run from the top, with little, or no, reguard for the members. Well I found out real F-A-S-T. I just have to ponder: "Would Fido have wanted it that way?". ----------------------------------------------------------------- FidoNews 5-05 Page 13 1 Feb 1988 ’ ----------------------------------------------------------------- FidoNews 5-05 Page 14 1 Feb 1988 Editor's note: While FidoNews articles only include the ASCII characters space through tilde, I am allowing this one to be printed due to its nature. --------------------------------------------------------------- Juan Davila Node 367/1 The article below is meant for a new sysop and describes how to go about getting a node address in Net 367. It is written in Spanish and is an example of the type of work we are doing in the LatinoNet. We are engaged in many other projects as well, some of which we'll be telling you all about during the coming weeks. Most of our work is coordinated through our echo, LATINO. We are passing messages twice weekly and if you would be interested in participating please let me know. You can also contact either Pablo Kleinman (368/1) or Travis Good (102/851) for more infor- mation. Como obtener un n£mero de Nodo en FidoNet 367 (RED de Puerto Rico) =================================== FidoNet 367 en la actualidad tiene 5 Nodos activos alrededor de todo Puerto Rico. Si usted esta comenzando un sistema FIDO o uno compatible en Puerto Rico o areas limitrofes y tiene interes en obtener un n£mero de Nodo, env”e un mensaje privado v”a FIDOmail, desde su sistema al Operador del Nodo 367/1. Si necesita cambiar el n£mero de Nodo inicial (-1/-1) porque su programa no le permite utilizar este n£mero, entonces utilice el n£mero (367/-1), £nicamente con el prop¢sito de enviar este mensaje. No utilice un n£mero de Nodo ya existente o previamente otorgados a otro Nodo. Su mensaje debe incluir la siguiente informaci¢n: El nombre de sus sistema (14 letras m ximo) El nombre del operador (su Verdadero nombre) El n£mero telef¢nico del Sistema (data) Localizaci¢n del sistema (Ciudad y Estado) Su n£mero telef¢nico de voz Horas en que su sistema funcionar  La velocidad m xima que puede aceptar su sistema Que equipo utiliza su sistema Cualquier otra cosa que usted crea importante Cuando envie su mensaje tiene que enviarlo con un archivo "FALSO" adjunto, para poder evitar la rutina interna de FIDO que evitara que dicho mensaje llegue directo al 367/1. Para adjuntar un archivo "FALSO", conteste que "Si" a la pregunta, "Attach File?", del FIDO, y asigne un nombre de un archivo que no FidoNews 5-05 Page 15 1 Feb 1988 exista. Esto instruir  a FIDO que envie el mensaje directo en lugar de enviarlo por las rutas al "Host", donde quedar  como un mensaje huerfano porque no contiene un n£mero de Nodo v lido. Eventualmente me ser  enviado pero esto tomar  mas tiempo del necesario. Una vez yo reciba su petici¢n, verificare los n£meros telef¢nicos de su FIDO y le eviare su nuevo n£mero de Nodo por FIDOmail. Cualquier petici¢n procesada antes del miercoles de cada semana, aparecer  en el nuevo listado de Nodos de ese viernes. Si tiene alguna pregunta adicional sobre este procedimiento, deje un mensaje dirigido al Operador. Juan D vila Operador y Coordinador RED 367 de Puerto Rico ----------------------------------------------------------------- FidoNews 5-05 Page 16 1 Feb 1988 Ed note: This is one of several proposals consisting of suggestions for the new POLICY4 document which is being published for review by FidoNet Sysops and the subcommittee of Membership Services. Publication of these proposals will take place in FidoNews weekly until they have all been seen. Discussion regarding the new POLICY4 is taking place in the POLICY4 EchoMail conference. --------------------------------------------------------------- EZ-POLICY FOR FIDONET by Bob Hartman, Sysop 1:132/101 This document is meant to be a starting point for further discussion on FidoNet Policy and Procedures. It is a draft of what could later be accepted as the official FidoNet Policy and Procedures Guide, and comments/suggestions are not only welcome, but encouraged. SECTION I: LEVELS OF FIDONET The FidoNet Network is broken down into many different levels much as the hierarchy within any efficient organization. Thru past history, the following hierarchy has developed: 1. All System Operators (SysOps) taken collectively (FidoNet). This is the topmost level of the structure, and represents the entirety of FidoNet. [NOTE: During the resolution of a dispute involving the expenditure of money, only those Sysops representing the minority that would have to spend the money are allowed to vote on the issue. An example would be a dispute on whether or not Network Coordinators are responsible for forwarding the NODELIST to all of the nodes in their network, or whether it is acceptable to have the nodes poll to get the NODELIST. This issue clearly is a dispute that involves money being spent by the Network Coordinators or other SysOps. The Network Coordinators are the smaller group, and therefore only SysOps in that position are eligible to vote on the outcome. If the reverse were true, the larger number would almost inevitably vote not to spend their money, but rather have the smaller group shoulder the burden.] 2. International FidoNet Association (IFNA) Board of Directors. This group is elected so as to be broadly representative of the views of the SysOps of FidoNet. 3. IFNA Executive Committee. Because of the size of the IFNA Board of Directors (necessary to maintain reasonable representation for all parts of the world), it is necessary to have this small working group to take on the everyday operations of IFNA. FidoNews 5-05 Page 17 1 Feb 1988 4. IFNA Vice President - Technical Coordinator (VP-TC). This is an Officer of IFNA position that is filled in accordance with the Articles and By-Laws of IFNA. This Officer is responsible for the maintenance and distribution of the master FidoNet nodelist, and ensuring the smooth operation of FidoNet. 6. Zone Coordinator (ZC). This position oversees one Zone of FidoNet and is responsible for the smooth functioning of FidoNet within that Zone. 7. Regional Coordinator (RC). This position oversees one Region within a Zone and is responsible for the smooth functioning of FidoNet within that Region. 8. Network Coordinator (NC). This position oversees one Network in one Region and is responsible for the smooth functioning of FidoNet within that Network. 9. SysOp. This is the singular unit of FidoNet. The SysOp runs his or her own FidoNet capable software such that their system can function as part of FidoNet within the guidelines imposed by the various levels of FidoNet above the SysOp level. Those guidelines are formulated over time as defined in this document. SECTION II: RESOLUTION OF DISPUTES In FidoNet it is very often necessary to resolve a dispute between SysOps at various levels of the hierarchy. For the purposes of this section, the following terms need to be defined: PLAINTIFF - The SysOp lodging a complaint against another SysOp. DEFENDANT - The SysOp against whom a complaint has been lodged by a plaintiff. MEDIATION LEVEL - One level in the FidoNet hierarchy ABOVE the level of the defendant. All disputes in FidoNet have the parties defined above. Using a "sliding window" of authority, any dispute can be heard and solved at any level of the hierarchy. The procedure is as follows: 1. Plaintiff files an official complaint against the Defendant by informing the Mediation Level of the problem. 2. The Mediation Level hears the complaint and asks for as much information as possible from all concerned parties before making a judgement. 3. The Mediation Level issues a "verdict" in the case. 4. If the Plaintiff feels slighted by the "verdict", the case may be appealed with the new Defendant being the combination of FidoNews 5-05 Page 18 1 Feb 1988 the original Defendant, and the original Mediation Level, and the process starts over again at number 1. At this point the complaint is being heard two levels above the original Defendent - effectively the authority for making the decision has been shifted via a "sliding window" to the next level. 5. If the Defendant feels slighted by the "verdict", the case may be appealed with the new Defendant being the original Mediation Level, and the process starts over again at number 1. Both 4 and 5 have the effect of moving the outcome of the complaint up the chain of command. All decisions at the topmost level are final and can no longer be appealed. All disputes are solved in this manner. SECTION III: POLICIES The Policy at each level of the FidoNet hierarchy is formed through the resolution of disputes. When a dispute is finally resolved, the policies of all levels below the level making the final compromise are affected. For this reason, each level of the hierarchy is responsible for maintaining a "Case Law" document of policies and procedures that have been created at that level. In no case may a "Case Law" document from one level be in conflict with any of the "Case Law" documents at higher levels. However, "Case Law" documents at the same level need not be the same. For example, Region 16 may have it in their case law that each Network Coordinator must have the latest issue of FidoNews available for pickup by any of the nodes in the network, while Region 10 case law may say that it is not necessary for the Network Coordinators to have FidoNews on-line. If however, FidoNet acting as a whole has in the case law book at the top level that Network Coordinators must have FidoNews available for pickup, then the rule in Region 10 is in conflict and is therefore superceded. ----------------------------------------------------------------- FidoNews 5-05 Page 19 1 Feb 1988 ================================================================= WANTED ================================================================= -- VIRUS QUERY -- Reporter writing an article for the NY Times on the threat of "virus' ("mole,) "worm" and/or trojan horse "attack code" programs seeks reports of real experiences with these often distructive, sometimes playful, devices. I'm interested in any reports about incidents involving PCs, minis or micros. Please forward replies to Vin McLellan at Fido 101/154, (voice) 617-426-2487, or Snail : 125 Kingston St., Boston, Ma. 02111. ----------------------------------------------------------------- FidoNews 5-05 Page 20 1 Feb 1988 TRW Real Estate Information Systems, in Anaheim, CA is seeking a creative Senior Programmer/Analyst to aid in the analysis, design and implementation of a new generation of micro/mainframe systems running in an IBM PC-AT compatible multitasking environment. We are looking for motivated, independent thinker with a minimum of two years MS-DOS micro programming in C or Macro Assembler and two years mini/mainframe programming. Experience in structured development techniques and systems analysis/design required. Familiarity with micro-mainframe communications, micro hardware, and networks is desirable. Direct customer interface is common, so good written and oral communication skills are needed. Please forward your resume with work history and references to: TRW Real Estate Information Systems, Professional Employment, Dept. DL-101, 2000 S. Anaheim Blvd., Suite 100, Anaheim, CA 92805. An equal opportunity employer. ----------------------------------------------------------------- FidoNews 5-05 Page 21 1 Feb 1988 ================================================================= NOTICES ================================================================= 5 March 1988 The Area Code for Southern Colorado changes to 719. Be sure to change your script files as necessary. ----------------------------------------------------------------- The Interrupt Stack 19 Feb 1988 Start of the International FidoNet Associations Board of Directors meeting in St. Louis. Meeting runs through the 21st. 25 Aug 1988 Start of the Fifth International FidoNet Conference, to be held at the Drawbridge Inn in Cincinnatti, OH. Contact Tim Sullivan at 108/62 for more information. This is FidoNet's big annual get-together, and is your chance to meet all the people you've been talking with all this time. We're hoping to see you there! 24 Aug 1989 Voyager 2 passes Neptune. If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. ----------------------------------------------------------------- Latest Software Versions BBS Systems Node List Other & Mailers Version Utilities Version Utilities Version Dutchie 2.80* EditNL 3.3 ARC 5.21 Fido 12e* MakeNL 1.10 ARCmail 1.1 Opus 1.03a Prune 1.40 ConfMail 3.31* SEAdog 4.10 XlatList 2.85* EchoMail 1.31 TBBS 2.0M MGM 1.1 BinkleyTerm 1.30* * Recently changed Utility authors: Please help keep this list up to date by reporting new versions to 1:1/1. It is not our intent to list all utilities here, only those which verge on necessity. ----------------------------------------------------------------- FidoNews 5-05 Page 22 1 Feb 1988 __ The World's First / \ BBS Network /|oo \ * FidoNet * (_| /_) _`@/_ \ _ | | \ \\ | (*) | \ )) ______ |__U__| / \// / Fido \ _//|| _\ / (________) (_/(_|(____/ (tm) Membership for the International FidoNet Association Membership in IFNA is open to any individual or organization that pays a specified annual membership fee. IFNA serves the international FidoNet-compatible electronic mail community to increase worldwide communications. Member Name _______________________________ Date _______________ Address _________________________________________________________ City ____________________________________________________________ State ________________________________ Zip _____________________ Country _________________________________________________________ Home Phone (Voice) ______________________________________________ Work Phone (Voice) ______________________________________________ Zone:Net/Node Number ____________________________________________ BBS Name ________________________________________________________ BBS Phone Number ________________________________________________ Baud Rates Supported ____________________________________________ Board Restrictions ______________________________________________ Your Special Interests __________________________________________ _________________________________________________________________ _________________________________________________________________ In what areas would you be willing to help in FidoNet? __________ _________________________________________________________________ _________________________________________________________________ Send this membership form and a check or money order for $25 in US Funds to: International FidoNet Association c/o Leonard Mednick, MBA, CPA 700 Bishop Street, #1014 Honolulu, Hawaii 96813-4112 USA Thank you for your membership! Your participation will help to insure the future of FidoNet. Please NOTE that IFNA is a general not-for-profit organization and Articles of Association and By-Laws were adopted by the membership in January 1987. The first elected Board of Directors was filled in August 1987. The IFNA Echomail Conference has been established on FidoNet to assist the Board. We welcome your input to this Conference. ----------------------------------------------------------------- FidoNews 5-05 Page 23 1 Feb 1988 INTERNATIONAL FIDONET ASSOCIATION ORDER FORM Publications The IFNA publications can be obtained by downloading from Fido 1:1/10 or other FidoNet compatible systems, or by purchasing them directly from IFNA. We ask that all our IFNA Committee Chairmen provide us with the latest versions of each publication, but we can make no written guarantees. Hardcopy prices as of October 1, 1986 IFNA Fido BBS listing $15.00 _____ IFNA Administrative Policy DOCs $10.00 _____ IFNA FidoNet Standards Committee DOCs $10.00 _____ SUBTOTAL _____ IFNA Member ONLY Special Offers System Enhancement Associates SEAdog $60.00 _____ SEAdog price as of March 1, 1987 ONLY 1 copy SEAdog per IFNA Member Fido Software's Fido/FidoNet $100.00 _____ Fido/FidoNet price as of November 1, 1987 ONLY 1 copy Fido/FidoNet per IFNA Member International orders include $10.00 for surface shipping or $20.00 for air shipping _____ SUBTOTAL _____ HI. Residents add 4.0 % Sales tax _____ TOTAL _____ SEND CHECK OR MONEY ORDER IN US FUNDS: International FidoNet Association c/o Leonard Mednick, MBA, CPA 700 Bishop Street, #1014 Honolulu, HI. 96813-4112 USA Name________________________________ Zone:Net/Node____:____/____ Company_____________________________ Address_____________________________ City____________________ State____________ Zip_____ Voice Phone_________________________ Signature___________________________ -----------------------------------------------------------------