Volume 6, Number 52 25 December 1989 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Vince Perriello Editors Emeritii: Dale Lovell Thom Henderson Chief Procrastinator Emeritus: Tom Jennings 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. 1:1/1 is a Continuous Mail system, available for network mail 24 hours a day. Copyright 1989 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. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and are used with permission. We don't necessarily agree with the contents of every article published here. Most of these materials are unsolicited. No article submitted by a FidoNet SysOp will be rejected if it is properly attributed and legally acceptable. We will publish every responsible submission received. Table of Contents 1. ARTICLES ................................................. 1 News about the ANEWS echo ................................ 1 SEAlink and Wazoo -- Benchmark Results ................... 2 Save money the EASY way! ................................. 11 Internetwork Gateway Policy Revisited .................... 13 InterNet Relations - A Rebuttal .......................... 15 IBM Offers free system Board to 50Z Owners ............... 16 Notes on proposed Internetwork Policy .................... 18 2. LATEST VERSIONS .......................................... 25 Latest Software Versions ................................. 25 3. NOTICES .................................................. 28 And more! FidoNews 6-52 Page 1 25 Dec 1989 ================================================================= ARTICLES ================================================================= This is just a short note to inform you about the ANEWS echo. ANEWS, or News of the US and World, has been in existence for about 2 months. In that time it has grown considerably. What is ANEWS? ANEWS, an acronym for alternative news, is a current events/news related echo. It contains general news stories and interesting news items that are either skimmed over by the normal media or which are not covered at all. ANEWS contains both national and international stories with emphasis on social, labor and environmental issues. ANEWS stories range from single-screen news briefs to articles that are several screens long. So if you would like some fresh news online, and don't want the cost or the blandness of the mass-produced USA Today online newspaper, look into ANEWS. ANEWS averages 40-60 messages per week and is available in many parts of the country. For more info contact the ANEWS moderator, Karl Frederick at 1:141/552. Area Tag : ANEWS Area Name: News of the US and World Moderator: Karl Frederick @ 1:141/552 ----------------------------------------------------------------- FidoNews 6-52 Page 2 25 Dec 1989 Thom Henderson, 520/1015@AlterNet System Enhancement Associates, Inc. SEAlink and Wazoo Benchmark Results We've done many benchmark tests over the years. Obtaining accurate benchmark data was often an important part of our consulting practice. In recent years we've done a number of benchmark tests of FidoNet-related technology, and we've usually reported the results of those tests in FidoNews. Our previous reported benchmark compared the SEAlink and Zmodem file transfer protocols, and were reported in FidoNews volume 5, issue number 19 (9 May 1988). The purpose of that benchmark was to compare the efficiency of the actual file transfer protocols themselves. The purpose of our latest benchmark was for the somewhat different purpose of comparing two different network mail session protocols: FTS-0007 using adaptive SEAlink Overdrive, and Wazoo using Zmodem. Since the point of this benchmark was to measure the session protocols themselves in real-world, high speed file transfers, our tests all involved shipping files over normal voice-grade lines using the most recent available models of U.S. Robotics Courier HST modems ("14.4" models), which were loaned to us by U.S. Robotics for this test. The software employed consisted of the latest versions of the two programs most widely considered as representative of the different techniques (SEAdog 4.51b for FTS with SEAlink/Overdrive, and Binkley 2.30 for Wazoo). It was observed that on all trials the software was always able to quickly saturate the data channel (which can be observed by noting that the transmitting system is being "paced" by its modem, while the receiving system is NOT pacing its modem), and hence limitations of either particular implementation are minimal. Furthermore, the data transmitted in all tests consisted of compressed data, which reduced any effects resulting from data compression performed by the modems, while also more- actual data transferred was identical between the two different programs. The first run consisted of having each program send one file, of graduating size, and timing the total connect time of the telephone call. For example, each program was told to transfer one file of 100 blocks (12,800 bytes), then each was told to transfer one file of 200 blocks (25,600 bytes), and so on in increments of 100 blocks up to a maximum size of 2,000 blocks (256,000 bytes). The following data was collected: FidoNews 6-52 Page 3 25 Dec 1989 Table 1: One file, increasing size Blocks Wazoo SEAlink 100 30 20 200 35 26 300 42 36 400 50 42 500 60 54 600 67 58 700 75 68 800 82 85 900 104 81 1000 100 93 1100 108 99 1200 115 110 1300 126 118 1400 141 124 1500 139 133 1600 149 138 1700 159 151 1800 171 156 1900 179 165 2000 184 177 Slope 0.08328 0.08129 Intercept 18.35789 11.34211 Correlation 0.99743 0.99847 The times are given are the total connect time in seconds between the sending and receiving system. These numbers are then treated to linear regression analysis (least-squares method) to produce a slope and intercept. This treatment assumes that the data is basically linear, and can hence be expressed with the formula: y = Ax + B where "x" is the number of blocks, "y" is the time taken in seconds, "A" is the slope, and "B" is the intercept. In other words, "A" is the time in seconds to transmit one block, and "B" is the overall session overhead in seconds. If the data is truly linear, then A and B will be constants. The degree of fit can be measured by the correlation coefficient. The higher this number is, the better the fit is, with a coefficient of 1.0 indicating a perfect fit. The correlation coefficient for this data set is better than 99% in both cases, so we can be confident that our data truly is linear and that it matches our calculated formulae quite well. The slightly greater deviation of the Wazoo numbers can probably be attributed to the greater complexity of Zmodem causing more variable results. FidoNews 6-52 Page 4 25 Dec 1989 As can be seen, a SEAlink-based session is slightly faster when transmitting data (0.002 seconds per block, or 16 seconds per megabyte) and has considerably less fixed overhead (7 seconds per session). For our next run we wished to compare the per-file overhead of the two protocols. This test consisted of sending files of 100 blocks (12,800 bytes). We told each program to send one file, then two files, and so on up to twenty files, and obtained the following data: Table 2: Multiple files of 100 blocks each Files Wazoo SEAlink 1 25 15 2 39 30 3 52 38 4 57 49 5 68 59 6 79 68 7 92 81 8 100 89 9 123 95 10 122 108 11 132 117 12 143 129 13 154 138 14 170 148 15 187 159 16 186 167 17 196 181 18 207 188 19 217 201 20 231 204 Slope 10.69774 9.99699 Intercept 16.67368 8.23158 Correlation 0.99812 0.99946 As you can see, we again have a reasonable fit of formula to reality. In this situation the slope is of interest, as it gives the time in seconds to transfer one file of 100 blocks. From table 1 we calculate the time required by each protocol to transfer 100 blocks of data (multiplying the time per block by 100). Subtracting that number from the time required to send one file of 100 blocks gives us the per-file overhead, as follows: FidoNews 6-52 Page 5 25 Dec 1989 Wazoo SEAlink Time per 100 block file: 10.698 9.997 Minus time per 100 blocks: 8.328 8.129 Equals overhead per file: 2.370 1.868 Thus we can see that a SEAlink-based session takes roughly half a second less to negotiate each file than does a Wazoo-based session. For our next benchmark run we tried something a bit unusual that had not originally been planned for this test. We included it partly out of curiosity, and partly because we knew that it would not take long to collect the data. This run was essentially the same as the previous run, except that the file being transmitted always existed on the target system in advance. Hence, on each and every transfer the receiving system immediately "synced to the end" and refused the file. The following data was collected: Table 3: Multiple files of 100 blocks each, pre-existing Files Wazoo SEAlink 1 13 11 2 15 10 3 17 13 4 19 14 5 23 17 6 21 17 7 26 21 8 26 22 9 27 28 10 29 27 11 31 26 12 33 28 13 34 30 14 36 34 15 37 33 16 42 34 17 43 36 18 43 40 19 45 42 20 46 48 Slope 1.74586 1.80376 Intercept 11.96842 7.61053 FidoNews 6-52 Page 6 25 Dec 1989 Correlation 0.99480 0.98523 Crossover 75.3 In this series Wazoo showed slightly better performance than SEAlink, though with a slightly greater deviation in the data than we have had thus far. According to this series, it takes about 0.06 seconds less to not transmit a redundant file when using Wazoo instead of SEAlink. We've introduced a new number in this table, dubbed "crossover". This is the value at which both methods will yield the same result. In other words, if the formulae are correct, then at 76 such file transfers the greater per-file rate of Wazoo will overcome its greater session overhead, and it will become faster overall than a SEAlink-based session. We have not reported the crossover for earlier benchmark runs because the data was divergent. That is, the data indicated that under those conditions Wazoo would never overcome its greater per-session overhead. This brings us to our final benchmark series, which tests the one great strength of Wazoo, and its only practical difference on a day-to-day basis. That is, Wazoo uses a much more time-efficient file request mechanism than the file-by-file negotiation of a SEAlink-based session. This run was similar to our second run in that each session involved the transmission of one or more files of 100 blocks (12,800 bytes) each, except that during this run the files were requested rather than sent. In other words, we told each program to request one file, then two files, and so on up to twenty files. The following data was collected: Table 4: Requesting multiple files of 100 blocks each Files Wazoo SEAlink 1 27 26 2 37 36 3 54 50 4 66 65 5 74 74 6 86 94 7 95 103 8 107 116 9 117 129 10 132 143 FidoNews 6-52 Page 7 25 Dec 1989 11 139 155 12 153 167 13 163 182 14 178 197 15 183 208 16 195 223 17 205 243 18 220 247 19 230 329 20 240 274 Slope 11.13158 14.09098 Intercept 18.16842 5.09474 Correlation 0.99952 0.98572 Crossover 4.4 From table 2 we can obtain the time required for the transfer of one file of 100 blocks, which then by subtraction yields the following: Wazoo SEAlink Time per file request: 11.132 14.091 Minus time per 100 block file: 10.698 9.997 Equals overhead per request: 0.434 4.094 This resulted in our only surprise during this benchmark series. We knew that Wazoo would have a lower per-request overhead, but we had not anticipated that the difference would be as much as 3.7 seconds per request. Even so, one must do five or more requests in a session before the difference can overcome the greater inherent overhead of a Wazoo session. We conclude that the difference would be significant primarily in large GroupMail sessions where StarLink was not being employed. Summation ========= The results of all of this can be tabulated as follows: Wazoo SEAlink FidoNews 6-52 Page 8 25 Dec 1989 Session overhead: 18.358 11.342 Time per 100 blocks: 0.083 0.081 Overhead per file: 2.370 1.868 Overhead per file request: 0.434 4.094 Conclusion ========== Overall, we find a SEAlink-based session to be far more efficient than a Wazoo-based session, with the sole exception of file requests. We would further conclude from this data that the most efficient session of all would be a SEAlink-based session employing the Wazoo file request mechanism (which is certainly possible), since it would take advantage of the more efficient request mechanism while also enjoying the more efficient file transfer protocols and lower overall overhead of a SEAlink-based session. Such a change would not be without cost, as it would sacrifice the targeted-request capability of the SEAlink-based file request mechanism (and in addition, for us at least, would involve difficulties relating to backwards compatibility with existing customers). However, it would be quite possible for a mailer to honor BOTH sorts of requests -- one for targeted requests, and one for non-targeted requests -- and thus acheive the best of both worlds. Hence, we intend to move in that direction in the future. We can but hope that other developers will see fit to follow suit. ----------------------------------------------------------------- FidoNews 6-52 Page 9 25 Dec 1989 COMPUTER INFORMATION MONTHLY NEWS ================================= This is the Official Announcement of what may very well be the first of it's kind of magazine. I have searched every possible avenue for a like product and have so far been unable to find one. For several years now I have accomplished a monthly news letter, well several months ago, I started looking at a new approach to the conventional news letter. I was tired of having to type them out or print them out to a printer. An after several months of experimentation I developed a program which is executable on IBM MS-DOS machines. This computer program offers all the features of a normal magazine in paper form. Feature articles, special announcements, product reviews, editors corner, business and BBS advertisement screens. At present there are approximately 200 (79x23) screens available in this magazine. Another feature is it is in full color, from the front page, to the opening index. A lot of time has gone into the development of this program and the Premier Issue Date is currently scheduled for 15 Jan 1990. This program will be offered to Computer Users as FreeWare, at this time there is NO plans to charge a subscription price, but this option may very well be exercised in 1991. Since this program is being offered as FreeWare, it is an absolute necessity to have a distribution system. I would like to make this program available to as many SysOps and Users as possible. In doing so it will cost Me a little extra to dissiminate the program in an ARCED version to BBS's systems. Since there are over 6000 available systems I would like to see your help in passing this program around. If you as a SysOp would like to make this program available to your users, you may File Request the Magazine each month effective 10 Jan 1990 using the file name CIMN-V##.ARC, with ## being the monthly issue (01-Jan, 12-Dec). If you are a user and would like to have access to this Magazine please ask your Local Fido Net Sysop to obtain it. In some cases I will deliver a copy to the Net Coordinator or the Regional Coordinator where the file will be available for file requesting. If you would like a personal copy of this file, you may also send a 5.25" floppy formatted disk to the address provided below, along with a (SASE) for return, or you may call Voice 1-505-865-8386 for further details. Remember this Program currently runs only on IBM or compatable systems, and is Free to anyone interested in obtaining a copy. JAKE HARGROVE HIGH MESA PUBLISHING 13 OSAGE DR LOS LUNAS, NM 87031 FidoNews 6-52 Page 10 25 Dec 1989 COMPUTER INFORMATION MONTHLY NEWS THE MAGAZINE OF THE FUTURE! ----------------------------------------------------------------- FidoNews 6-52 Page 11 25 Dec 1989 I'm going to save YOU money! It's very simple, really. You see, the new Front Door and D'bridge versions no longer support SEAlink or BARK requests, they supposedly support FTS-0001. What does this mean to you? Well, it means one of two things. If you're lucky, your transfer efficiency will ONLY go down to about 35% at 9600 baud when one mailer calls another. *I* was one of the UNlucky ones. You see, I've been distributing nodelists all over the United States and Canada for the past two months, but when the Front Door people I called switched to the new Front Door, I found that I was unable to send them files. You know what? They couldn't send me files, EITHER. The lovely thing is that all these file transfers were going on after everyone had gone to bed, so like good little mailers, our systems would just keep calling, trying desperately to carry out the commands we'd given them, i.e., to send the files. The way I figure it, the Front Door and D'bridge authors owe me some bucks on my phone bill. The really wierd thing about all this is that the old versions run SEAlink and supported BARK requests really well. I've got a half dozen Front Door people alone calling me long distance every night for GroupMail, and THEY have no problems. So why take the support out for a feature that was working? Dare we call the reason (Shhh! Say it quietly!)... "political"? Nah, it couldn't be that, could it? Now, here's where I back up my promise. The way you save money if you're running Front Door is to NOT upgrade. That way you won't be calling systems all night and either getting 3500 baud thruput on your 9600 baud line or simply calling over and over all night long. The new version will have the SEAlink and BARK stuff back in (after all, they promised, didn't they? They've had the spec for a MONTH now...), and you'll have all your other bells and whistles, too. If you're running SEAdog 4.5 or higher, you can save money this way: In your XLATLIST control file (or other equivalent software), define a class for nodelist flag XX (WazOO update requests only), thus: FidoNews 6-52 Page 12 25 Dec 1989 Class Z XX In your ROUTE-DOG file, put the following statements at the end: Schedule ALL HOLD Class-Z That will insure that your mailer NEVER, EVER, calls a Front Door or D'bridge system that's going to run up your phone bill. If you're doing echomail with such a system, let HIM call YOU. If he complains about the connections, or multiple calls just say, "Hey, I didn't change MY software! Did YOU?" * Submitted by Phil Buonomo, 1:107/583@FidoNet 520/583@AlterNet ----------------------------------------------------------------- FidoNews 6-52 Page 13 25 Dec 1989 Thom Henderson, c/o 1:107/528 Chairman, International FidoNet Association Internetwork Gateway Policy Revisited I notice in FidoNews volume 6, issue 51 that a small group has announced the creation of a new (and lengthy) Policy Document on how internetwork gateways may or may not be done. Fortunately the proposed (newly established?) policy meets Tom Jennings' criteria of a "good policy". It is emminently ignorable. In essence, some unspecified group appoints one person to be in charge of all internetwork gateways. Said person then regulates all gateways to ensure that they meet various criteria as established by the policy document and by the unspecified small group. I suppose this means that the various people now running Usenet gateways must ask approval and seek certification if they wish to continue in their activities. Fortunately, as I said, it is a very ignorable policy. If you are running a Usenet or othernet gateway, or if you wish to do so, you can go right ahead with no worries. The reality of FidoNet that this group seems to be overlooking is that as long as you have the support of your NC (or your RC if you're an independant), you can do pretty much anything you like and nobody can really stop you. But the real problem with this policy is not so much what it says, as what it implies. It implies that there is some unspecified group with no apparent mandate or means of selection who are somehow empowered to make decisions on behalf of FidoNet. It should be obvious by now that I don't really think that unspecified groups like that are a good idea. I got roped into one once (the original "interim board" of IFNA), but our very first acts were directed at converting our "unspecified group" into a VERY specified group with a democratically elected Board of Directors with a known mandate to operate on behalf of the FidoNet sysops (and somehow I've wound up STILL working on that!) The test has been set. With much discussion and some disagree- ment here and there, but with general consent overall as near as I can tell. Any group or organization that wishes to represent itself as "speaking for FidoNet" must first obtain a positive mandate from the majority of FidoNet sysops. Passive "no voters" count as a "no", because if the majority does not see a need for a central organization, then there should not be one. IFNA is undergoing this test. As I write this, the referendum is over and the votes are being tallied. By the time you read this the totals should be published. FidoNews 6-52 Page 14 25 Dec 1989 One of two things will happen: 1) IFNA will receive a mandate, in which case this "proposed policy" will be subject to review by all FidoNet sysops and must meet with their (your) approval before it can go into effect. 2) Or IFNA will not receive a mandate, in which case this "unspecified group" must seek its own mandate before it can presume to speak on behalf of FidoNet. This goes below the level of voting on policy. Before anyone can set ground rules for how a policy can be approved, they must first have the authority to establish policy approval procedures. ----------------------------------------------------------------- FidoNews 6-52 Page 15 25 Dec 1989 Date: 20 Dec 89 21:17:20 From: Walter Tietjen on 151/114 To: Tim Pearson on 286/703 Subj: FidoNews Article Original in netmail - Copy to Vincent P. (1:1/1) for inclusion in FidoNews Isolation of the various political networks _WON'T_WORK_!! It can make an accidental echomail `circular feed' _WORSE_ _ANY_ `circular feed' in echomail causes duplicate messages. With full FidoNet/AnyOtherNet combined seen-bys and path-lines, the duplicates caused by the `circular feed' are restricted to the nodes in the closed loop of the `circular feed'. With pure seen-by stripping at "approved inter-net echo-gates" the duplicates originally caused by a `circular feed' are spread to nodes _OUTSIDE_ the closed loop of the `circular feed'. The path-lines if left intact still provide some limited ability to manually trace & eliminate a circular feed. If _BOTH_ the seen-bys and path-lines are stripped-out, there is _NO_ method left available to track down a circular feed involving dual-ID nodes which through accident receive an echo from both sides of an internet echogate. ALTERNATIVE PROPOSAL: _ALL_ FTSC-compatible networks shall draw their "Net" numbers (of /) from a _COMMON_ number pool thus insuring that an AnyOtherNet address will _NOT_ interfere with echomail delivery within FidoNet. Future agreements between different FTSC-compatible networks should address the fair & equitable sharing of echomail distribution cost between multiple networks participating in a shared echo. Re: Private netmail replies to echomail messages: By the use of "private" nodelists an artificial `zonegate' can easily be set-up between the pure-FidoNet nodes in a local area and a dual-ID system in the same local area who maintains an address in the target AnyOtherNet. ----------------------------------------------------------------- FidoNews 6-52 Page 16 25 Dec 1989 IBM Offers free system Board to 50Z Owners Recently, certain users of the IBM Model 50Z PS/2 computer have encountered problems using software which bypass the computer's BIOS and attempt to send data to a serial port, according to Cheryl Butcher, an IBM systems engineer in West Lafayette, Ind. IBM has acknowleged the existance of a bug in the system board which will halt the output process and leave users with a useless machine. The bug causes problems in use with such programs as Microsoft Corp.'s Windows and Lotus Development Corp.'s Symphony by keeping the software from properly accessing the PC's serial port. IBM is offering a free replacement system board to users who encounter this problem. IBM has issued an engineering change for its IBM Model 50Z BIOS to correct the problem in new machines, and has offered to replace defective system boards thru December 31st, 1989. Users of Microsoft's WORD 5.0 will also notice the problem, which is how IBM originally became aware of the bug. "Microsoft WORD 5.0 worked fine on all of our other machines except the Model 50Z," said Bruce Fuller, and electrical engineer at Purdue Universeity. "The only work around was to use WORD 4.0, which is really not a solution." IBM will replace system boards that qualify according to the following chart: The machine must have the following: o Module ZM41 (located in the center of the system board) is marked with part number 05fox3628. o The serial number is one of the following: Model 50Z 31: Model 50Z 61: 23-7134521 23-7634866 72-7072052 55-6667427 78-4223666 72-7617500 90-5011650 78-4704505 90-5602521 Users whose machines do not qualify for the system board replacement should contact the software developers for patches, Butcher said. IBM officials recommend that users get in touch with their local IBM representative for further information and assistance. FidoNews 6-52 Page 17 25 Dec 1989 * Submitted by Phil Buonomo, 1:107/583@FidoNet 520/583@AlterNet ----------------------------------------------------------------- FidoNews 6-52 Page 18 25 Dec 1989 Jack Decker 1:154/9, 11:154/8 NOTES ON THE PROPOSED INTERNETWORK GATEWAY POLICY DOCUMENT In Fidonews 651 an article by Tim Pearson of 1:286/703 appeared, which described and presented a draft of an Internetwork Gateway Policy document. I would just like to point out a few observations on this document. If past experience holds, most of this will fall on deaf ears. It seems most sysops tend to ignore net politics until it's their node number going down the tubes, at which point they are pretty powerless to do anything about it. Well, if that's what you want, fine. Just don't act so surprised when you are on the outside looking in. Now the question we should be asking ourselves is whether this proposed policy will enhance communications, or inhibit them? Most of us joined Fidonet because we wanted to be able to communicate with a maximum number of people. A policy that inhibits communications may stroke the egos of a few who wish to be "in control", but it doesn't benefit most sysops within the net. The first thing to notice is the proposed method for adoption of this document: "It is our intention to allow 30 days for the receipt of input from the network at large. After that, the final draft will be presented to the International Coordinator for adoption." Now you'd think that folks would by now realize that many Fidonet sysops are totally opposed to the "control from on high" operation of Fidonet. You have the opportunity to comment, but do you have the right to say "I don't think there is any need for this policy at all?" Probably not. If you suggest changes, the Gateway Policy Development Committee may decide to incorporate your suggested changes, or they may not. But if you tell them "I sincerely fail to see any need for such a policy, and would prefer that it not be adopted", I wonder if they would listen? Keep in mind that the "members of the Gateway Policy Development Committee include: Bill Bolton, Steve Bonine, Randy Bush, David Dodell, Rick Moore, Tim Pearson, Vince Perriello, Tim Pozar, and Matt Whelan." Now I'm not saying that any of these folks are bad people. In fact, I think most of them have a vision of what Fidonet should be, and they think it's a good vision. The problem is that in my experience, the vision of some of these folks as to what Fidonet should be is almost 180% degrees removed from what most of the "common sysops" I have spoken to want from Fidonet. If you are familiar with the names in the above list, you probably know what I'm talking about. With a couple of exceptions, most of these folks have a vision of Fidonet that is controlled from the top down, with the individual sysops having almost no say in how the net is FidoNews 6-52 Page 19 25 Dec 1989 operated. I'm sure that in their own minds, they are convinced that this is the best way to "run a railroad", but others might disagree (by the way, for what it's worth, you will notice that Tom Jennings, the founder of Fidonet, is not on the above committee. I've noted that he generally seems to not approve of these efforts to exert additional political controls over those using Fidonet technology). Now rather than simply take snipes at the people involved in this proposal, I'd like to point out some problems with the proposal itself. Some of these problems also exist in Policy4, by the way. The first is that any time we get into domain gating (which is what's really being proposed here), we are talking some major software changes in the network. Or else we are talking about having users add addressing information to messages manually, or both. In this proposal it appears that we are talking both, since not only will software be required to change addressing information at the domain gates, but users will be expected to add certain addressing information within the text of the message itself. Folks, we're adding a lot of additional complexity to the network here. Many sysops are of the opinion that we should "Keep It Simple, Stupid" but there are a few wannabe Usenet administrators in our net who would like to turn Fidonet into a very technically complex network. If we gain some real benefits from increased complexity, then the benefits may outweigh the problems. But where are the benefits to the average sysop here? The power players in Fidonet have continuously and deliberately ignored the simplest solution to the perceived problems... assign each "FidoNet Technology Network" (FTN) a block of net numbers for their use. Thus, within Zone 1, you know that any net with a number between 100 and 399 (or in the 3xxx range) is in Fidonet, while numbers from 400 to 799 are in Alternet, and so on. It would be much easier to formalize an addressing agreement between the other networks than to go through the hassle of setting up domain gates, and that would not break existing software, and would allow sysops to send mail to other networks with a minimum of hassle. The one thing we all agree on is that Zonegating (to alternate networks) doesn't work... but if we go to "domain gates", we will have many of the same problems we have with Zonegates. "A rose by any other name"... However, instead of going for a less complex, more easily implemented solution, the proposal introduces even greater complexity. Why? Well, I submit that it's because the great complexity, while doing little or nothing to advance communications, does allow a certain few to exert greater amounts of control over the network. Control over what? Well, consider the following paragraphs from the proposal: FidoNews 6-52 Page 20 25 Dec 1989 "FidoNet is now gated into Internet via UUCP. It has agreed to the terms and conditions necessary for membership in and connectivity to the Internet multi-network "umbrella". One obvious method for achieving connectivity to FidoNet (and a whole host of other wide area networks) is for the Other Network to apply to Internet for a gateway. Under this scenario, the Other Network is bound by the terms and conditions of Internet just as FidoNet is. In this peer relationship, the terms and conditions stated in this document are used by FidoNet to determine if Other Network message traffic arriving at a FidoNet/Internet gateway will be accepted into FidoNet." Now please note that in the above paragraph, it seems to be a given that Fidonet cannot dictate the terms and conditions under which it will accept messages from the Internet. That makes sense... Internet has been around a lot longer and is a lot larger, and quite frankly, many of the folks in Internet couldn't care less whether Fidonet is tied in or not. But if you read the above carefully, something else is being stated here. That is that if another network obtains connections to the Internet quite independent of Fidonet, and follows all the rules, regulations, terms and conditions of Internet, Fidonet may still elect to refuse message traffic based solely on the originating network. Who wants to bet that this provision would first be used to exclude traffic that originated on another FTN network? Actually, this whole document hold forth different standards for interconnection between a "FidoNet Technology Network" (FTN) and "All Other Networks" (see sections 3.6 and 3.7). Section 3.7 states: "3.7 - Other Criteria (FTN Other Networks) ----------------------------------------- Software allowing nodes in FTN Other Networks to simultaneously participate directly in FidoNet as valid FidoNet nodes, isolating the Other Network's addresses from FidoNet message traffic (i.e., using only valid FidoNet addresses in FidoNet message traffic) presently exists. This 'dual identity' approach is the method FidoNet expects nodes in the FTN Other Network will employ....." In other words, if you are running FTN software you are expected to have a Fidonet net/node number and to use it, rather than the address of your primary network. No mention is made of what you are supposed to do if you can't get a Fidonet node number (for example, if you want to be a private, unlisted node, since many of these have recently been excluded from the Fidonet nodelist). FidoNews 6-52 Page 21 25 Dec 1989 More from section 3.7: ".....the FTN Other Network must provide evidence of overriding technical or social considerations, must show cause why these considerations justify the establishment of a Gateway instead of merely allowing its individual nodes to use the 'dual identity' approach, and must satisfy FidoNet that such an arrangement will be mutually beneficial." And add in section 5.1: "5.1 - Interpretation -------------------- FidoNet retains the exclusive right to interpret the terms and conditions stated herein based upon its representatives' best understanding of those terms and conditions and upon its knowledge of the original intent of the authors." What we have here is Fidonet saying, in effect, that if you choose to use FTN software, you had better join Fidonet and use your Fidonet net/node number (and if for some reason you can't get one, you can always take up stamp collecting, I guess). Curiously, this only applies if you are using FTN software. This could actually encourage software authors to make their software slightly NON-FTSC compliant, so that users of that software could rightly claim that they are not in an "FTN Other Network" and obtain Gateway status on more favorable terms. Then there's section 3.4: "3.4 - Application of FidoNet Administrative Policy -------------------------------------------------- For the purposes of applying FidoNet policy, FidoNet will view the entire Other Network as a single FidoNet 'node' under the control of the individual named as the 'Administrative Contact / Responsible Party' (or an authorized agent thereof) in the administrative agreement outlined in paragraph 3.3 above. All other systems and their users will be viewed by FidoNet as users on the 'responsible party's' node for the purposes of FidoNet official policy application. FidoNet holds the operator of a FidoNet node responsible (from an administrative policy standpoint) for the actions of that node's users, subordinate 'point' systems, and the 'point' system's users. FidoNet views single or multiple Other Network Gateways as a single 'boss' node under the control of the 'responsible party' and will apply FidoNet official policy accordingly. FidoNet reserves the right to sever links to one or more of the Other Network's Gateways as its final remedy for violations of administrative policy....." FidoNews 6-52 Page 22 25 Dec 1989 I think the bottom line here is that we have a classic case of what is termed "Imperialism" when nations are involved. Basically, we have a large entity (Fidonet) saying that it will not participate as an "equal" in the "global community" (except in relationships with entities of larger size and status) but that rather feels that it should be able to set policies for smaller entities on a "take it or or leave it" basis... and the "take it" option in this case looks more like a takeover! It is my opinion that some (NOT all) of the folks on the "Gateway Policy Development Committee" still view the alternate networks as some sort of a "cancer" that should be cut out of electronic networking. But, as I pointed out in a recent message in the SYSOP echo, "We need more than one viable network that uses Fidonet technology. What do you suppose would happen if the Democrats and the Republicans (or the Liberals, PC's, and NDP's for those of you in the Great White North) were all merged into one political party? There would be so much infighting that nothing would ever be accomplished. Even our churches have found the need to divide into groups of like-minded people rather than constantly bicker over minor points of doctrine. So why do we, in a hobbyist communications network, think that we can force sysops who hold widely divergent views on how a network should be operated into one mold? "Rather than look upon alternate networks as an enemy of Fidonet, as something to be harassed and suppressed, you should realize that this is a place where those who don't agree with you can go and leave you (and those who agree with you) alone to get on with life. It never ceases to amaze me that folks who in one breath say that the Fidonet nodelist is getting too large and who are all for cutting out certain classes of nodes (private nodes, etc.) will nevertheless turn around and participate in the harassment, or the attempts to 'shun' those in other nets. They don't realize that these nets COULD be the SOLUTION to the problem, rather than the problem itself." There is one other section of the proposed policy that deserves some attention: "3.5 - Supported Message Types ----------------------------- FidoNet will grant Gateway interconnection for the purposes of exchanging messages of the type defined above as 'Netmail' and optionally for the purposes of exchanging messages of the type defined above as 'Echomail'. FidoNet will not grant Gateway interconnection for the purposes of exchanging 'Echomail' only. The ability to generate a private and personal 'Netmail' reply to an 'Echomail' message is one of the basic facets of FidoNet and cannot be compromised." FidoNews 6-52 Page 23 25 Dec 1989 If you believe this, I've got a nice bridge to sell you... Maybe this is how things should be in Fidonet, but that is not how they work now, at least not in Zone 1. I'll have more to say on this subject in an upcoming article, but for the purposes of this discussion, let me ask a couple of questions: 1) If I'm in an alternative network that has a "Gateway" with Fidonet, will I be able to just dump all my Netmail on the Fidonet Gateway and let the Gateway operator worry about sending it anywhere in Fidonet? Will anyone in Fidonet really want to become a Gateway if they have to send Netmail their own expense? Why should those in alternate networks have access to such a "one stop" delivery point for Fidonet Netmail when those who are in Fidonet enjoy no such privilege (except those fortunate enough to be on one of the few nets that have OGATEs)? 2) If Fidonet does NOT expect its "Gateway" systems to deliver Netmail anywhere in Fidonet, then why do they expect the smaller alternative networks to provide this capability? The smaller the net is, the more of a burden this could become. Also, this requirement could subject an alternate network Gateway to what would amount to "terrorist tactics" by someone in Fidonet, who could send large amounts of Netmail traffic to the Gateway and require the gateway node to either deliver or return it at his expense. It is a well known fact to just about every sysop in Fidonet that most sysops are in Fidonet to receive echomail, and could care less if Netmail service disappeared tomorrow. But the select few who do use Netmail regularly have made something of an idol out of it, and refuse to recognize that most of the sysops that have joined Fidonet in the last 2-3 years just don't care about Netmail. Fine, but if they are so concerned about Netmail, let them come up with a Netmail distribution scheme that WORKS, instead of trying to convince everyone that Netmail is so all-fired important by mere words. In the meantime, I feel that this particular section is totally inappropriate in this document. There's a lot more that I find objectionable in this document, but I fear I'm probably already pushing the limits for length of a Fidonews article. I hope it's never adopted, or failing that, that it undergoes some pretty serious revision first, preferably by some folks who do not believe that Fidonet is at the center of the universe. Since I am probably spitting into the wind anyway, I will just offer a few suggestion to those in the alternate networks: Begin linking conferences with each other! Stop depending on the Fidonet backbone for all your echomail traffic. Start listing your nodes in the OPCN nodelist so you can communicate with each other if you find yourself locked out of Fidonet (contact 1:234/1 or 1:236/7 for information). Develop your own independent links into networks such as Internet and Usenet. I FidoNews 6-52 Page 24 25 Dec 1989 will be truly amazed if anyone actually heeds these warnings, but at least I tried... ----------------------------------------------------------------- FidoNews 6-52 Page 25 25 Dec 1989 ================================================================= LATEST VERSIONS ================================================================= Latest Software Versions MS-DOS Systems -------------- Bulletin Board Software Name Version Name Version Name Version Fido 12q+ Phoenix 1.3 TBBS 2.1 Lynx 1.30 QuickBBS 2.61* TComm/TCommNet 3.4 Kitten 2.16 RBBS 17.2B TPBoard 6.0 Opus 1.03b+ RBBSmail 17.2 Wildcat! 2.10* Network Node List Other Mailers Version Utilities Version Utilities Version BinkleyTerm 2.30 EditNL 4.00 ARC 6.02 D'Bridge 1.30* MakeNL 2.20 ARCA06 2.20* Dutchie 2.90C ParseList 1.30 ARCmail 2.0 FrontDoor 2.0 Prune 1.40 ConfMail 4.00 PRENM 1.47 SysNL 3.01* EMM 2.02 SEAdog 4.51b XlatList 2.90 Gmail 2.01 XlaxDiff 2.32 GROUP 2.16 XlaxNode 2.32 GUS 1.30* LHARC 1.13 MSG 4.0 MSGED 1.99 PK[UN]ZIP 1.02* QM 1.0 QSORT 4.03 StarLink 1.01 TCOMMail 2.2 TMail 1.12 TPBNetEd 3.2 UFGATE 1.03 XRS 3.0 ZmailQ 1.09 Macintosh --------- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Red Ryder Host v2.1b3 Macpoint 0.91* MacArc 0.04 Mansion 7.12 Tabby 2.1 ArcMac 1.3 WWIV (Mac) 3.0 StuffIt 1.51 FidoNews 6-52 Page 26 25 Dec 1989 TImport 1.331 TExport 1.32 Timestamp 1.6 Tset 1.3 Timestart 1.1 Tally 1.1 Mehitabel 1.2 Archie 1.60 Jennifer 0.25b2g Numberizer 1.5c MessageEdit 1.0 Mantissa 1.0 PreStamp 2.01 R.PreStamp 2.01 Saphire 2.1t Epistle II 1.01 Import 2.52 Export 2.54 Sundial 2.1 AreaFix 1.1 Probe 0.052 Terminator 1.1 TMM 4.0b UNZIP 1.01* Amiga ----- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Paragon 2.00+* BinkleyTerm 1.00 AmigArc 0.23 TrapDoor 1.11 booz 1.01 WelMat 0.35* ConfMail 1.10 ChameleonEdit 0.10 Lharc 1.00* ParseLst 1.30 PkAX 1.00 RMB 1.30 UNzip 0.86 Zoo 2.00 Atari ST -------- Bulletin Board Software Network Mailer Other Utilities Name Version Name Version Name Version FIDOdoor/ST 1.4f* BinkleyTerm 1.03g3 ConfMail 1.00 Pandora BBS 2.41c* The BOX 1.20* ParseList 1.30 QuickBBS/ST 0.40 ARC 5.21c* GS Point 0.61 TurboArc 1.1 FidoNews 6-52 Page 27 25 Dec 1989 LHARC 0.51* PKUNZIP 1.10* MSGED 1.96S SRENUM 6.2 Trenum 0.10* OMMM 1.40* + 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 6-52 Page 28 25 Dec 1989 ================================================================= NOTICES ================================================================= The Interrupt Stack 30 Dec 1989 Telephone area codes (5, 3 and 0) are abolished in Hong Kong 1 Feb 1990 Deadline for IFNA Policy and Bylaws election 5 Jun 1990 David Dodell's 33rd Birthday 5 Oct 1990 21st Anniversary of "Monty Python's Flying Circus" If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. ----------------------------------------------------------------- FidoNews 6-52 Page 29 25 Dec 1989 OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION Thom Henderson 1:107/528 Chairman of the Board Les Kooyman 1:204/501 President Fabian Gordon 1:107/323 Vice President Bill Bolton 3:3/0 Vice President-Technical Coordinator Kris Veitch 1:147/30 Secretary Kris Veitch 1:147/30 Treasurer IFNA COMMITTEE AND BOARD CHAIRS Administration and Finance * By-laws and Rules John Roberts 1:385/49 Executive Committee (Pres) Les Kooyman 1:204/501 International Affairs * Membership Services Jim Vaughan 1:226/300 Nominations and Elections Steve Bonine 1:1/0 Public Affairs David Drexler 1:147/30.20 Publications Irene Henderson 1:107/9 Technical Standards Rick Moore 1:115/333 Ethics * Security and Privacy * Grievances * * Position in abeyance pending reorganization IFNA BOARD OF DIRECTORS DIVISION AT-LARGE 10 Courtney Harris 1:102/732 Don Daniels 1:107/210 11 John Rafuse 1:12/900 Phil Buonomo 1:107/583 12 Bill Bolton 3:711/403 Mark Hawthorne 1:107/238 13 Fabian Gordon 1:107/323 Tom Jennings 1:125/111 14 Ken Kaplan 1:100/22 Irene Henderson 1:107/509 15 Kevin McNeil 1:128/45 Steve Jordan 1:206/2871 16 Ivan Schaffel 1:141/390 Robert Rudolph 1:261/628 17 Kathi Crockett 1:134/30 Dave Melnik 1:107/233 18 Andrew Adler 1:135/47 Jim Hruby 1:107/536 19 Kris Veitch 1:147/30 Burt Juda 1:107/528 2 Henk Wevers 2:500/1 Karl Schinke 1:107/516 3 Matt Whelan 3:54/99 John Roberts 1:147/14 ----------------------------------------------------------------- FidoNews 6-52 Page 30 25 Dec 1989 __ 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 PO Box 41143 St Louis, Missouri 63141 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 second elected Board of Directors was filled in August 1988. The IFNA Echomail Conference has been established on FidoNet to assist the Board. We welcome your input to this Conference. FidoNews 6-52 Page 31 25 Dec 1989 -----------------------------------------------------------------