Volume 4, Number 41 9 November 1987 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Contributing Editors: Dave Lovell, 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. Table of Contents 1. ARTICLES ................................................. 1 Building the LATINO Net .................................. 1 Some Comments on the Proposed Policy4 .................... 3 Preferred Inbound and Alternate Inbound: A Routing Prop .. 9 SEA Letter: ARCmail, DTTY ................................ 14 FidoCon V ................................................ 16 2. NOTICES .................................................. 18 The Interrupt Stack ...................................... 18 Latest Software Versions ................................. 18 3. COMMITTEE REPORTS ........................................ 19 IFNA Status Report for November 1987 ..................... 19 FidoNews 4-41 Page 1 9 Nov 1987 ================================================================= ARTICLES ================================================================= Travis Good, 102/851 Building the LATINO Net Have you noticed what's been happening in the NodeList lately? Other than continued growth, a second phenomenon is that we've been getting nodes from Latin America. There are now nodes in Puerto Rico, Argentina, and Suriname (OK trivia experts, where's "Suriname"?). Juan Davila of San Juan, Puerto Rico (18/3 soon to be 367/0) says that though there are only two nodes presently in Puerto Rico he already sees 5 to 6 more by year-end. Pablo Kleinman of Buenos Aires (18/5) shows that Argentina is really on the ball. Just last week he wrote Ken Kaplan and got four nodes added to the list in one shot. Growth in Argentina is expected to take off too. So why all this sudden interest? One reason might be that La Nacion ("South America's New York Times" according to Pablo) recently published the history of the FidoNet in their Home Computing section. Another is that international telecommunications is finally past the stage of being cost prohibitive. What ever the reasons it's a healthy development. Could Zone 4 be far off? Only time will tell but in the mean time we can do things to raise the Latin American participation level. At the end of this article I have two specific questions to ask of anyone interested in helping the effort. Below are some ideas on what might be done. These are presented in hopes that some of you might be interested in pursuing some of them. Regular E-mail Link =================== Outbound and inbound gates through which to channel all Latin American traffic to the U.S. need to be established. As part of this it would probably make sense to do an analysis of just what routing was cheapest; e.g. a call during National Mail Hour to Argentina from the U.S. using MCI costs $1.55 for the first minute plus $0.66 for each additional minute. Probably far less than what it costs for Argentina to initiate phone calls. Since we're all hobbyists we should try to keep costs down, no? Spanish-language Echo ===================== This would be a means by which interested people could find out about FidoNet and new nodes could get questions answered about participating in the Net. This echo would be a takeoff point and would hopefully spawn other Spanish-language echos. FidoNews 4-41 Page 2 9 Nov 1987 We're in the early stages of establishing a three-hub echo network. Pablo for South America, Juan for Caribbean, and my node (102/851) for the Southwest. Of course, this is just the beginning and we would hope that it eventually will include every Latin American country. FidoNews Articles ================= Having something printed in the weekly FidoNews is a good way of elevating awareness within the FidoNet community. If articles were published promoting the Spanish-language echo, advancing growth of the LATINO Net, and occassionally written in Spanish the network world would certainly become more cognizant of the effort. IFNA Promotion Literature in Spanish ==================================== Some of the key IFNA literature needs to be translated into Spanish for potential Latin American members to understand about the network and the organization. Without some decent reading it will be hard for people to get too enthused. Pablo, Juan and I want to do what we can to help the Net grow. We hope you'll join us. Give us your ideas, take on some role of your own, and jump on the wagon. OK, now for the end of the article and my two questions: 1) Can anyone provide additional names of people in Latin America who might be interested in joining the Net? We'd like at least one node in each major city in each Spanish- and Portuguese-speaking country. Having this would get us to critical mass and the Latino Net can grow by itself. 2) Anyone out there interested in participating in a Spanish- language echo? There's a lot of curve climbing that needs to be done and we would use all the expertise we can get. The LATINO echo will be available in the U.S. from 102/851. For further information or for feedback please contact any of the three of us. We're all available during Mail Hour and soon will all be up 24 hours per day. ----------------------------------------------------------------- FidoNews 4-41 Page 3 9 Nov 1987 Brad Hicks Director-at-Large, IFNA Sysop WeirdBase, 1:100/523 Since discussion has been solicited on Policy4, here are my full comments on the subject. Each section that will consist of the section number, original quote, my comment, and a proposed revision if any. These are emphatically =not= the official positions of the board of directors, but these are some of the issues being discussed in IFNA_BOD echo. Make your feelings known to me or to any member of the Board of Directors. -------------------- SECTION 1.1 The Levels of FidoNet "o Nodes; A node is a single FidoNet address, and is the smallest recognized unit of FidoNet. o Points; A point is a node on a private network which is accessible through a node on FidoNet." COMMENTARY: Smallest? Not an ideal word, especially since some very popular BBS's have more users than some of the smaller nets. Could also be perjorative. And in fact, with sub-sub- points available with PointMap, it's no longer quite true. A node is, however, the primary building-block of the published nodelist. I also think it might be nice if we said something more about bulletin-board systems in these definitions, so as to put things in terms that even non-FidoNet folk can have a referent, something to get a handle on what we're talking about. SUGGESTION: "o Nodes; A node is a single address in the international node list, the most basic building block of FidoNet. It usually corresponds to a single bulletin board system. o Points; A point is a system which sends or receives mail through a node, and is not independently listed in the international node list. As such, there are fewer demands upon such a system. A point usually corresponds to a single user of a bulletin board system." -------------------- SECTION 1.2 Coordinators "o The Point Coordinator; Any node in FidoNet can act as a gateway to a point network. ... o The Sysop; A Sysop formulates his own policy for running his board and dealing with his users, so that will not be discussed in this document. ..." COMMENTARY: Excuse me if I seem obsessed with definitions. FidoNews 4-41 Page 4 9 Nov 1987 First of all, I cannot think of a single reason why these two paragraphs shouldn't be merged. Secondly, what exactly is a sysop? Does a mail-only node have a sysop? How about a point? Could it be that we should drop the word? I also see no point whatsoever in discussing at this point in the document what will not be discussed. If it's not to be discussed, let's not discuss it! SUGGESTION: "o The Node Coordinator (Sysop): Anyone who actually operates a node on the FidoNet is a Node Coordinator. A Node Coordinator is responsible for his own network mail and that of any points below him, or users on his node if he or she is a system operator." -------------------- CHAPTER 2 SYSOP PROCEDURES "A sysop of an individual node can pretty much do as he pleases, as long as he ... is not excessively annoying to other nodes on FidoNet, and does not promote the distribution of pirated copyrighted software." COMMENTARY: We still haven't defined "excessively annoying." We need to do so -- or at least give better examples. Are bombing runs "excessively annoying?" (I think so.) Is sending advertising un-solicited? (I think so.) How about insulting another sysop? (I think not.) Racism, sexism, or bigotry? How about censorship? (Let's discuss these.) And then there's the whole issue of echomail conduct ... And then there's the fact that pirating copyrighted software is not the ONLY crime that can be perpetuated by a BBS. Does this imply that we'll wink at fraud? Chain-letter or pyramid schemes? SUGGESTION: "... is not excessively annoying to other nodes on FidoNet (see section x.x.x below for guidelines), and does not use the FidoNet for the commission of a crime, such as distribution of pirated software." -------------------- CHAPTER 2 SYSOP PROCEDURES "National Mail Hour is the heart of FidoNet, as this is when network mail is passed between systems. Any system which wishes to be a part of FidoNet must be able to receive mail at this time. ... Failure to observe the proper mail events is sufficient grounds for any node to be dropped from FidoNet without notice (since notice is generally given by FidoNet mail). ..." COMMENTARY: Now that the use of Points makes possible special FidoNews 4-41 Page 5 9 Nov 1987 gateways, I think this is even more important than ever. I stand 110% four-squarely behind these paragraphs. Now ... do we want to go farther? Consider the existence of nodes with no listed phone number. (1) Since no one can call them without making special arrangements, do they need to observe NMH? On the other hand, (2) since they cannot be called directly, do they have any place in the nodelist? One area where I feel particularly strongly about this is unlisted nodes not in a network, since there is effectively no way to send mail to these people - so why list them at all? -------------------- SECTION 2.1 How to get a node number "Your application for a node number must be sent to the coordinator by FidoNet mail, and must include at least the following: 1) Your name. ... 6) The maximum baud rate you can support." COMMENTARY: As a person who finds Bob Hoffman's use of another machine to mimic the one he wanted, thereby requesting two separate node numbers from the same machine, excessively annoying, I would add to this "... directly from the machine requesting the address, ..." It also occurs to me that this is an excellent place to enforce at least SOME degree of familiarity with POLICY4, by adding another requirement. SUGGESTION: "Your application for a node number must be sent to the coordinator by FidoNet mail directly from the machine requesting the address, and must include at least the following: ... 7) A statement to the effect that you have read, are familiar with, and will abide by the rules in version 4 of POLICY.DOC." -------------------- SECTION 3.2 Node list distribution "The node list is posted weekly on Saturday, along with a 'difference file' giving the changes for the week. It is your responsibility to obtain the difference file from your coordinator every week and to distribute it to the coordinators below you. ..." COMMENTARY (Minor quibbles, both): (1) I think it's a bad idea in general to have so much of the traffic tied to a specific day when we all know that sometimes it doesn't happen that way. Frankly, I've set my system up so that whatever day Rich crashes FidoNews 4-41 Page 6 9 Nov 1987 the NODEDIFF through, I'll process it. So let's make it "weekly, usually on Saturday." (2) Suggested clarification: "... and to distribute it to the coordinators and nodes directly below you." -------------------- SECTION 3.6.3 Regional Coordinator procedures "A Regional Coordinator should try to avoid the needless proliferation of networks. Networks should not be allocated on any basis other than technical and practical considerations relating to network mail operations. For example, persons wishing to establish networks on the basis of special interests or for company mail should be encouraged to investigate the alternatives, such as echomail conferences and point networks." COMMENTARY: I notice that as written, this section makes no mention of geography. Does this mean that is =is= OK for a node in Philadelphia to host the network for Arkansas? Does this say anything about two or more networks that cover the same range of phone numbers, such as nets 102 & 103, or 125 & 161? -------------------- SECTION 3.6.4 Network Coordinator procedures "3) The most common source of routing overload is echomail. Echomail is a nice invention, and offers great benefits, but it cannot be allowed to degrade the ability of FidoNet to handle normal message traffic. If a node in a network is routing large volumes of echomail, the sysop can be asked to either limit the amount of echomail, or even to stop routing his echomail completely. The design of echomail is such that it is a simple matter to do either of these." COMMENTARY: As this problem is ancient history, and as this problem is also used for an example (4.1.7), I find this entire paragraph redundant. In fact, I'd blow all three of these paragraphs into one much shorter sentence. SUGGESTION: "If for any reason, a single node is receiving a dis- proportionate amount of the mail addressed to its network, the network coordinator should require the node to either arrange for the mail to be sent direct or the node should be referred to the region coordinator to become an independent node, achieving the same end." -------------------- CHAPTER 4 RESOLUTION OF DISPUTES "... In other words, there are no hard and fast rules of con- duct, but reasonably polite behavior is expected. ..." FidoNews 4-41 Page 7 9 Nov 1987 COMMENTARY: I believe we want this to read, "... there are FEW hard and fast rules of conduct ..." -------------------- SECTION 4.1 Case Histories "A few actual case histories of past disputes may be instructive to show general procedures and methods." COMMENTARY: And then again, they might not. This whole section makes me vaguely uncomfortable. It's chatty, it gives few or no general principles to extrapolate from, and despite the fact that it coyly leaves out names and addresses, it invites speculation. (The fact that I happen to be case 4.1.7 is irrelevant. I'd feel the same way even if it weren't me being pilloried behind that gauze curtain.) (Grin) I would much, much rather see this entire section re-written, after MUCH discussion, into a list of behaviours which have been found "extemely annoying" in the past, and/or which we have decided (will have decided, rather) are "extremely annoying." -------------------- SECTION 4.1.1 The Case of the Crooked Node "A sysop of a local node was using network mail to engage in un- ethical business practices. ... Independent status was denied." COMMENTARY: Do we mean illegal? If so, let's say illegal. Unethical by whose standards? This is why I don't like the whole coy, chatty/catty tone of this chapter. I =don't= like the idea that somebody can be kicked out of the nodelist because one host thinks he's a bit shady. C'mon, are we going to ban nodes by ambulance-chasing personal-injury law firms? By share- lease real estate salesmen? Or do we actually want legal proceedings? Is the word of the local BBB sufficient? -------------------- SECTION 4.1.6 The Case of the Sysop Twit "A patron of various local nodes had been roundly recognized by all sysops as a twit. The user obtained his own system, became a sysop, and applied for a node number. The Network Coordinator denied the request. No appeals were made." COMMENTARY: This one makes me almost as uncomfortable as 4.1.1, for similar reasons. It's vague. It tells us nothing. What's a "twit?" Someone who's young? Someone who treats female users/sysops in a sexist fashion? Or do we have to go all the way up to attempted crashers ... in which case, this section is redundant with "The Case of the Hacker Mailer." Is Bob Hoffman a twit? How about Adam Selene? How about Mike? How about me? Who decides? And does that last line imply that appeals would have been seriously considered, or not? FidoNews 4-41 Page 8 9 Nov 1987 -------------------- SECTION 4.1.7 The Case of the EchoMail Junkey key key "A local node became enamored with EchoMail and joined several conferences, routing his outbound mail through his network. He then started an EchoMail conference of his own and began relaying EchoMail between several systems, again routing it all through his network." COMMENTARY: Since I was there, I know that this one neglects a lot of what =I= (as the accused) think are important facts: like the fact that I had permission to route a few of those conferences through 100/10; the fact that I couldn't bloody well STOP folks from sending me mail via 100/0 (what was I supposed to do, mail them a letter bomb?); and the most important fact that the packets that actually affected network mail performance were NOT intentional on my part, they were accidental - I had my route-file set up incorrectly. Would Ken Kaplan really have ejected me from the node list for an honest, easy-to-make technical mistake which I corrected as soon as possible? ----------------------------------------------------------------- FidoNews 4-41 Page 9 9 Nov 1987 Jack Decker, 120/64 Preferred Inbound and Alternate Inbound A Routing Proposal (This article is NOT COPYRIGHTED and may be reproduced by anyone, in any form, with no strings attached.) The present scheme of regions, hosts, hubs, and nodes within Fidonet was developed in an era when, by and large, all telephone costs were distance-sensitive (and where the costs always increased when your call terminated at a more distant point). Even at that time those assumptions were not always true (due to the use of leased lines and the generally higher cost for in- state calls as opposed to out-of-state calls) but now that we have PC Pursuit and AT&T's Reach Out America plan, distance is often of no consideration in making modem calls. Still, nets are often arranged geographically, with all BBS's in a given region grouped together on a geographic basis. This works well enough when an entire net is located in a major metropolitan area, but it often does not meet the needs of Sysops in more remote areas. The major reason that it doesn't work well is that the backwater Sysop's HOST is probably accessible only via the long distance phone system, and the HOST itself may be in only a medium-sized city. Consider, for a moment, the disadvantages that our rural Sysop will face: 1) He will probably be expected to POLL his host for mail on a regular basis, even though the volume of received mail may be very low. 2) He probably does not yet have access to an alternate long distance carrier, let alone a packet network or PC Pursuit, so his calls to the host will be at AT&T long distance rates. If the host is located in the same state and is some distance away, those rates may be VERY high, even at night! 3) If the host is not in a PC-Pursuitable city, other Sysops will charge their users to send mail through to the remote board (if they allow it at all). This, in turn, will lower the volume of received mail, making the prospect of having to poll the host regularly even less attractive. What we are talking here is COST. The Sysop who is out of the mainstream of traffic may have expenses that are many times those of a sysop living in a larger city. But inefficient routing can also affect Sysops in more populated areas. For example, if your inbound host is a long distance call (and is not PC Pursuitable), it's still going to cost you to connect with him even though you may be able to access other hosts (of other nets) for free or for less money. I'm sure that others have suggested that the whole Fidonet system FidoNews 4-41 Page 10 9 Nov 1987 be reconfigured to take maximum advantage of PC Pursuit or Reach Out America or some other quirk in local calling rates. There are a couple of major problems with that, however. The first is that if the service that the net is configured around goes down or has a dramatic rate increase, you're right back to inefficient routing (for example, if the proposed FCC regulations go through and PC Pursuit is discontinued, I can guarantee you that there will be some major changes in the way that Echomail is being routed!). The second is that the geographic unity of a net is not something that should be easily cast aside. It is nice (and usually very beneficial) to be in frequent communication with other Sysops in your own area! Therefore, I have a proposal that would retain the present net/hub/node structure but would allow calls to be rerouted based on least-cost principles, where the sysop of the receiving board is willing to put a little effort into making it happen. My proposal involves new comments in the miscellaneous field of the nodelist: AI:net/node - An alternate inbound routing that MAY be used if it is less cost to the calling board. PI:net/node - A PREFERRED alternate inbound routing that SHOULD be used by the calling board if it is the same cost or less cost than host routing or direct routing. This might be used when it is a toll call from the receiving board to the net host, but a "free" (PC Pursuit, possibly?) call to the preferred alternate. In either case, more than one net/node may be specified. Let me give a hypothetical example of how such routing might save some money. Since a picture is supposed to be worth 1,000 words and I'm tired of typing, please refer to the following diagram of nodes in imaginary net 999: 999/999 999/123 888/888 777/777 BACKWATER <-----> SMALLTOWN ----> HUBTOWN -----> METRO x x | | (TELENET (PC PURSUIT x x ACCESS) INBOUND CITY) HOST 999/0 (TOLL CALL) Let's assume that BACKWATER is at the edge of nowhere, but is within the local telephone calling area of SMALLTOWN, which is, presumably, in the middle of nowhere! In our hypothetical example, the Net 999 Host is a toll call for both boards but the Sysop of the Smalltown board happens to be a business owner with a direct line (foreign exchange or WATS, perhaps) to HUBTOWN, which as it happens is the location of a HUB for net 888 (unfortunately, that's NOT part of the same net!). Our Smalltown BBS operator POLLs the Hubtown node daily to pick up echoes and whatever mail might be incidentally routed that way. Meanwhile, the Hubtown node operator, which has access to a Telenet local line, places a daily call via PC Pursuit to POLL node 777/777 in FidoNews 4-41 Page 11 9 Nov 1987 METRO for mail. Under the present setup, both the Backwater and Smalltown Sysops would have to POLL their host to receive incoming matrix mail. Of course, they could realign themselves to be under Net 888, ASSUMING that the host of node 888 has no objections and the regional coordinator(s) involved are willing to allow the transfer - but what if, two months later, the Sysop of the Smalltown node decides to pull the plug on his system? Then the Backwater Sysop is left high and dry, with no connection to Net 999 and the possibility of a not-too-satisfying relationship with Net 888. Let's suppose, however, that our Backwater Sysop would take the initiative to contact all of the nodes involved and set up the following arrangement: METRO 777/777 receives mail for Backwater - this in effect makes the Backwater board PC Pursuitable for mail purposes - and HOLDs it for pickup by HUBTOWN 888/888. HUBTOWN 888/888 in turn HOLDs it for pickup by SMALLTOWN 999/123. When 999/123 receives the mail packet, he immediately CRASHes it to 999/999 because it's a local call. This much of it is all workable under the present system. The only problem is that any Sysop that simply runs Xlatlist, without knowing about this arrangement, will automatically route mail for 999/999 to the Host (999/0) which, as noted earlier, happens to be a toll call for the Net 999 boards in question. Now, if our Backwater Sysop could some convince everyone to ARC his mail TO 888/888 or 777/777, he'd be in fine shape. He wouldn't have to Poll the host to get his mail. So how does he do this? Under my proposal, he would place this comment in the nodelist: PI:888/888 777/777 This would tell other Sysops that, if it is a toll call to his board, he would prefer that mail be routed to 888/888 or 777/777 rather than to the Net 999 Host. On the sending end, the program that handles the mail (that would have to be written to implement this scheme) would use this logic to route the outgoing call: 1) Is 999/999 a local/zero cost call? If so, direct route it. 2) Is 888/888 a local/zero cost call? If so, route it via 888/888. 3) Is 777/777 a local/zero cost call? If so, route it via 777/777. 4) Is the HOST (999/0) a local/zero cost call? If so, host route it (the HOST may still receive some inbound mail for this node, but he may be able to Arc it To a node in the Backwater system's "free" path, if the call is also "free" for him.) FidoNews 4-41 Page 12 9 Nov 1987 5) If all of the above are toll calls, then check the cost fields to determine which of routing direct to 999/999, indirect via 888/888, indirect via 777/777, or indirect via the host (999/0) is the least expensive and use that method. 6) Where the costs are the same, the first choice would be direct routing. Since this was set up as a Preferred Inbound, the second and third choices would be to route via 888/888 or 777/777. Host routing would only be used if it was clearly the lowest cost choice for the sender. Now let's change the scenario a bit. Suppose that the above diagram is the same except that the HOST happens to be a local call. In this case, the Backwater Sysop isn't out anything when he polls the host, so he doesn't care if other boards send mail directly to his board, or route it via his Host. The only problem with this scenario is that the Host isn't in a PC Pursuitable city, which means that users in distant areas have to pay their Sysops to send mail to Backwater. Now, instead of PI: (Preferred Inbound), the Backwater Sysop would use AI: (Alternate Inbound). This simply reverses the priorities so that Host routing would be preferred over the use of 888/888 or 777/777 for inbound mail, BUT if it is a zero cost (or lower cost) call for the originating BBS, it MAY route via one of the other two boards. Of course, the above describes one particular situation (any similarity to a real-life situation is purely coincedental) but the ability to use the PI and AI comments (one or both) in the comment field might permit mail to flow at a lot lower cost. More importantly, I think, is that existing Net bonds are not destroyed and if something changes, changing the preferred or alternate routing is as easy as making a change in the nodelist. Now, how would a PI: or AI: be used at the sending end? Well, the lo-tech method would be for a Sysop to manually eyeball the nodelist and look for the PI's and AI's. Let's suppose he found the Backwater BBS and, because he was a PC Pursuit user, could call 777/777 for free. He would then insert a statement such as ArcTo 777/777 999/999 in his route control file. Most Sysops wouldn't enjoy doing this very much (although they might make the necessary adjustments for frequently-called nodes), so I'm sure that someone would write a utility that would scan the nodelist (after xlatlist processing) and generate appropriate statements for the route control file. Such a utility, when it encountered a PI: or AI: statement, would check the cost fields of the boards referenced by the PI: or AI: and generate any necessary statements based on the logic outlined above. If the board with the PI: or AI: statements happened to be a Host or a Hub, then the routing for all boards below that host or hub would also be checked and changed if the alternate routing could be accomplished at lower cost. Ultimately, a new version of xlatlist might handle all of this automatically, or a newer version of the BBS or mail-handler program (whichever brand you're using) might read the comments and make the necessary adjustments in calling patterns. FidoNews 4-41 Page 13 9 Nov 1987 As with anything, this kind of alternate routing capability could be misused (I can envision "super" mailboards in the large PC Pursuit cities becoming nearly impossible to reach due to overloads), so it would have to be used with some restraint to spread the message traffic evenly. But I also think that many Sysops would welcome this method of reducing costs for outgoing mail, while at the same time encouraging a freer flow of mail to the boards in the outlying areas. Comments on this proposal may be left to me via the BIXNET BBS (120/64, 616-361-7500 300/1200/2400bps), although I really can't do much more to develop it. The idea is simple, could be implemented NOW in a limited manner, and when appropriate software is written could be more fully implemented. For the present, a Sysop could just ignore the PI: and AI: comments and continue to Host route mail, or could manually make changes to his route control file for as many boards as he cares to make the effort. I hope that this idea will receive some consideration among those in the Fidonet community. Jack Decker ----------------------------------------------------------------- FidoNews 4-41 Page 14 9 Nov 1987 Kilgore Trout, 1:107/6 What's Happening at SEA? Did you ever try to send 4096 blocks of echomail to someone, just to have the line die on you after 4095 blocks? Frustrating, isn't it? A few people have thought about ways to handle that. Answers range from lots of little mail relays throughout the day to implementing a ZMODEM based protocol that can resume an aborted transfer in the middle. But nobody has actually implemented a workable solution. Until now, that is. As of 3 November 1987, SEA has released version 1.11 of our popular ARCmail program. This version adds a variation of the -d parameter to create discrete archives based on the size of the previous archive. For example, suppose you have two mail archives waiting to go out. One of them is going to 107/312 and is 120k in size. The other is going to 107/16 and is 50k in size. You are now about to send another 30k of mail to each person. If you give the command: arcmail to 107/312 107/16 -d100 ARCmail 1.11 will add the packet to the archive to 107/16, because his archive is still small. But the archive for 107/312 is larger than 100k, so ARCmail will create a new archive for him. "-d100" means "create a new archive if the old one is larger than 100k" (you can vary the size, of course). So how does this answer the problem, you ask? Simple. SEAdog keeps track of what files have or have not been sent, and will not resend a file that has already been sent. Thus, the 4096 block archive in our earlier example will now be sent as five smaller archives, and if the line drops while the last archive is being sent, then ONLY the last archive will be sent on the next call. In other news, we have also released version 1.23 of the DTTY terminal program. DTTY still isn't very bright, but now she knows better than to call a board that has an unpublished number. Two other changes have been made: 1) DTTY will now respond to an ENQ with your name, as listed in your CONFIG.DOG file, in the format "First;Last". People who call TBBS boards a lot should appreciate this. 2) The Give and Ask commands have been modified to work with Opus upload and download. Any of the DTTY supported protocols may be used. FidoNews 4-41 Page 15 9 Nov 1987 Products mentioned in this article may be file requested from 1:107/6 at any time outside of National Mail Hour, or may be downloaded from the SEA customer support board at (201) 473-1991. Product Filename to request ARCmail 1.11 MGMARCM.ARC ARCmail documentation MGMDOCS.ARC DTTY 1.23 DTTY.ARC ----------------------------------------------------------------- FidoNews 4-41 Page 16 9 Nov 1987 Eric Ewanco, 1:130/3.0 Fort Worth, TX FidoCon V How convenient that the Oct 5 FidoNews should have a request for suggestions on where FidoCon V should be held, I just send a letter to Mr. President about where I thought it should be held. Well, I'll publish it here and forward a copy to the RIGHT place, now. Although I cannot answer every question posed there, I can probably get pretty far. My suggestion is to hold it at the InfoMart in downtown Dallas. Dallas is home to many computer hobbists (just look at the size of net 124) and the InfoMart is an ideal place for any computer-related conference. It is seven floors and features such things as talking elevators, automatic flushing urinals (programmers are so forgetful), a bar, a cafeteria, underground parking, many many many rooms and auditoriums, a computer bookstore, and a basement that can hold several hundred vendors. The InfoMart was specifically designed for computer conferences and for permanent vendor displays. Tandy, IBM, Xerox, and many other companies whose names I've never heard of have permanent "booths" there where clients can come by and get demonstrations. It is also the home, on the 2nd Saturday of every month, of the Dallas Computer Council user's group meetings, where hundreds of vendors with rock-bottom prices crowd the basement and groups for Apples to Zeniths have their meetings and talk about everything from C to 1-2-3 to dBase, representing almost every interest. Since it is in downtown Dallas, I imagine everything you need will be right there. There is public transportation (DART), but as far as "shuttles" as such I do not know. There are hotels down there, and I'm sure they've struck up some kind of deal with InfoMart. I'm sure the price is right; if DCC, being made almost exclusively of hobbists, can meet there every month without charging a mandatory fee, I'm sure we can, particularly if we can produce non-profit organization status. Net 124 would probably host it if it came to that (Wynn Wagner lives in Dallas, another plus), and I certainly can't speak for them whether they can do all those things (make T-SHIRTS and SOUVENIRS available? GIMME A BREAK!) but net 124 is strong and I'm sure they could if they wanted to. Net 130 (Fort Worth, a half-hour away) would be willing to help if it came to that. Since August gets really hot in Dallas, I recommend something earlier, perhaps the second or third week in June or thereabouts, or even in July. Dallas is a growing technological city that can offer an awful lot in the area of entertaining Fido sysops. InfoMart is an excellent place for a computer conference and was designed FidoNews 4-41 Page 17 9 Nov 1987 specifically for that purpose. The airport is easily accessable and DFW is a major airport (it is one of American's hubs) and there should be no problem getting a non-stop. I hope that IFNA will seriously look into Dallas as the home for FidoCon V (geez, that sounds like a sci-fi movie....) ----------------------------------------------------------------- FidoNews 4-41 Page 18 9 Nov 1987 ================================================================= NOTICES ================================================================= The Interrupt Stack 14 Nov 1987 The First New England Sysop Conference, to be held at the Lederle Graduate Research Center, 16 Floor University of Massachusetts, Amherst. Contact Mort Sternheim at 1:321/109 for details. 7 Dec 1987 Start of the Digital Equipment Users Society meeting in Anaheim, CA. Contact Mark Buda at 1:132/777 for details. 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.71* EditNL 3.3 ARC 5.21 Fido 12d* MakeNL 1.10 ARCmail 1.1* Opus 1.03a Prune 1.40 ConfMail 3.2* SEAdog 4.10 XlatList 2.84 EchoMail 1.31 TBBS 2.0M MGM 1.1* * 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 4-41 Page 19 9 Nov 1987 ================================================================= COMMITTEE REPORTS ================================================================= Don Daniels, President International FidoNet Association FidoNet 1:107/210 IFNA Status Report for November 1987 PROGRESS DURING THIS PERIOD General I am sorry to report that this Status Report will not be as positive as I might had hoped, as we are still being plagued by start-up problems. That is not to say that a lot of individuals have not pitched in are doing a good job, because that does seems to be the case. Rather, our problems seem to primary be that of an administrative and management nature. It is hoped, however, that we are building up some inertia in the right directions. This month I only received two status reports from the various Committee Chairmen. A synopsis of their reports and some additional concerns are included below. Administration and Finance Ken Kaplan met with Treasurer Leonard Mednick in St. Louis in what seems to have been a very productive meeting. Len informs me that we is still waiting on some additional material being forwarded by Ken, but we have already seen the beginnings of new forms and procedures to make various of our operations easier to perform and manage. Board of Directors No report this month. By-laws and Rules The Chairman of this committee informed me that he was taking a month off because of some personal concerns. Last night I heard that he is back and will be picking up efforts next month. Executive Committee This month has primarily centered on organizational concerns. International Affairs This committee has not still not "met" as of yet, primarily because of our own domestic focus. However, so many items of concern are happening overseas that it looks like we can't put this off any longer. Membership Services FidoNews 4-41 Page 20 9 Nov 1987 No report. Nominations and Elections Dave Dodell informs me that primary activity centered on discussions on how to secure echomail voting by email. Legal rulings from IFNA Counsel indicate that voting by electronic means would not be invalid. Encoding of passwords in voting messages is being studied. Publications Although not officially received, Brian Hughes indicated he has resigned as Chairman. Ken Kaplan has named Tim Sullivan as the replacement. Technical Standards No report. PRESENT PROBLEMS General Getting such a large body to develop inertia in the right direction is proving very difficult considering the limited resources that can be brought to bear. My apologies to those who have suffered from our lack of expedient responses. Administration and Finance No significant problems reported at this time. Board of Directors We have still not learned how to actually conduct business in an EchoMail environment. Overcoming this will take considerable discipline. By-laws and Rules Specific direction has still not been received from either the BoD or Executive Committee. Executive Committee We have not yet resolved how we will meet our obligations to meet "at least quarterly" and handle all the concerns that are being placed before us. The problem with working in EchoMail has resulted in many delays which in turn are causing friction with those laying business before us. We are currently divided as to how best to proceed. International Affairs A very large storm seems to be brewing in Australia. Distance, of course, makes it difficult for us to effectively intervene and provide assistance. Membership Services None reported at this time. Nominations and Elections None reported at this time. FidoNews 4-41 Page 21 9 Nov 1987 Publications With no Chairman, this committee has not been in operation. Technical Standards No report. PROGNOSIS FOR THE COMING MONTH General It is hoped that we will solve some of organizational problems this month and get on to the backlog of business. Administration and Finance Leonard Mednick will continue to take over much of the administrative factors previously handled exclusively by Ken Kaplan. Board of Directors No Report. By-laws and Rules Activity in this committee will mostly still be tabled. Executive Committee As this Committee is required to meet quarterly it is expected that much of the orgainizational concerns and backlog of work will be addressed this month, providing some acceptable compromise can be met on how to meet. International Affairs This committee will begin to get underway this month. Membership Services No report. FidoCon proposals should be acted on, however. Nominations and Elections Furthur development of electronic voting with appropriate software development. Publications Installation of new Chairman should get this committee rolling. Technical Standards No report. ----------------------------------------------------------------- FidoNews 4-41 Page 22 9 Nov 1987 __ The World's First / \ BBS Network /|oo \ * FidoNet * (_| /_) _`@/_ \ _ | | \ \\ | (*) | \ )) ______ |__U__| / \// / Fido \ _//|| _\ / (________) (_/(_|(____/ (jm) Membership for the International FidoNet Association Membership in IFNA is open to any individual or organization that pays an annual specified membership fee. IFNA serves the international FidoNet-compatible electronic mail community to increase worldwide communications. ** Name _________________________________ Date ________ Address ______________________________ City & State _________________________ Country_______________________________ Phone (Voice) ________________________ Net/Node Number ______________________ Board Name____________________________ Phone (Data) _________________________ Baud Rate Supported___________________ Board Restrictions____________________ Special Interests_____________________ ______________________________________ ______________________________________ Is there some area where you would be willing to help out in FidoNet?_______ ______________________________________ ______________________________________ Send your membership form and a check or money order for $25 to: International FidoNet Association P. O. 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 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 on this Conference. ----------------------------------------------------------------- FidoNews 4-41 Page 23 9 Nov 1987 INTERNATIONAL FIDONET ASSOCIATION ORDER FORM Publications The IFNA publications can be obtained by downloading from Fido 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. IFNA Fido BBS listing $15.00 _____ IFNA Administrative Policy DOCs $10.00 _____ IFNA FidoNet Standards Committee DOCs $10.00 _____ Special offers for IFNA members ONLY: System Enhancement Associates SEAdog $60.00 _____ ONLY 1 copy SEAdog per IFNA Member. Fido Software's Fido/FidoNet $65.00 _____ ONLY 1 copy Fido/FidoNet per IFNA Member. As of November 1, 1987 price will increase to $100. Orders including checks for $65 will be returned after October 31, 1987. SUBTOTAL _____ Missouri Residents add 5.725 % Sales tax _____ International orders include $5.00 for surface shipping or $15.00 for air shipping _____ TOTAL _____ SEND CHECK OR MONEY ORDER TO: IFNA P.O. Box 41143 St. Louis, Missouri 63141 USA Name________________________________ Net/Node____/____ Company_____________________________ Address_____________________________ City____________________ State____________ Zip_____ Voice Phone_________________________ Signature___________________________ -----------------------------------------------------------------