F I D O N E W S -- Volume 14, Number 5 3 February 1997 +----------------------------+-----------------------------------------+ | The newsletter of the | ISSN 1198-4589 Published by: | | FidoNet community | "FidoNews" | | _ | 1-904-409-7040 [1:1/23] | | / \ | | | /|oo \ | | | (_| /_) | | | _`@/_ \ _ | | | | | \ \\ | Editor: | | | (*) | \ )) | Christopher Baker 1:18/14 | | |__U__| / \// | | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+-----------------------------------------+ | Submission address: FidoNews Editor 1:1/23 | +----------------------------------------------------------------------+ | MORE addresses: | | | | submissions=> cbaker84@digital.net | +----------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies of FidoNews or the internet gateway FAQ | | please refer to the end of this file. | +----------------------------------------------------------------------+ WHERE WAS THAT GROUNDHOG? Table of Contents 1. EDITORIAL ................................................ 1 Is it Phat or is it Jolly? ............................... 1 2. ARTICLES ................................................. 3 OpenDOS is Out! .......................................... 3 Fat-o-news? Call Jenny Craig! ............................ 6 3. GETTING TECHNICAL ........................................ 9 FSC-0028 - Note on Moving Files in FidoNet ............... 9 FSC-0030 - Message Identification & Reply ................ 21 FSC-0031 - Echomail dupe checking ........................ 25 FSC-0032 - Uniform Echomail Quoting ...................... 26 FSC-0033 - FidoNet Message ID Proposal ................... 27 4. COORDINATORS CORNER ...................................... 29 Nodelist-statistics as seen from Zone-2 for day 031 ...... 29 5. NET HUMOR ................................................ 30 An irreverent look at FidoLand hierarchy. :) ............ 30 What kind of Users do you have? .......................... 31 6. COMIX IN ASCII ........................................... 35 ASCII art goes hog wild? ................................. 35 7. NOTICES .................................................. 36 Future History ........................................... 36 8. FIDONET SOFTWARE LISTING ................................. 38 Latest Greatest Software Versions ........................ 38 9. FIDONEWS PUBLIC-KEY ...................................... 45 FidoNews PGP public-key listing .......................... 45 And more! FIDONEWS 14-05 Page 1 3 Feb 1997 ================================================================= EDITORIAL ================================================================= One of our readers takes the size of FidoNews to task in this Issue. He doesn't say how long he's been around but only refers to the output of Tees, the previous Editor as example of FidoNews size past. Since Tees didn't bother to actively edit FidoNews many times, it's hardly surprising many of his Issues were miniscule or Editorial only phosphor padding. FidoNews has been all sizes the past 13 years from 5K to 157K. Does it really matter how big an Issue is uncompressed? Nobody has to read it; part or all of it. Those who enjoy FidoNews for its potential [like myself] make contributions to it to make it fun or useful. The History and Standards series is part of what FidoNet is and many newbies and Echomail weenies [those who only joined FidoNet for Echomail and don't care or understand FidoNet's purpose] have never been exposed to this material. It's FidoEducational. That's why it's here and why it's going to keep going this way. There are FIVE FSCs in this Issue. There are only sixty or so more to go. [grin] The software list is also an important part of the FidoNews mission and we all are indebted to Peter Popovich for the Herculean labors he has made in organizing and maintaining that list. {Thanks, Peter!} In these days of uncertified mailers and tossers giving headaches to the entire Network from time to time, it's good to know what is available and what does work. Even as many of the Echomail weenies flee FidoNet for the apparently greener pastures of Internet mailing lists, there are still BBS Sysops who need to know what is available for them if they want to put up a system and become part of the World's First and Largest Amateur BBS Network [and no, Bob, you don't have to run a BBS to be a FidoNet Sysop]. It serves a purpose. It's in every Issue because any one Issue may be the only one somebody sees. There's an old saying that I don't agree with about doing and teaching. It sez that those who can, do, and those who can't, teach. That is incorrect. Those who can, do AND teach. Those who can't, get jobs as critics. I'm doing and teaching. The lessons may be taken or left at the reader's discretion. [grin] Speaking of 'otherNets'[tm], it appears that the first major splinter groups that broke from FidoNet to start true Utopian networks [cough] have died from lack of interest or commitment. The first to go off was AlterNet and it stopped publishing a nodelist as of Julian 010 this year. You had to pay a tithe to belong to that one. It was the first sourgrapesnet[r]. The second to splinter was EggNet. It didn't cost anything but it was going to provide all the democratic ideals FidoNet didn't. They even had a Supreme Court. It stopped publishing last year as of Julian 138. Ten years ago, I told you so. There never was any good reason for 'otherNets'[tm]. They were all ego-driven fantasies of 'the way a network should be operated' when FIDONEWS 14-05 Page 2 3 Feb 1997 FidoNet didn't move fast enough to suit them. Now, there are bunches of them. Most of those are Echomail driven which was also unnecessary. Several of those foolishly used Zone numbers under 10. That was very short-sighted. FidoNet is bound to expand into those Zone numbers and a lot of folks in 'otherNets'[tm] are going to start whining about overlap and 2D addressing that can't tell one Zone's Nodes from another. Boohoo. If they have any sense, they will shift up to Zone numbers unlikely to be overrun by FidoNet Zones when expansion takes place. With the demise of AlterNet's deliberate use of Zone 7, that will be one less group of whiners to hear from. [grin] Okay, that should generate some input. Those who complain about FidoNews content should remember that THEY are dictating the content with THEIR contributions. If they make none, their griping is hollow. Those who can, DO. [chuckle] C.B. ----------------------------------------------------------------- FIDONEWS 14-05 Page 3 3 Feb 1997 ================================================================= ARTICLES ================================================================= Cindy Ingersoll @ 1:107/71 http://www.caldera.com/dos/dos.htm The secret is out! I just happen to catch the above URL on the #linux channel of Undernet IRC, which points to OpenDOS! Let's let it speak for itself, here are some blurbs: Caldera OpenDOS Caldera OpenDOS 7.0 is based on the Novell DOS 7.0 DOS operating system, and expands on some of Novell's DOS' strengths. OpenDOS: * A genuine DOS (100% compatible) * A Rommable DOS - designed from the start to execute out of ROM * Fully featured - A comprehensive DOS utility set * Complete with extensions - including drivers for CD-ROMs etc. * Genuine multi-tasking, with API for developers * Includes 286 DPMS memory manager in addition to DPMI * Comprehensive Networking Client solution, NetWare 3.X, 4.X and Personal NetWare * Includes PC-based Personal NetWare Server * Includes defacto Disk compression - STAC * Includes new NetWars 2.0 network game Availability For private/evaluation and education use Caldera OpenDOS is available for download from Calderas Web site - to [1]Download Click Here BUT read our license agreement before downloading. Downloading constitutes acceptance of Calderas terms and conditions. For commercial and OEM usage of Caldera OpenDOS contact Caldera sales for more information. Return to [2]OpenDOS Main Menu References 1. http://www.caldera.com/dos/html/opendoslicense.htm 2. http://www.caldera.com/dos/index.html ..................................................................... Caldera OpenDOS Programming Documentation Caldera OpenDOS 7.0 is a complete DOS operating system. FIDONEWS 14-05 Page 4 3 Feb 1997 Consequently you can use all the available DOS development tools for the platform, allowing creation of software that will run on Caldera OpenDOS, MS-DOS, and DR DOS versions. In addition Caldera OpenDOS provides extensions that allow your application greater flexibility. Example additional features include: * Multi-tasking Caldera OpenDOS provides a full multi-tasking environment on Pentium, 486, or 386-based harware. This is built into the memory management extensions provided in the operating system, and is accessible for standard un-aware applications when using the Taskmanager (Taskmgr) utility. Programs however can have direct access to create separate threads etc, via the extended Application Programming Interface. * DPMS A memory manager that even works on 286-based Pcs, allowing device drivers to reside outside of the regular DOS application area. Drivers or Terminate and stay resident applications can thereby avoid using valuable application memory, * Romming tools Caldera OpenDOS is the ideal embedded DOS system, designed for straightforward out-of-the-box romming. Caldera will also be making these tools available for prototyping embedded systems. If you wish to use Caldera OpenDOS in your embedded application contact Caldera Sales for more information ..................................................................... Caldera Ships OpenDOS 7.01 for Free Internet Download New DOS Version Provided Free for Non-commercial use. Caldera OpenDOS makes a Solid, Low-Cost Solution for Running Windows 3.X Applications and DOS Applications on Intel and Compatible-based Workstations Andover, UK and Provo Utah, USA January 27, 1997 Caldera Inc. today shipped Caldera OpenDOS 7.01. OpenDOS is the first Caldera Release of DOS, based on the Novell DOS 7 technology acquired from Novell in 1996. The release is notable as it is the first commercial DOS Operating System to be downloadable from the Internet. OpenDOS is a true DOS operating system, supporting all DOS applications including Microsoft Windows applications, and networking systems including Novell NetWare, Windows for Workgroups, and LANtastic. FIDONEWS 14-05 Page 5 3 Feb 1997 Caldera OpenDOS comes complete with comprehensive networkability. The inclusion of Novell Personal NetWare means that OpenDOS fulfils all DOS workgroup requirements. End-users can easily network their PCs. It even includes a brand-new version of the NetWars Arcade game for single or multiuser use. "OpenDOS underlines Calderas commitment to making essential technology openly available as widely as possible" commented Jon Williams, Director of Marketing of Caldera UK Ltd. "Non-commercial users can download the latest DOS direct from our Web site. Commercial users and OEMs can download the system for evaluation and easily test-integrate into their solutions" "Caldera OpenDOS 7.01 represents the first 're-generation' of DOS Operating Systems, with its particular suitability to specialist OEM applications" he continued (The DRDOS product line that OpenDOS is derived from was the first purposely ROMmable DOS with industry leading features like power management) Brian Sparks, President and CEO Caldera Inc. said "Caldera is working with the Internet community to make productive commercial systems as open and available as possible. Dependable and reliable commercial systems software such as OpenLinux and OpenDOS are enabling users to make affordable and open choices on which to base their business solutions." Caldera uses its own technological and marketing resources to leverage technologies including the Linux operating system created by independent developers worldwide, and the OpenDOS product range. Visit the Caldera web site at [2]http://www.caldera.com/. For orders and information call (800) 850-7779 in the US or +1 801 269 7012 internationally. Caldera is a registered trademark; and Caldera OpenLinux, Caldera Network Desktop, Caldera Solutions CD and Caldera OpenDOS are trademarks of Caldera Inc. NetWare and Personal NetWare are registered trademarks of Novell Inc, Microsoft, Microsoft Windows, and Microsoft Windows for Workgroups are trademarks or registered trademarks of Microsoft Inc., UNIX is a registered trademark, in the United States and other countries, licensed exclusively through X/OPEN Company Limited. Netscape Communications, the Netscape Communications logo, Netscape and Netscape Navigator are trademarks of Netscape Communications Corporation. All other products, services, companies and publications are trademarks or registered trademarks of their respective owners. Press Contacts: Europe: Jon Williams - Director of Marketing Tel: +44 1488 71945 or +44 385 317 477 Email: jonw@caldera.com USA and Rest Of World: Lyle Ball - Marcoms Manager Tel +1 801 377 7687 FIDONEWS 14-05 Page 6 3 Feb 1997 Email: lyle@caldera.com Contact: [3]info@caldera.com References 1. http://www.caldera.com/dos/gifs/caldico.gif 2. http://www.caldera.com/ 3. mailto:info@caldera.com CiAo --- ----------------------------------------------------------------- Fidonews, The "lard ass" of newsletters by gary gilmore, 1:2410/400 First off, let me say, I take nothing away from Chris on running Fidonews. I know it's not easy to produce, and I know he's trying hard. I didn't see a mass rush of people volunteering to take it over when Sylvia/Don gave it up. OK, enough of the prefacing... time to get out the axe. A few of the locals here were talking about Fidonews, and mentioning how much larger it's gotten... unfortunately, that's mostly due to a bunch of bloated junk that I'm willing to bet a majority doesn't care about. Just for the hell of it, I took this week's news and did a little slash and burn to it. FIDO1404.NWS 123592 01-27-97 That's the whole enchilada, all the poop included. Hefty, eh? Wait.. there's more. Lets remove the huge "how to get Fidonews from every place in the world that we know of & Internet addresses of those that can spell 'Fidonews'" listing, the "Jurassic park" section (those FTSC documents that were originally written on stone tablets by guys with modems that had tubes in them), and the oh-so-popular "All the software in the world that has the word "mail" somewhere in it's source code" segment, oh, I left in some "humor" that probably managed to offend most everyone who might be a Fidonet sysop. (Not only was that emailed to almost the entire world, it wasn't funny the first time I saw it.) FIDO1404.NWS 27118 1-28-97 Whoops! What happened? Fidonews gets anorexic! Now again, I don't -really- want to bash the Snooze.. honest. I'm one of the few weirdos that actually bother reading it weekly. FIDONEWS 14-05 Page 7 3 Feb 1997 (Of course, I also like to read the nodelist now and then, so go figure...) Honestly though.. do we really need reprints of FTSC docs? If someone wants them, there's many, many places that offer them up for reading. Fer chrissakes, there's even a listing of the FTSC Internet site! (Though where's the FIDOnet listing for it?) About the only people that DO want to read them are programmers, or those preparing to "go after someone" over some arcane specification. Do we really need them in Fidonews? I don't think so. I'll betcha that most folks just PgDwn furiously past them. How about the giant PGP key? Have we -really- had a huge problem in the past with "bogus" copies of Fidonews? Oh please... I have to laugh just imagining some kiddies whipping out a Fidonews proclaiming himself the new International Coordinator or writing that Bruce Bodger and Bob Satti were seen on a plane with Bigfoot and Elvis, and that John Souvestre has moved in with Steve Winter. Bwaahahaha! :-) (Hmmm... come to think of it, I think I'd -rather- read an issue like that...) Uhhh, I don't think there's much doubt on the "authenticity" of the Fidonews I get, so I don't think we need to bloat with a huge key in every issue. Hell, just use AV mode when you Zip it up... that'll do nicely. (Oh, gahead... tell me how you can crack a zip password... yep, I'll bet there's LOTS of people dying to do that with Fidonews too! ) Today in history... umm, do I -really- need to know what's happening in 2000? Do I care? Should I jot it down in my Dayrunner? OK, ok... whatever, but how about limiting it to 6mo in advance? That's fair. Oh, and while we're at it, how about something like "Zone 1 Mail hour changes for areas observing Daylight Savings Time"... or something that REALLY would be helpful/matters to the Fidonet sysop. Ain't this "FIDOnews"? Peter E. Popovich.. bless him. Nice guy. But do we -really- need him to go to all the trouble of submitting this encyclopedia-sized listing each and every week? C'mon, some of this software hasn't been updated in four -years-, so why not just let Peter send in one listing every four -weeks-. I think that's fair, and gives Peter some rest. Jim Henry.. Hey! Here's a guy in FIDOnews talking about FIDOnet! Imagine! Hurrah for Jim! I don't own a palmtop, but I might just turn his echo for being one of the FEW things in this issue that is FIDOnet related, not INTERnet. Oh, Internet? Geez, hey, you forgot to list that our net's home page also has a link to Fidonews. Oh, and Infoseek? I'll also find the phrase "Fidonews" too, so let's not leave them out.. (Get the idea?) Auugh! Do I -have- to be told each and every place FIDONEWS 14-05 Page 8 3 Feb 1997 in the galaxy that I can find Fidonews, or each place that has another dreary all-black "Fidonet" web page? (Hmm, is that an oxymoron? "Fidonet web page"?) Doesn't POLICY4 (you know, it relates to FIDOnet) say that my NC has to give me Fidonews if I want it? (Well, I -am- the NC here, but you know what I'm saying..) I notice that of all the junk about where I can get Fidonews, I don't see one mention of the -main- way to get it... the FIDONEWS file echo. Hello? Anyone there? Sheesh, do we have an Internet boner or what? I think there's also something inherently wrong with FIDOnews in HTML format. I dunno, but all this Internet all over FIDOnet makes me itch. Umm, it happens to be that beloved Internet that's shrinking our ranks, for the most part. Is it too much to ask that FIDOnews do more coverage of FIDOnet, and -not- the Internet? If it doesn't, lets just change the name of it to INTERnews, and be done with it. After all, it -does- say "The newsletter of the FidoNet community", doesn't it? Sure, many want to put Internet features in their BBS systems. That's great. Keeping up on the bleeding edge of technology and all, but where's the "how to gate newsgroups into your Fidonet BBS" articles, or "How to gate email into your Fidonet BBS"... (note that I say "into your Fidonet BBS" a lot there... that's because it's what Fidonews should be concerned about. What's the point of this behemoth article? Simple. A little less INTERnet in my FIDOnews, please. A little less rehashing of old crap, and ancient postings. (I'll also kill you if you post more damned childlike ASCII "artwork"... Christ, that's so lame. My cat's litterbox has better artwork in it.) A little less bloat and needless information, and more FIDO-related meat in the S'nooze, please. If this means some issues will be slim, then so be it. No problem. Donald Tees had some issues that were nothing more than an editorial, but know what? They were -good- editorials, and worth reading. At least he didn't include reprints of "My favorite nodediffs from 1988-1990" just to keep the size up. Let it be what it will be, and let it be FIDOnet related first and foremost. Again, I like Fidonews, and I hope no one will be offended by all this rambling. If you are, well, go read "The history of nodelist flags in Guam and Easter Island" for a while until you get over it. (Or wait until it's reprinted in Fidonews. ) As they say, "Flames>nul". :-) ----------------------------------------------------------------- FIDONEWS 14-05 Page 9 3 Feb 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of a continuing series publishing FidoNet Standards and Proposals submitted to the FTSC. It is also part of the FidoNet History series. These have been reformatted to 70 columns as required.] Ed. FSC-0028 FwdSpec - A Collection of Notes on Moving Files in FidoNet Preamble Copyright 1988 Greylock Software, Inc. POBox 730 Gt Barrington MA 01230 FidoNet>1:321/202.0 Synopsis This started as a reverse-engineered technical description of the core operations of Ron Bemis' Flea program, and an attempt to formulate a new specification which is a more symmetric superset of that functionality. Specifications for Mr. Bemis software is available with that software, which is not freely distributed. This document ONLY addresses the format of files transferred between systems. It does not address configuration information, which is really an implementation specific issue. This is currently only a base for discussion, which should be carried on in the SOFTWARE (SDS) and FTSC conferences. Distribution This document may be freely distributed, so long as it is complete. Comments should be directed to: Barry Geller: 266/12 Tom Hendricks: 261/662 Harry Lee: 321/202 Rick Moore: 115/333 1 General 1.1 Existing Tools 1.1.1 FileFwd FIDONEWS 14-05 Page 10 3 Feb 1997 FileFwd is a program by Joe Keenan whose primary purpose is to move consistently named files on a routed, regular basis. It is extremely useful for routing echomail packets through intermediate nodes without unpacking and re-packing at each of the stations. 1.1.2 Flea Flea is a program created by Ron Bemis which is used to broadcast files in a manner similar to EchoMail. It is the primary tool used by the FidoNet Software Distribution System. Specifications for the Flea program are ostensibly available from the author. 1.1.3 GlueFwd GlueFwd is a distributed document control system from Greylock Software that was considered and rejected for use by the FidoNet Software Distribution System. Unlike Flea and Tick, GlueFwd uses messages to contain the associated routing information. 1.1.4 Tick Tick is a program by Barry Geller, which performs approximately the same functions as Flea, but uses a unique associated information file format. 1.2 Basics 1.2.1 Associated Routing Information There are a number of problems associated with file routing, either point to point, or broadcast. The basic problem is how to handle the associated routing information. The approaches involve a spectrum ranging from information contained ONLY on the systems handling the files to carrying the information WITH the files being handled. In addition, there is the choice of how this information is to be conveyed. The choices range from associated files, to messages. 1.2.2 Name Collisions 1.2.3 Larva - starting the process The "Larva" process is usually invoked by the user at the command line. This is how a file is put in motion. It creates the appropriate outbound .Fle files and the file attach information required by the given mailer environment. 1.2.4 Flea - moving stuff along The "Flea" process is the one that moves the files along. It does the following: FIDONEWS 14-05 Page 11 3 Feb 1997 Check the inbound for .Pre file, and process any that are releasable as you would a normal .Fle file Check the inbound for .Fle files, and process each as follows: Parse the .Fle file, making sure its associate file exists, it comes from a valid source, and that it is not a pre-release. If any of those conditions are violated, the file is renamed either to .Bad or .Pre. If all is well, move the file to the appropriate path associated with the area, and, if possible, update the FILES.BBS file. Using a Larva-like process, send the file along to any nodes in your echo list that have not seen the file. A Flea process is generally run whenever inbound mail is received. 1.3 Nomenclature 1.3.1 [Required] 1.3.2 {Optional} 1.3.3 Address: {Domain>}{Zone:}Net/Node{.Point} In the context of Flea 2.x, only Net/Node style addressing is supported. 1.3.4 Dates 2 New Forwarding Format (TICK) 2.1 General Goals 2.1.1 Removing order dependency The current structure of .Fle files is very order dependent. In some cases, .Fle file lines have verbs, in others, they do not. Presumably, Flea proper will have problems processing lines beyond the description that are not in the proper order. This weakness should be eliminated, essentially by insisting on a verb per line, which makes possible free-form parsing, eliminating order dependency. Within some groups of entries with the same verb, order dependency may be required. 2.1.2 Limiting the type of information contained in a given datum Flea 2.x very often carries different types of information on a given line. While on the surface, this seems like an economical way to do things, it can lead to complications later on. Therefore, it is a general design goal to keep the type and use of a given datum associated with a given verb very clean. FIDONEWS 14-05 Page 12 3 Feb 1997 2.1.3 Removing Case Sensitivity Flea is currently very case sensitive. Software should be soft. An argument has been made that case sensitivity is a protection against bad files being inserted into the system. If someone wants to generate a trojan horse, they will need passwords (the primary protection), and in all likelihood would use some sort of Larval tool to generate it anyway. Case sensitivity makes it slightly more difficult for a developer to "enter the fray". 2.1.4 Removing Inconsistent Colon Usage Flea currently is haphazard in its usage of colons after verbs. Colons should be made optional (or eliminated) on all verbs. 2.1.5 Optional Multiple DESC lines Flea currently supports a single description line, which is additionally position sensitive. By creating a DESC verb, the position sensitivity can be eliminated, and multiple DESC lines can optionally be supported. At the current time, .Tic files use the DESC verb, but multiple DESC lines are not permitted. Minimal compliance will be to handle one; multiple lines will be addressed later. 2.1.6 App (Application) line support In general, all mechanisms in FidoNet should allow for growth/variation by other developers in a non-harmful manner. In the case of Flea routing files, an APP verb with non-specific data should be provided for. For example, let's assume that UPCL supports some sort of a "return receipt" functionality - when a file hits you, so long as it's posted to your area, and with the sysop's consent (in the form of a configuration option), a message is sent to the Origin node. This might be done as follows: APP GREYLOCK Return-Receipt The "Greylock" sub-verb would keep APP conflicts from occurring. Processors other than UPCL would pass the line through to any rebroadcast .Tic files intact. (In fact, so would UPCL.) App lines, taken as a group, are order dependent. A Tick processor should output App lines created during forwarding in the same order they read them, and if a Tick processor creates new App lines, they should be added to the end of the existing App line list. Once the majority of processors support a given APP functionality, it might be moved to the spec proper. FIDONEWS 14-05 Page 13 3 Feb 1997 Indeed, any lines with "unrecognized verbs" should be passed through intact, and in the order encountered. 2.1.7 Use of PATH construct rather than sby kludge Seenby information is more easily digested by humans (and programs) if it is sorted. Unfortunately, such sorting removes the ability to use it for both seenby, and path information as it is in Flea 2.2. In addition, the mechanism used by Flea 2.2 precludes tiny seenby's, or Zone gating. Therefore, a PATH construct, much like an EchoMail PATH line should be used, instead of the current mechanism. Once again, order dependency should be discouraged. Within a group of path lines, obviously, order is important. 2.1.8 Multiple Sby's per Sby line The current seen-by construct, with one seenby per line, with the word seen-by required on each line is hideously inefficient. This should be changed to mimic echomail's seen-by handling, where multiple seenby's are contained on each line, up to 78 or so characters worth. A possible reason to keep the seenby down to a single entry per line is if information on how and when that node got the file is to be included. While this might be worth considering, it will add considerable weight to the .Fle file. At the current time, Tick files are assumed to have one seen-by per line. 2.1.9 Full (Optional) Domain, Zone, and Point support In order to allow for the future growth of the network, and interactions with other networks, addresses should be able to contain a fully qualified FidoNet address: Domain>Zone:Net/Node.Point. Further, given that many authors' primary machines are points, the result is as shown in the sample above: completely unknown addresses appearing in the .Fle files. Of course, these should not be required, but used as necessary. At the current time, Domains are completely unsupported, and should not be used. 2.1.10 Different extensions to avoid problems with Opus Style Outbound The extension .Fle was chosen because it leads to some expedient side effects in the form of file truncation/elimination by Opus or Binkley when the files reside in the outbound directory. FIDONEWS 14-05 Page 14 3 Feb 1997 On the other hand, both Opus and Binkley explicitly specify their outbound areas should be used ONLY for that. A number of Binkley/Opus developers have expressed concern with this problem. For this, and other reasons, .Fle files should be given a new extension of some sort, one that is not closely related to the commonly used routing/message file extensions. In addition, rather than the three divergent extensions now used by Flea (.Fle, .Bad, and .Pre), any and all extensions used by file routers based on this technology should use extensions that are more closely grouped. As an ancillary note, the FTSC should consider a "File Specification Pattern Registry". This would not be limited to network tools, and it would not be an indication of ownership, it would simply be a reference. 2.1.11 RFC-822 Format It might make some sense to consider using an RFC-822 compatible format for these files. In a future version of this document, I'll detail this possibility. It would also be nice from the point of view of implementing a similar system on UseNet/Internet flavored systems. 2.1.12 Valid pairing of associated info file and file proper We need a mechanism to insure that the primary file and the associated information file are a valid pairing. Consider the following scenario ... System allows overwrites. A file and associated .Tic arrive. They are, for whatever reason, not processed. A file by the same name comes in. The pair is no longer valid, but given current technology, it would be passed along. 2.2 Considerations 2.2.1 Up and downness 2.2.1.1 Single Uplink 2.2.2 Table driven duplicate elimination 2.2.3 Mapping between distribution and on-line organization There is a problem in the current implementation in that the local organization of a system tends to defeat the duplicate catching aspects of the system. I.E., the SDS currently sends out ALL FidoNet files in one "channel". Many systems move files of this category or that to unique directories. FIDONEWS 14-05 Page 15 3 Feb 1997 2.2.4 Many features are intended for local optional implementation Many of the features in this specification obviously affect how individual sysops run their systems. As such, these features should be optionally supported by each sysop, although the information should be passed through the associated information file regardless of whether or not they support the feature. 2.3 Schematic of .Tic file Area{:} [AreaName] {Release{:} [Time]} {Replaces{:} [FileName]} File{:} [FileName] DESC{:} [Description] {DESC{:} [Description]} {Size{:} [Bytes]} {Date{:} [FileDate]} {CRC{:} [Calculated CRC-32 (in hex?)]} Origin{:} [Address] From{:} [Address] [Pwd] {Created{:} [Program Banner]} Seenby{:} [Address] {Address} ... {Seenby{:} [Address] {Address} ...} {APP{:} [Application Specific Information]} Path{:} [Address] {Address} ... {Path{:} [Address] {Address} ...} Note this file is NOT order dependent. Some of the newer features are more for discussion than anything else. 2.4 Nomenclature and Rules 2.4.1 Address Format: Zone:Net/Node{.Point} 2.4.2 Don't Barf on appended or unknown stuff Lines that are unrecognizable (i.e., non-existent or non-supported verbs) should be passed through untouched. Lines that have additional data beyond the required data (separated by whitespace) should not cause the system to fail, although it is obviously difficult to pass this information through. 2.4.3 One or zero items of a given type unless otherwise specified 2.4.4 Simple ASCII Alphabet 2.4.5 Unix Date Time Formats All times are expressed as a long decimal in Unix format - the number of seconds since 1970. 2.4.6 [Required Data] FIDONEWS 14-05 Page 16 3 Feb 1997 2.4.7 {Optional Data} 2.5 Detail 2.5.1 App [Ref] {Info} This is a "pass through" line to allow developers some room for development without breaking other developer's work. An APP line should have the following form: APP [AppRef] {App Information} or APPLICATION [AppRef] {App Information} Application lines should have their order preserved, and applications adding lines should do so at the end of the existing application list. 2.5.2 Area [Name] Area names should probably be limited to 8 characters, with alphabet restrictions, to simplify their implementation. This is a mandatory line, and only one should exist in the file. 2.5.3 Author [Name] This is an item for discussion. 2.5.4 CRC [Decimal CRC Value] As .Fle files stand, it is possible to "slip something in" to the pipe, particularly if .Fle files are processed only once in a while as opposed to after each inbound call. A number of the proposed (and optional) features here provide safeguards against this. Specifically, computing the file CRC, and preserving the original file date and size in the .Tic file. This has some value as a verification tool, without the legal encumbrances of PKSCrypt, etc. This probably should be a CRC-32 value. This would also closely follow some of the ideas that are being considered for echomail processing. This is currently a point for discussion. It probably should be a mandatory field. 2.5.5 Created [Program Banner] This should contain some program identification information of the program that generated the attach information. FIDONEWS 14-05 Page 17 3 Feb 1997 There might be some standard format for the first part of this line, allowing for variant information after this. This is an optional line. 2.5.6 Date [Date/Time of creation] This is a check for valid file pairing between the associated information file and the primary file. It is the file date stamp of the primary file in Unix format. 2.5.7 Desc [File Description] This is a description of the file. There is as yet unspecified length restriction on this line. At the current time, exactly one of these lines should appear in the Tick file. In the future, more than one line may be supported. 2.5.8 Dest [Address] This is related to Route (qv) 2.5.9 Encrypted [PKS Key] Read the section on "GARBLE", and change it as follows: The file is initially encrypted using a PKS style encryption. This would be the ONLY time the file is encrypted. The FTSC or someone would have to collect a list of valid public keys of authors (and probably eventually everyone). The file would then be of "known-quality", or at least from a known source. The key would be included in the .Tic file for ease of operation. The ramifications of this are considerable. First off, PKSCrypt is something the spook types in the world are bothered by. Secondly, the source is not available, and the program does not work on some machines (i.e., my 386.) Large keys would probably have to be used so a large number of possible keys will exist, which means considerable encryption and decryption processing time. Finally, there is the question of a "Key registry", and how you verify them. I am not sure if this and Garbled are and/or or either/or. 2.5.10 File [FileName] ONLY a filename (no path information) is contained on the FILE line. No wildcards. Exactly one of these lines must exist in a Tick file. 2.5.11 From [Address] FIDONEWS 14-05 Page 18 3 Feb 1997 This is the address of the system sending the file on the current leg. 2.5.12 Garbled This is really just a thought for consideration than anything else. If this is present, the file referenced by the .Tic file is assumed to be archived (we'd have to address the issue of "deviant" archivers") by an agreed upon password between the sender and the sendee. The ramifications of this are considerable. It would mean that individual archives would need to be created for any node so protected, which would need to be deleted after sending. This implies a considerable expenditure of time and resources to create and store these archives. 2.5.13 Log [Comment] This is another one for consideration. Any such lines would be displayed on the console and/or the system log. 2.5.14 Magic [FileName] This is food for thought. In order to resolve and standardize version numbering in file names, and magic file names, this might be used to distribute a "magic file name" with a given file. More than one of these lines might exist. 2.5.15 Origin [Address] Where the file originally entered the system. 2.5.16 Path [Address] {Arrival} Path lines are, among themselves, order dependent. However, they need not be contiguous. The current path specification allows for only one address per path statement. It might make sense to leave it this way, and add an "Arrival time", which would be the time the file was processed. I.E., the file would start out with the path for this node and the next node with the time of creation. When it gets to the next node, he changes his time to the time of processing, and puts out a similar line for the node(s) he sends to. 2.5.17 Pw [Password] FIDONEWS 14-05 Page 19 3 Feb 1997 This is the password between the sender and the sendee. This password is not case sensitive. Exactly one of these lines must exist in a Tick file. It would be nice to have some method of password securing that did not require the password to be exchanged in clear text. 2.5.18 Release [DateTime] This is an optional line used to contain a Unix Date Time (seconds since 1970) of the release of the file. The handling of this is really murky as far as I can tell. A brief digression into "political structures." Let's consider the case of the SDS. In SDS, it has generally been assumed that ONLY nodes that are a part of the SDS get their files using Flea/Tick technology. However, whether it is aware of it or not, this is not the case. Here's what I think was intended: a file comes in with a Pre-release time set. That is the time at which the file is moved to the publicly available area. I am not sure whether it is passed along the chain until that date, or if it is simply not to be made "publicly available" until that date. 2.5.19 Replaces [FileName] Only a filespec, no path information, is contained on this flavor line. A REPLACES line is used to optionally (at each given node) dispose of older versions of the file being sent out. For instance, Binkley releases are named: BEXE_XXX.Arc Assuming the next version of Binkley was 2.10, and assuming REPLACES was enabled for the given area, the file named on the REPLACES line would either be erased or moved if found. I.E.: FILE BEXE_210.Zoo REPLACES BEXE_*.Arc If these lines are encountered, and replacement is allowed, and BEXE_200.Arc was found, it would, in some way, be removed from the access directory. Wildcards should be allowed, but should also be used with care. Multiple REPLACES lines should be allowed. 2.5.20 Route [Address] FIDONEWS 14-05 Page 20 3 Feb 1997 This is just thinking out loud. These would have to be order dependent. They would be set up at the point of creation, and there would have to be agreements all along the way. A political nightmare, but very useful in a corporate environment. Collisions are a very real problem here. 2.5.21 RtRcpt {Address} This is an item for discussion more than anything else. It would be nice to have a means to find out how far your files have moved. On the other hand, there are significant Policy type considerations for such a functionality. If the optional address is omitted, the ORIGIN is used. 2.5.22 Seenby [Address] {Arrival} The current seenby specification allows for only one seenby per line. Seenby's are NOT order dependent. Seenby information is more useful in "alphabetical" than encountered order, although it is not a requirement. 2.5.23 Size [File Size in Bytes] 2.5.24 Source [Address] Where the file actually came from. This is a point for discussion. Let's consider the SDS again. In theory, SDS is a controlled system. Files are only supposed to enter it from a very limited subset of FidoNet. Currently, the Origin is the location the file was "launched" from, a very different thing than the author's address. The Source address, if present, is the address of a primary system used by the actual author. For instance, consider Binkley. Binkley is supposed to enter the system at the region 16 SDS node, although it is written by nodes that do not participate in SDS. 2.5.25 Topo {Address} This feature, if enabled, can be used to generate a topology report for the area specified to the given node. If no node is specified, the report should be sent to the Origin node. 2.5.26 Unidentified Verb Handling FIDONEWS 14-05 Page 21 3 Feb 1997 Lines with unrecognized verbs should be passed through. Order is a critical issue here. Unknown lines should be output in the same order they were input. 2.6 Feature Table Feature Status Count Area [Name] 1 File [FileName] 1 Path [Address] >=1 Created [Text] 0-1 From [Address] Origin [Address] SeenBy [Address] Path [Address] Unidentified Verbs 2.7 TK123456.Tic (Updated and amended slightly from Barry's Orig) Area TICKTEST File TEST.TXT Desc This is the file description Line! Origin 1:266/1 From 1:266/13 Created by TICK v1.00 - Copyright (C) 1988 by I. Barry Geller Release 59000000 Path 1:266/21 Path 1:266/13 Path 1:150/1 Seenby 1:266/21 Seenby 1:266/13 Seenby 1:150/1 Pw TESTPW 2.8 Notes 2.8.1 The primary file should be sent before the associated file The actual file should be sent before the associated information file. Consider this was not done in the following scenario: Associated file sent Primary file partially sent - session fails System processes associated files, and fails to find last primary During next session, primary is sent, with no associated -30- ----------------------------------------------------------------- FSC-0030 FIDONEWS 14-05 Page 22 3 Feb 1997 MESSAGE IDENTIFICATION AND REPLY FOR FIDONET *DRAFT* FIDONET TECHNICAL COMMENT Author: John Cowan Fido: 1:107/711 (formerly 1:107/111) Arpa: cowan@magpie.masa.com Uucp: {backbones}!rutgers!hombre!magpie!cowan Vox: +1-212-236-9153 ABSTRACT The following document proposes a standard for message identification and message reply identification for Fidonet and Fidonet-based electronic mail system. It is based on the Usenet standard, RFC 850 and successors. The proposed standard will assist in duplicate- message detection and will permit the support of true reply threading across the network. The standard consists of mandatory and suggested portions; however the term "mandatory" does not mean that any Fidonet product must implement this standard --it simply means that those that do claim to implement this standard must do so in the way described. BACKGROUND Currently, Fidonet messages are not uniquely identified. A variety of schemes are in place to determine whether a message received by a Fidonet node has been previously processed by the node, but all of them involve a probabilistic component which may allow duplicates to slip through. This can happen with particular ease where non-Fidonet gateways are involved which may reformat a message. In addition, Fidonet provides no clear and definite indication of whether a message is a reply to some other message, and if so, which message. This is a consequence of the previous problem -- there is no way to refer to a message that is valid across all nodes. Programs like TBBS, therefore, which do support the notion of detailed reply threading (each reply refers to some definite "parent" message) have to use a semi-guesswork algorithm which frequently leads to the wrong answer -- the latest message with a common Subject header is taken to be the parent, even when examination of the context by a human being indicates that the message is in reply to some earlier message. The Usenet network, which shares much of its problem domain with Fidonet, solves these problems by tagging every outgoing message with a unique Message ID string. Other messages can then refer to this Message ID and provide an unambiguous indication of which message, or messages, they are in reply to. IFNA KLUDGE LINES "MESSAGE-ID" AND "IN-REPLY-TO" Fidonet supports a general method for sending additional information embedded in a message known as the "IFNA kludge line". This is a line of text beginning with the ASCII SOH character. The characters following SOH are a word indicating the type of kludge line, and the remainder of the line contains information specific to that type. This standard introduces two new types of kludge lines, the MESSAGE-ID FIDONEWS 14-05 Page 23 3 Feb 1997 line and the IN-REPLY-TO line. These names, and the kludge line formats, are taken directly from Usenet. MESSAGE-ID is used to tag an outgoing message with a unique string, different from any other message on the network. IN-REPLY-TO is used by threading message processors to specify the Message ID of the "parent" of a reply message. These kludge lines are generated and interpreted by message editors; tosser/scanner and mailer products need only leave them undisturbed. They are applicable to both regular network mail and Echomail. FORMAT OF A MESSAGE ID -- MANDATORY This format is drawn directly from Usenet; it may seem a little arcane, but is flexible enough to handle a large variety of needs. Generally, a Message ID looks like this: The <, @, and > characters are fixed, and are used to help in parsing the Message ID. The "unique-part" may consist of any characters -- the only requirement is that it be different for every message generated on a given node or point. Possible implementations of "unique-part"s include a simple serial number, a date+time, or something completely different. The "domain-name" must be a valid Internet domain name. Luckily, every Fidonet system has a valid domain name now! The format here is as follows: The domain name of the node a:bbb/ccc is Fccc.Nbbb.Za.FIDONET.ORG and the domain name of the point a:bbb/ccc.ddd is Pddd.Fccc.Nbbb.Za.FIDONET.ORG The periods, magic letters, and the magic name "FIDONET.ORG" make the domain name unique in the world. Of course, Fidonet systems that already have a different domain name (e.g. circle.UUCP) are free to use that name instead. A system which generates Message IDs must guarantee that no Message ID will be reused for at least two years. This implies that if multiple message editors exist on a system they must cooperate at least to the extent of not using the same Message IDs for different messages. In particular, a message editor that uses a simple serial number should make provision for the user to set the starting serial number to a value other than zero, so that different starting values can be used by different products. Note that the numeric name of a .MSG file is >not< suitable as a unique-part, because it is neither unique nor permanent. FORMAT OF A MESSAGE ID -- SUGGESTED It is suggested, though not required, that the unique-part of all Message IDs consist only of decimal digits, and not more than 9 of these, so that the unique-part can be stored as a 32-bit signed integer. A serial number scheme meets this standard, as does a Unix- style timestamp (seconds since midnight Jan 1 1970, Universal Time). There many other possible schemes. CREATION OF THE IN-REPLY-TO LINE -- MANDATORY FIDONEWS 14-05 Page 24 3 Feb 1997 The most important thing about the IN-REPLY-TO line is that the Message ID specified by it should be the actual Message ID of the message being replied to, and not a Message ID invented by the sender of the reply. This implies that message editors which generate IN- REPLY-TO lines should be able to store the Message IDs of all incoming and locally generated messages for as long as the messages themselves remain on-line. It is worth repeating, however, that there is nothing mandatory about generating the IN-REPLY-TO line at all. A message editor may generate both MESSAGE-ID and IN-REPLY-TO lines, only MESSAGE-ID lines, or neither. Due to problems with existing software, message editors should be prepared to receive (and either discard or display uninterpreted) IN- REPLY-TO lines which are >not< in standard format. Standard format lines will have a < character just after the keyword and a > character at the end of the line. DUPLICATE MESSAGE ELIMINATION Usenet makes use of a "history file" which maintains the Message IDs of messages received in the last 15 days (this number is configurable by the sysop). Fidonet has a similar scheme, but this is inherently less reliable, depending as it does on the exact layout of each message. With MESSAGE-ID kludge lines, dupe eliminators can take advantage of them to help kill dupes once and for all, using existing mechanisms as a backup when needed. IMPLICATIONS FOR USENET GATEWAYS Currently, Fidonet<->Usenet gateways generate Message IDs for messages passing from Fidonet to Usenet, and discard them for messages passing the other way. With this standard in place, such gateways should be modified to watch for MESSAGE-ID and IN-REPLY-TO kludge lines and translate them to Usenet "Message-ID:" and "In-Reply-To:" header lines, and vice versa. This will improve the behavior of threading systems like TBBS on the Fidonet side and 'notes' on the Usenet side. Fidonet messages which don't have a MESSAGE-ID line will, of course, need to have one generated when passing over to Usenet, as is now the case. IMPLEMENTATIONS The Magpie tree-structured BBS is now being enhanced to provide Fidonet access to its users. Magpie depends heavily on the notion of parent messages; every message on a Magpie system (except one) has a parent. Magpie/Fidonet systems will use the above technique to pass the parent information they need transparently through the Fidonet, so that incoming Fidonet messages can be connected at the correct place in the Magpie tree. (A backup algorithm similar to TBBS's will be used for Fidonet messages without parent information.) We are publishing this information as a Fidonet technical comment in hopes that other Fidonet products will eventually incorporate all or part of this standard as well, and that it will eventually form part of a Fidonet Technical Standard. FIDONEWS 14-05 Page 25 3 Feb 1997 -30- ----------------------------------------------------------------- FSC-0031 May 1, 1989 EchoMail ^aEID: Dup-Checking with Linked Replies A Proposal To The FidoNet Technical Standards Committee Currently, no universal methodology for implementing echomail duplicate message checking exists. One thing is certain - they will only increase in number as the shear volume of echomail is increasing every day! In order to catch the highest percentage of duplicates possible it is desirable to utilize a system which actually tags each of the messages themselves with a distinct messages identifier to be used to check against an existing database of all previous messages' identifiers. In practice, this is not possible, but we can limit the number of previous identifiers kept so that processing is quick but still almost certain to eliminate any duplicate messages. This also provides an easy method of linking replies to their original message by appending the previous identifier. Using a linked reply technique allows easy relinking of the messages to the original message, assuming it still exists. This proposed ^aEID: kludge line specifications are as follows: 1) A 16-bit CRC followed by a 32-bit DOS file date/time stamp. 2) The 16-bit CRC is calculated by first CRC'ing all but the first 11 (static) characters of the origin line, followed by the first two "words" of the from name, the first two words of the to name, and the first 25 characters of the subject line after stripping leading occurances of "Re: " sequences. Notes: You must always upper-case the to/from/subject fields, as some current processors will change the case of that text. Using only the first two words of the from and to names will eliminate the potential problem when some processors add the " of xxx/yyy" to the end. Stripping all leading occurances of the "Re: " in the subject field is also done to eliminate the possibility of changed subject lines not matching with the original message, which is also the reason for limiting the length of that field to the first 25 bytes (after taking off all the "Re: " sequences), because adding the leading "Re: " may force characters out (because they are beyond the 72-character field limit). When you must add an EID line for a message which is not local, you have to zero the seconds field before creating the 32-bit FIDONEWS 14-05 Page 26 3 Feb 1997 time stamp - some processors eliminate this information! This limitation can be overcome if most editors insert them at the time they are written. Automatic reply linking ========= ===== ======= When replying to a message with an ^aEID: line, extend the new ^aEID: with the ^aEID: fields of the original message. The new line would look like this: ^aEID: xxxx yyyyzzzz uuuu vvvvwwww Where 'uuuu vvvvwwww' is the Eid information of the original message. Only one previous message's information is retained. -30- ----------------------------------------------------------------- FSC-0032 May 1, 1989 Uniform EchoMail Quoting Style A Proposal To The FidoNet Technical Standards Committee As more and more new software appears on the network, it has become evident that we need a universal method for quoting text of previous messages in replies. Because of the way quoted text must appear, it is necessary to format said text with "Hard" characters, in order to keep the block from drifting should the new text itself be quoted. The following method should allow current and future programs to properly identify and handle previously quoted material. Newly quoted text should be preceeded by the a single space, a greater than symbol ('>') and another space. Optionally a field of initials may appear in front of the greater than symbol, like this: " MR> ". If you allow the initials to be inserted, they should only be inserted into lines which have not been previously quoted. (in other words, don't add initials to anything already quoted) Successive quotes of previously quoted material should only add a single ">" in front of the existing text, which may eliminate the leading blank space. Blank lines in quotes should remain blank (no '>' or initials). Kludge lines, including tear lines and origins lines are not normally quoted, but when they are - they must never be quoted exactly - this definitely causes problems with other software! FIDONEWS 14-05 Page 27 3 Feb 1997 -30- ----------------------------------------------------------------- FSC-0033 June 11, 1989 FidoNet Message ID Proposal By Todd Kover 1:261/5016;1:261/1028 Since there are many proposals for Message-IDs, for dupe-checking, and reply-linking, I figured, I may as well do my best to add confusion to things, and come up with another one. :-) In my playing around with different ideas, and such, I came out with the following format: ^AFMSGID:DDDYYHHMMSSLLNNNNOOOOPPPP[ZZZZ][Domain] ^AFREPLY: < Repeat of what is above > Here's a brief explanation of what each area is... DDD: (01-366) The day of the year. (Julian calendar method). YY: (0x00-0xFF) The year. Now, this only gives 255 year accuracy, but, if the message has been in circulation that long, then it deserves to be read again. :-) HH: (00-23) Hour which the message was written MM: (00-59) Minute which the message was written SS: (00-59) Seconds which the message was written LL: (0x01-0xFF) In reading NET_DEV, and FTSC, and all of the debating over "What happens when someone enters a message at the EXACT same time, on my multiline system?) Well, the best way to avoid that, is to either A) Set the ID while packing the message up, and only pack all the lines messages in, at once, or, use this option, that sets the line number, of the caller (0-0xFF).. I figure that there won't be more than 255 lines to a single node... I would opt for the former, but, I put this in here, to shut everyone up. :-) NNNN: (0x00-0xFFFF) The Net Number of the node, that this message originates from. OOOO: (0x00-0xFFFF) The Node Number of the node, that this message originates from. PPPP: (0x00-0xFFFF) The Point Number of the node, that this message originates from. FIDONEWS 14-05 Page 28 3 Feb 1997 ------ Now for the Optional ones: ZZZZ: Since there is a question as to weather or not Zones should be implemented, and, some packages do not implement them, I figured that this should be optional. If it is not there, then a Domain address would be there, or, nothing at all. Domain: This is for the people that use these (SEADogians, for one). I am assuming that Domains are alphabetic characters, and no numbers are there (Which is probobly stupid on my part), so that software can distingish between Domains, and Zones. ------ The FREPLY: is just teh FMSGID of the message that the message is replying too. That way, you can just compare. In order to allow dupe checking, a system has to keep a backlog of all of the message IDs for some period of time (say 2 weeks?) that pass through the system, and has to compare a new one to the old ones. If it matches, then the message is a dupe. This doesn't seem too efficient, since there are alot of messages that pass through something such as a backbone, but, I am sure there is some way to make it fast, I just haven't put enough thought into it, yet). ------ One of the more nicer features about this, is that if the ID is not there, then it can be calculated by examinining parts of the message, and the header to get all of the information, and, it can be put in there. Pretty simple, eh? ------ If you want to get in contact with me, to make contacts on this, you can reach me at my private node, 1:261/5016, but, since I only poll the Net-Coordinator once a week, or so, to pick up my NodeDiff, and FidoNews, I will be a little slow in responding to it. You can reach me pretty quickly on 1:261/1028, which is the only BBS that I frequent, just about daily, and, if I don't, the sysop there will tell me if there is anything waiting for me... Direct flames, and such things to NIL:, thank you.. -30- ----------------------------------------------------------------- FIDONEWS 14-05 Page 29 3 Feb 1997 ================================================================= COORDINATORS CORNER ================================================================= Nodelist-statistics as seen from Zone-2 for day 031 By Ward Dossche, 2:292/854 ZC/2 +----+------+------------+------------+------------+------------+--+ |Zone|Nl-003|Nodelist-010|Nodelist-017|Nodelist-024|Nodelist-031|%%| +----+------+------------+------------+------------+------------+--+ | 1 | 10370|10370 0 |10177 -193 |10063 -114 | 9877 -186 |35| | 2 | 16056|15979 -77 |15936 -43 |15938 2 |16078 140 |56| | 3 | 869| 868 -1 | 865 -3 | 863 -2 | 863 0 | 3| | 4 | 552| 554 2 | 553 -1 | 558 5 | 550 -8 | 2| | 5 | 93| 93 0 | 93 0 | 93 0 | 87 -6 | 0| | 6 | 1073| 1073 0 | 1073 0 | 1072 -1 | 1072 0 | 4| +----+------+------------+------------+------------+------------+--+ | 29013|28937 -76 |28697 -240 |28587 -110 |28527 -60 | +------+------------+------------+------------+------------+ ----------------------------------------------------------------- FIDONEWS 14-05 Page 30 3 Feb 1997 ================================================================= NET HUMOR ================================================================= An irreverent look at FidoLand hierarchy. :) Paul Quinn at 3:640/384 Aha! Here it is... knew I had it somewhere. I found this description of the network lying around and, as I'd had such a good belly-laugh, thought that I ought to really pass it around. FidoNet Co-ordinators ~~~~~~~~~~~~~~~~~~~~~ *IC leaps tall buildings in a single bound is more powerful than a locomotive is faster than a speeding bullet walks on water is GOD *ZC leaps short buildings in a single bound is more powerful than a shunting engine is faster than a speeding bullet walks on water if the sea is calm gives policy to God *RC leaps short buildings with a running start and favourable winds is almost as powerful as a shunting engine is just as fast as a speeding bullet walks on water in an indoor swimming pool talks with God *NC barely clears a fabricated hut loses a tug of war with locomotive can fire a speeding bullet swims well talks with God if special request is approved *HUB makes high marks on the wall when trying to clear tall buildings is run over by locomotives can sometimes handle a gun without hurting themselves dog paddles talks to animals *NODE FIDONEWS 14-05 Page 31 3 Feb 1997 runs into buildings recognises locomotives 2 times out of 3 is not issued with ammunition can stay afloat with a lifejacket talks to walls *POINT falls over doorstep when trying to enter buildings says look at the choo choo wets themselves with water pistol plays in mudpuddles mumbles to themselves *USER lifts buildings and walks under them kicks locomotives off the tracks catches speeding bullets in teeth and ears walks on water if it is frozen who the hell is GOD? Many thanks to Stuart Fox (3:635/727.21) for the original. Cheers, Paul. ----------------------------------------------------------------- From: "Mike Riddle" To: "Baker, Christopher" , Date: Tue, 28 Jan 97 14:22:29 -0600 Reply-To: "Mike Riddle" Subject: Fwd: PC Users ==================BEGIN FORWARDED MESSAGE================== >Date: Tue, 28 Jan 1997 14:11:26 -0600 >To: Mike Riddle >From: "Demitri Baroutsos" (by way of jennifer rose ) >Subject: PC Users >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" 9 Different types of users El Explicito: "I tried the thing, ya know, and it worked, ya know, but now it doesn't, ya know?" Advantages : Provides interesting communication challenges. Disadvantages: So do chimps. Symptoms : Complete inability to use proper nouns FIDONEWS 14-05 Page 32 3 Feb 1997 Real Case : One user walked up to a certain Armenian pod manager and said, "I can't get what I want!" The pod manager leaned back, put his hands on his belt-buckle, and said, "Well, ma'am, you've come to the right place." Mad Bomber: "Well, I hit Alt-f6, shift-f8, Cntrl-f10, f4, and f9, and now it looks all weird." Advantages : Will try to find own solution to problems. Disadvantages: User might have translated document to Navajo without meaning to. Symptoms : More than six stopped jobs in UNIX, a 2:1 code-to- letter ratio in WordPerfect Real Case : One user came in complaining that his WordPerfect document was underlined. When I used reveal codes on it, I found that he'd set and unset underline more than fifty times in his document. Frying Pan/Fire Tactician: "It didn't work with the data set we had, so I fed in my aunt's Recipe for key lime pie." Advantages : Will usually fix error. Disadvantages: 'Fix' is defined VERY loosely here. Symptoms : A tendency to delete lines that get errors instead of fixing them. Real Case : One user complained that their program executed, but didn't do anything. The scon looked at it for twenty minutes before realizing that they'd commented out EVERY LINE. The user said, "Well, that was the only way I could get it to compile." Shaman: "Last week, when the moon was full, the clouds were thick, and formahaut was above the horizon, I typed f77, and lo, it did compile." Advantages : Gives insight into primitive mythology. Disadvantages: Few scons are anthropology majors. Symptoms : Frequent questions about irrelevant objects. Real Case : One user complained that all information on one of their disks got erased (as Norton Utilities showed nothing but empty sectors, I suspect nothing had ever been on it). Reasoning that the deleted information went *somewhere*, they wouldn't shut up until the scon checked four different disks for the missing information. X-user: "Will you look at those...um, that resolution, quite impressive, really." FIDONEWS 14-05 Page 33 3 Feb 1997 Advantages : Using the cutting-edge in graphics technology. Disadvantages: Has little or no idea how to use the cutting-edge in graphics technology. Symptoms : Fuzzy hands, blindness Real Case : When I was off duty, two users sat down in front of me at DEC station 5000/200s that systems was reconfiguring. I suppressed my laughter while, for twenty minutes, they sat down and did their best to act like they were doing exactly what they wanted to do, even though they couldn't log in. Miracle Worker: "But it read a file from it yesterday!" 'Sir, at a guess, this disk has been swallowed and regurgitated.' "But I did that a month ago, and it read a file from it yesterday!" Advantages : Apparently has remarkable luck when you aren't around. Disadvantages: People complain when scons actually use the word "horse-puckey". Symptoms : Loses all ability to do impossible when you're around. Must be the kryptonite in your pocket. Real Case : At least three users have claimed that they've loaded IBM WordPerfect from Macintosh disks. Taskmaster: "Well, this is a file in MacWrite. Do you know how I can upload it to MUSIC, transfer it over to UNIX from there, download it onto an IBM, convert it to WordPerfect, and put it in three-column format?" Advantages : Bold new challenges. Disadvantages: Makes one wish to be a garbage collector. Symptoms : An inability to keep quiet. Strong tendencies to make machines do things they don't want to do. Real Case : One user tried to get a scon to find out what another person's E-mail address was even though the user didn't know his target's home system, account name, or real name. Maestro: "Well, first I sat down, like this. Then I logged on, like this, and after that, I typed in my password, like this, and after that I edited my file, like this, and after that I went to this line here, like this, and after that I picked my nose, like this..." Advantages : Willing to show you exactly what they did to get an error. Disadvantages: For as long as five or six hours. Symptoms : Selective deafness to the phrases, "Right, right, okay, but what was the ERROR?", and a strong fondness for the phrase, "Well, I'm getting to that." Real Case : I once had to spend half an hour looking over a user's shoulder while they continuously retrieved a FIDONEWS 14-05 Page 34 3 Feb 1997 document into itself and denied that they did it (the user was complaining that their document was 87 copies of the same thing). Princess (unfair, perhaps, as these tend, overwhelmingly, to be males): "I need a Mac, and someone's got the one I like reserved, would you please garrote him and put him in the paper recycling bin?" Advantages : Flatters you with their high standards for your service. Disadvantages: Impresses you with their obliviousness to other people on this planet. Symptoms : Inability to communicate except by complaining. Real Case : One asked a scon to remove the message of the day because he (the user) didn't like it. Yours Humouresly, The Humour Man (aka Demitri Baroutsos) mailto:humour@bigfoot.com http://www.nis.za/homepgs/dbarout.htm http://cyber.nis.za/penpal/ Online Pager: http://wwp.mirabilis.com/189775 --------------------------------------------------------- ** DISCLAIMER ** None of the jokes posted are in any way intended to insult or offend any person/place/race/creed or sex. The jokes posted in no way represent my views or those of the company I work for. The jokes posted may contain rude or inappropriate words and/or content - parental guidance is advised. ===================END FORWARDED MESSAGE=================== ----------------------------------------------------------------- FIDONEWS 14-05 Page 35 3 Feb 1997 ================================================================= COMIX IN ASCII ================================================================= --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Mon Jan 27 06:12:42 1997 From: Dave Aronson @ 1:109/120 To: Chris Baker @ 1:18/14 Date: 26 Jan 97 21:38:52 Subj: more ascii comix I was going to send you more of my ASCII art, but I didn't want to /\__--~~~--__/\ ||\ /|| |/|(O) (O)|\| \ .---. / \ ( O O ) / \ `---' / `-----' the space all to myself. ----------------------------------------------------------------- FIDONEWS 14-05 Page 36 3 Feb 1997 ================================================================= NOTICES ================================================================= Future History 6 Feb 1997 Waitangi Day, New Zealand. 7 Feb 1997 Chinese New Year, Year of the Ox - 4695. 16 Feb 1997 Eleventh Anniversary of invention of Echomail by Jeff Rush. 29 Feb 1997 Nothing will happen on this day. 17 May 1997 Independence Day, Norway. 25 May 1997 Independence Day, Argentina. 6 Jun 1997 National Commemoration Day, Sweden. 11 Jun 1997 Independence Day, Russia. 1 Jul 1997 Canada Day - Happy Birthday Canada. 13 Oct 1997 Thanksgiving Day, Canada. 1 Dec 1997 World AIDS Day. 10 Dec 1997 Nobel Day, Sweden. 12 Jan 1998 HAL 9000 is one year old today. 22 May 1998 Expo '98 World Exposition in Lisbon (Portugal) opens. 1 Dec 1998 Fifteenth Anniversary of release of Fido version 1 by Tom Jennings. 31 Dec 1999 Hogmanay, Scotland. The New Year that can't be missed. 1 Jan 2000 FIDONEWS 14-05 Page 37 3 Feb 1997 The 20th Century, C.E., is still taking place thru 31 Dec. 15 Sep 2000 Sydney (Australia) Summer Olympiad opens. 1 Jan 2001 This is the actual start of the new millennium, C.E. -- If YOU have something which you would like to see in this Future History, please send a note to the FidoNews Editor. ----------------------------------------------------------------- FIDONEWS 14-05 Page 38 3 Feb 1997 ================================================================= FIDONET SOFTWARE LISTING ================================================================= Latest Greatest Software Versions by Peter E. Popovich, 1:363/264 My apologies to everyone; I missed last week's deadline. Sigh. And I was doing so well... ;-) I thought I'd have phased out the old info by now, but old info still makes up 47% of the column. I kept a few of the old sections around, hoping it would encourage folks to write in. It's also been harder to find contact info than I expected. Anyone who has contact info for -any- package of interest to Fidonet sysops is encouraged to submit it. I'm happy to do the leg-work of tracking down the specifics if I have a name to start with. Fair warning: The Xenix, Atari, and CoCo sections got a reprieve because folks wrote in. Since then, I've gotten a few Unix and Atari submissions, but no CoCo submissions. I plan to phase out the old Xenix and CoCo sections soon unless I hear something new. The Atari section will follow once I've followed up on my leads. Phased out this week: TBBS 2.1, TComm/TCommNet 3.4, Telegard 2.7, and TPBoard 6.1 Phase-out highlights: This week: "Xenix/Unix 386 -- Other Utilities" Section Deadline for info: 14 Feb 1997. Last week: WildCat! 3.02 and XBBS 1.77 Deadline for info: 7 Feb 1997. -=- Snip -=- Submission form for the Latest Greatest Software Versions column OS Platform : Software package name : Version : Function(s) - BBS, Mailer, Tosser, etc. : Freeware / Shareware / Commercial? : Author / Support staff contact name : Author / Support staff contact node : Magic name (at the above-listed node) : Please include a sentence describing what the package does. Please send updates and suggestions to: Peter Popovich, 1:363/264 -=- Snip -=- MS-DOS: Program Name Version F C Contact Name Node Magic Name FIDONEWS 14-05 Page 39 3 Feb 1997 ---------------------------------------------------------------------- Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP ALLFIX 4.40 T S Harald Harms 2:281/415 ALLFIX Announcer 1.1 O S Peter Karlsson 2:206/221 ANNOUNCE BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_DOS CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR CheckPnt 1.0 O G Michiel van der Vlist 2:500/9 CHECKPNT FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FASTECHO FastEcho/16 1.45a T S Tobias Burchhardt 2:2448/400 FE16 FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES FrontDoor 2.12 M S JoHo 2:201/330 FD FrontDoor 2.20c M C JoHo 2:201/330 FDINFO GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO GoldED 2.50 O S Len Morgan 1:203/730 GED GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM GoldNODE 2.50 O S Len Morgan 1:203/730 GEN Imail 1.75 T S Michael McCabe 1:1/121 IMAIL ImCrypt 1.04 O G Michiel van der Vlist 2:500/9 IMCRYPT InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL InfoMail/386 1.20 O F Damian Walker 2:2502/666 INFO386 InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB IPNet 1.11 O S Michele Stewart 1:369/21 IPNET JD's CBV 1.4 O S John Dailey 1:363/277 CBV Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386 JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G MakePl 1.9 N G Michiel van der Vlist 2:500/9 MAKEPL Marena 1.1 beta O G Michiel van der Vlist 2:500/9 MARENA Maximus 3.01 B P Tech 1:249/106 MAX McMail 1.0 M S Michael McCabe 1:1/148 MCMAIL MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP Msged 4.00 O G Paul Edwards 3:711/934 MSGED Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS O/T-Track 2.63a O S Peter Hampf 2:241/1090 OT PcMerge 2.7 N G Michiel van der Vlist 2:500/9 PCMERGE PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP RAR 2.00 C S Ron Dwight 2:220/22 RAR RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA Silver Xpress Door 5.4 O S Gary Petersen 1:290/111 FILES Reader 4.4 O S Gary Petersen 1:290/111 SXR44.ZIP Spitfire 3.51 B S Mike Weaver 1:3670/3 SPITFIRE Squish 1.11 T P Tech 1:249/106 SQUISH StealTag UK 1.c... O F Fred Schenk 2:284/412 STEAL_UK StealTag NL 1.c... O F Fred Schenk 2:284/412 STEAL_NL FIDONEWS 14-05 Page 40 3 Feb 1997 T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK TriBBS 10.0 B S Patrick Driscoll 1:372/19 TRIBBS TriDog 10.0 M S Patrick Driscoll 1:372/19 TRIDOG TriToss 10.0 T S Patrick Driscoll 1:372/19 TRITOSS WaterGate 0.92 G S Robert Szarka 1:320/42 WTRGATE WWIV 4.24a B S Craig Dooley 1:376/126 WWIV WWIVTOSS 1.30 T S Craig Dooley 1:376/126 WWIVTOSS xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL XRobot 3.01 O S JoHo 2:201/330 XRDOS OS/2: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- ALLFIX/2 1.10 T S Harald Harms 2:281/415 AFIXOS2 BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2 CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2 FleetStreet 1.18 O S Michael Hohner 2:2490/2520 FLEET GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO GoldED 2.50 O S Len Morgan 1:203/730 GEO GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM GoldNODE 2.50 O S Len Morgan 1:203/730 GEN ImCrypt 1.04 O G Michiel van der Vlist 2:500/9 IMCRYPT Maximus 3.01 B P Tech 1:249/106 MAXP Msged 4.00 O G Paul Edwards 3:711/934 MSGED PcMerge 2.3 N G Michiel van der Vlist 2:500/9 PCMERGE RAR 2.00 C S Ron Dwight 2:220/22 RAR2 Squish 1.11 T P Tech 1:249/106 SQUISHP T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2 Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK XRobot 3.01 O S JoHo 2:201/330 XROS2 Windows (16-bit apps): Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL FrontDoor APX 1.10 P S Mats Wallin 2:201/329 FDAPXW Windows (32-bit apps): Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP BinkleyTerm 2.60 M F Bob Juge 1:1/102 BW32_260.ZIP CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR GoldED 2.50 O S Len Morgan 1:203/730 GEO GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM Maximus 3.01 B P Tech 1:249/106 MAXN Msged/NT 4.00 O G Andrew Clarke 3:635/728 MSGNT400.ZIP FIDONEWS 14-05 Page 41 3 Feb 1997 PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO T-Mail 2.599I M S Ron Dwight 2:220/22 TMAILNT WinFOSSIL/95 1.12 r4 F S Bryan Woodruff 1:343/294 WNFOSSIL.ZIP WinFOSSIL/NT 1.0 beta F S Bryan Woodruff 1:343/294 NTFOSSIL.ZIP Unix: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- ifmail 2.8g M G Eugene Crosser 2:293/2219 IFMAIL ifmail-tx ...tx7.8 M G Pablo Saratxag