Volume 7, Number 34 20 August 1990 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | FidoNet (r) | | \ \\ | | International BBS Network | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Vince Perriello Editors Emeritii: Thom Henderson, Dale Lovell Chief Procrastinator Emeritus: Tom Jennings Copyright 1990, Fido Software. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact Fido Software. FidoNews is published weekly by the System Operators of the FidoNet (r) International BBS Network. It is a compilation of individual articles contributed by their authors or authorized agents of the authors. The contribution of articles to this compilation does not diminish the rights of the authors. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous Mail system, available for network mail 24 hours a day. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, Box 77731, San Francisco CA 94107, USA and are used with permission. Opinions expressed in FidoNews articles are those of the authors and are not necessarily those of the Editor or of Fido Software. Most articles are unsolicited. Our policy is to publish every responsible submission received. Table of Contents 1. EDITORIAL ................................................ 1 FidoNews Archiving -- the view from the City Desk ........ 1 2. ARTICLES ................................................. 4 Something We Can All Agree On ............................ 4 LHARC, The Snooze, IFNA, and Iraq ........................ 7 TechCon-I, the Report (part 1) ........................... 9 3. LATEST VERSIONS .......................................... 15 Latest Software Versions ................................. 15 4. NOTICES .................................................. 18 MetroFire [1:135/14] Moves Again! ........................ 18 The Interrupt Stack ...................................... 19 FidoNews 7-34 Page 1 20 Aug 1990 ================================================================= EDITORIAL ================================================================= A funny thing happened this summer. FidoNews changed its default archiver. It broke a few batch files. And FidoNet survived! Thank God for those little miracles. This has been a fascinating story. Certainly the best one I know of that concerns FidoNews itself. But it's starting to get boring now, and I'm going to have to bring it to a close. I have heard the words "insolent" and "arrogant" used to describe our actions. I'm not really sure where the insolence comes in. I'll have to wait until somebody explains that to me. As for arrogance -- if you're a software author in FidoNet and you're not arrogant yet, just wait a week or so, it's a communicable disease here. I've seen no cure as yet either, except perhaps for complete removal of the cause. So I'm arrogant. So sorry. That doesn't mean that I don't care about FidoNet at large. I do. Enough to be keeping my eyes open for potential problems and to take action when it appears warranted. I saw a potential problem. It appeared to require action. I took action. Harry took the heat. His call. I was willing to. I do now. There have been several objections to the change. Most of them were not objections to the dropping of ARC. Most actually protested the use of LHArc rather than ZIP. We'll cover that issue later in this editorial. The complaints which I want to address first are from those who felt we had acted unreasonably in making the change without advance notice. Did your batch file break? I apologize. Should I have given you some warning so you could fix it beforehand? Maybe. Would this advance notice have been interpreted as license to start a NET_DEV-style filibuster? I think so. I'm a great fan of Grace Hopper, whose favorite admonition is that it's often (I think she says "always" rather then "often", actually) easier to apologize than to ask permission. With that in mind, we decided to avoid the filibuster by presenting you with a fait accompli. However, before FidoNews went out in a .LZH file, I consulted the International Coordinator, the Zone 1 Coordinator, and the holder of the Trademark. Nobody cautioned me not to do it. Nobody told me not to do it. I had either an implicit or explicit go-ahead from each (though TJ made a point of not wanting to "meddle", one way or the other). Nobody felt that the world would come to an end if I made the change. Nobody felt that Dan Quayle would wind up as the U.S. President as a consequence of the lack of advance notice. End of story. We did it. FidoNews 7-34 Page 2 20 Aug 1990 That's why there was no advance notice. I still feel that it was the only way to make this change. To those of you who are still offended that I didn't appear at your doorstep, prostrate myself, and ask for your divine consent -- I'm sorry. But you're the kind of person Grace had in mind, and I'll not be asking your permission the next time I have an idea either. Let's get down the the "ARC versus the world" issue now. When you really get down to cases, it's the only part that matters. This has nothing to do with the SEA vs. PKware lawsuit. I made this decision before reading the materials that seem to be floating around the net -- in fact, I haven't read them yet for this very reason. ARC 5.12 was a standard that is still very widespread. But SEA is breaking this standard themselves in their new product, which works best in its (DEFAULT!) incompatibility modes. This is nothing new for ARC. It's part of ARC's evolutionary history. I know that many of you are familiar with the message "Sorry, I can't unpack this archive. You need a newer version of ARC." This inconvenience was offset by the improvements offered, and for those people who were using ARC on other platforms -- new source code to port. ARC 6.0 changed all that. For apparently obvious reasons, the widespread distribution of source code ended. As the gain involved in moving to 6.0 was small and the public was still angry over the Katz lawsuit (whether they were right or wrong in this regard, the fact remains that they were ANGRY), not too many people in FidoNet actually used it -- and those people were generally savvy enough to keep 6.0 archives off the public net. ARC 7.0 is a better product than 6.0. In fact, MUCH better. It will sell, in my opinion. To neophytes, in many cases. This makes the .ARC extension a shaky one for people who are still running ports of 5.12. Why? Consider those users who have no archiving software. They download FNEWSxxx.ARC. Then they download XARC or whatever to unarc it. In the process of registering their shareware ARC software or using XARC etc, they are very likely to find themselves on the business end of a sales pitch for ARC 7.0. Many people confronted with this pitch are likely to buy -- hell, why not? Then they archive something up. Then they upload it. Then if you're not running DOS or OS/2 you will not be able to access the contents of that archive, since there is no source available for any dearchiver and SEA is only releasing DOS and OS/2 software. That's intolerable. FidoNews 7-34 Page 3 20 Aug 1990 I hope the people at SEA do well. They are hard-working people and they deserve to benefit from the fruits of their labors. But I don't want to be in a position to help confuse the .ARC standard, which in my opinion is now locked at 5.12, through indirect marketing of ARC 7.0. I also do not want to somehow become victimized by it through receipt of ARC 7.0 archives that I can't unpack. So I won't distribute .ARC files. Most people think that if I don't use ARC, I should use ZIP. I think not. I know that there is code about for unzippers and that archive formats are documented. But ZIP could wind up on the same path as ARC, and since there are other archivers which are not being developed or distributed with commercial gain in mind, I'd rather pass on ZIP. Zoo is another standard. It's not too bad, in terms of compression. It's about on a par with ARC 5.12, in fact. But these days that's not too good. Rumors abound that Rahul Dhesi is adding better compression methods to it, but as yet -- nothing. That's the only bad thing I can say about it. Its structures are well thought out, in terms of portability. In fact, its portability is outstanding. LHArc is Freely Available with source in both Intel assembler and ANSI C. No marketing pitch, no fancy sales talk, always up to date on all platforms. And it's about as good as anything else (and MUCH better than ARC 5.12!). It's slower than most, but the bottom line is connect time. Smaller archives cost less to move. I chose LHArc because it was unencumbered with commercial intent or pretense (as is also the case with Zoo), and because it compresses much better. I intend to stay with it. There will be no change in archive format for the forseeable future. We've made our change and we're going to stick with it. I might add that for those of you who are getting FidoNews via file request from 1:1/1, you can request FIDONEWS to get the .LZH file and FIDOTEXT to get the uncompressed .NWS file. I don't know of anyone who can do file requests but can't uncompress a .LZH file, but you never know. Thanks for listening. This thread is now ended. Let's try to get conversation regarding FidoNews back to what's in it and not what it's in. Cheers, Vince ----------------------------------------------------------------- FidoNews 7-34 Page 4 20 Aug 1990 ================================================================= ARTICLES ================================================================= John Passaniti Fidonet 1:260/201 I am one-half of the Fidonet hub for Rochester, New York (260/2xx). Part of the thrill of being in Fidonet is wondering what other people are going to do, and how it will affect you. The recent Fidonews fiasco is a beautiful case in point. A well-meaning individual decided to make a change for the better, and used LHARC to compress Fidonews. That well-meaning individual probably didn't consider the number of people in the network who _expect_ or _need_ to have Fidonews be compressed as something resembling an ARC file. (Reminder: please write a "registered trademark" symbol after "ARC" in the preceding sentence on any printouts of this issue of Fidonews.) I really wouldn't have minded so much if I would have been given warning. As it turns out, we have a node in our hub which cannot decompress LHARC files-- he is running on a Tandy Color Computer, and nobody has ported LHARC for his machine. This means I have to spend time and effort in decompressing and recompressing the Fidonews for him. Should I have to? But enough of my bitching-- anyone can complain. I have a solution that with enough people's help can eliminate this sort of problem. THE PROBLEM: To some people, compression programs aren't a practical matter of concern-- they are a religious issue. There is an awful lot of "emotional liability" involved with some compression programs. Some people refuse to use ARC (again, don't forget the "registered trademark" symbol) because of the court case between SEA and PKware. Some people refuse to use PKZIP for the same reason. Both kinds of people probably don't have enough depth to understand what the court case was really about, and waste the time of the rest of us with their nonsense. If recent comments in Fidonews are to be believed, some people object to the use of LHARC because it is was written by a Japanese person. Wow-- futile nationalism comes to software! I'm sure there are others who have strong objections to using programs like ZOO, and whatever other compression programs I haven't mentioned. FidoNews 7-34 Page 5 20 Aug 1990 Others may have more valid (non-religious) reasons for objecting to certain compression programs. Some programs may not be ported to their machine. Some programs might go outside the bounds of what a particular machine can do (such as amount of memory needed, or disk I/O limitations). THE SOLUTION: What is needed is a _true_ Fidonet compression standard. This standard should be 100% public domain, and be written in as portable a manner as possible to promote it to be ported to as many machines as possible. ARC, PKZIP, LHARC, ZOO, and whatever others are out there fail in various respects. The source code for ARC isn't portable without tedious work, and it certainly isn't public domain. PKZIP offers no source code. LHARC offers source code, but it isn't as portable as some would lead you to believe. And ZOO-- well, ZOO is about the best candidate of the bunch, but I'm sure someone, somewhere out there has some objection to it-- valid or not. This new Fidonet compression standard would be used for the weekly Fidonews and "nodediff." It would also replace ARC as the _base_ standard for echomail compression. Note that this doesn't prevent two consenting adults from using any echomail compression program they want on the privacy of their own system. Note that the purpose of this compression standard wouldn't be to compete with other compression programs. The authors who write those programs have interests other than Fidonet in mind. This new compression standard would be both BY Fidonet members, and FOR Fidonet members. MAKING THE SOLUTION A REALITY: Software doesn't appear out of thin air, and while my mythical compression standard doesn't yet exist, nothing is preventing a few programmers who are interested in such a project from getting together and making it a reality. Such a group would include programmers who were familiar with portability issues; who could work both independently and together with others; and who could port the compression standard to as many machines as possible. Every single machine that now can participate in Fidonet would NEED this compression standard ported to it, or it would be useless as a standard. FidoNews 7-34 Page 6 20 Aug 1990 To start this project, I offer an echo conference to anyone who would like to participate in it. The conference will be unmoderated, and available initially from Fidonet 1:260/228. If you are interested, please send mail to me at 1:260/228, and I'll set you up so you can poll for it. CLOSING WORDS: Virtually every technical specification needed to participate in Fidonet is available-- from either the Fidonet Technical Standards Committee documents which are available, or from the wealth of source code that many authors have contributed. The only technical specification that isn't similarly documented is a compression standard. This is a glaring oversight that needs to be corrected as soon as possible. Fidonet has grown far beyond anyone's imagination, and continues to grow. The lack of a technical specification for a compression standard is something that must be addressed. With your help, we can create such a standard, and promote the spread of Fidonet. ----------------------------------------------------------------- FidoNews 7-34 Page 7 20 Aug 1990 LHARC, The Snooze, IFNA, and Iraq --------------------------------- By Kwityer Bychin Well folks, here I am once again to agitate and irritate the masses. Being that the masses are so easily agitated and irritated. We'll start this week's column with a little talk about the most recent Earth-shaking, life threatening, disaster to strike Fidonet; Vince & Harry's switch to LHArc FOR THE SNOOZE!! (Dun Dun DUNNNN!).... Oh boy this REALLY IS A BIG DEAL now, ain't it folks?! I mean, the entire membership of Fidonet literally SCRAMBLES to read the Snooze every week now don't we? I mean, it plays such a major part in our lives, that any attempt to change it is sacreligious! Now, let's take a look at this thing like the mature well-adjusted adults that we are shall we? Here we have Vince Perriello, a NICE GUY. He is, really. I've met him. He spent 4 days at Conclave '90 doing this 'n that, but not ONCE did he engage in ANY sort of devil-worship whatsoever. Nope. No horns, no tail, just a couple bottles of BINK BEER and a copy of Fight-O-News, cruising through the conference. Meanwhile, back at the ranch, all kinds of people are foaming at the mouth because Commandant Perriello had the audacity to change COMPRESSION METHODS for the Snooze. And to our absolute HORROR, he didn't even ask PERMISSION. Woooo. Bad dude, that Perriello. Vince whips out his copy of LHarc, compresses the Snooze, ships it off, and all kinds of PEOPLE start whining WAAAAAAH! WAAAAAH! YOU BROKE MY BATCH FILE!! WAAAAAH!! As if NOTHING ever went awry with their systems. You say can't decompress the LHarc archive? Well guess what Virigina? The source code is available! MAKE IT WORK ON YOUR SYSTEM. What? You say you don't WANT to port the code over? Y9ou don't know HOW? You want someone to make a version FOR YOU? OHHHH!! Right Away! Hey, this is a HOBBY, this ain't LIFE & DEATH here. If your batch file's broke, FIX IT. OH WAIT!! There's a GIF PICTURE in Snooze #733! Oh my GOD this is terrible! We can hear the bawling already! WAAAAAHH!! The archive is too big now!! WAAAAAH!! TWO FILES in the archive broke my new batch file that I just fixed!! WAAAAAH!! I WANT AN RLE PICTURE!!! WAAAAH!! I CAN'T VIEW IT ON MY TIMEX/SINCLAIR!! FidoNews 7-34 Page 8 20 Aug 1990 And as far as IRAQ is concerned, we could end that conflict over there by giving Hussein a node number and sending him and his buddies the SYSOP echo. And maybe a copy of the NEW IMPROVED FIDONEWS! Then they could spend all their time FLAMING AND KILLING EACH OTHER, just like WE DO! Wow. Chemical weapons in the SYSOP conference.... Now I'm supposed to talk about IFNA. Remember IFNA? NO??? Where have you BEEN for the last week or so? Well, for those of you that know what IFNA was, IT'S DEAD. Yep. The membership and the BoD voted it into oblivion on August 4, 1990. TRASHED it. And You know what? Since the thing kicked the bucket, traffic in the IFNA echo skyrocketed! Pretty good huh? Speaking of the IFNA echo, you GOTTA check this one out. Read the stuff in there by this guy named FRED. He wants to BAN BETA TESTING OF MAILERS. He wants to make an FTSC with a minimum AGE requirement of 25. He wants to do all kinds of INTERESTING STUFF. If you're too young to remember Joe McCarthy, HERE IS YOUR BIG CHANCE. Hey kids! You're old enough to drive, old enough to vote, old enough to DIE FOR AMERICA IN SAUDI ARABIA, but FRED SAYS you AIN'T OLD ENOUGH to evaulate BINKLEYTERM! Hey, let's hear it for Fred huh! A big hand, come on! Oh and before I go, how about that BOB MORAVSIK eh?? Let's give him a big hand! How can I possibly end such a violent column without taking a couple shots at MAHATMA-RAVSIK??!! Didja read last week's SNOOZE ?? (Oh, that's right I forgot. You can't decompress it). Well anyway, an article in last week's Snooze says MAHATMA-RAVSIK was named IC! PRETTY FUNNY STUFF EH? I'll bet that if that really happened, he'd file a complaint against himself, and be EGGS-COMMUNICATED. Oooooh. BAD EGG that Moravsik. Well folks, that's enough drivel for this issue. Now WHIP OUT those word processors while your blood pressure is still 200 over 150 and SEND IN THAT HATE MAIL! Let's see just how good a job LHarc REALLY DOES! K.B. ----------------------------------------------------------------- FidoNews 7-34 Page 9 20 Aug 1990 Jan Ceuleers 2:295/53 TechCon-I, the Report (part 1) OK, so here it is folks: the first part of the TechCon-I report. "What is a TechCon?", I hear you ask? TechCon-I was the first 2-day conference which was entirely devoted to FidoNet Technology. It was held at the same time and in the same hotel as EuroCon-IV: on July 14th and 15th in Antwerp, Belgium. Anyway, if this is the first you hear of TechCon, you haven't been reading FidoNews regularly, because it was announced well in advance, and already commented upon by FidoNews' editor, Vince Perriello. Vince wasn't at TechCon simply as the FidoNews Editor (in fact, that's not why he was there at all). He'd also brought Bob Hartman and the new BinkleyTerm with him. Moreover, Rick Moore had appointed him as the official FTSC representative at TechCon. Obviously, there were a lot of other interesting people among the attendants (me, for one ;-). I'm not going to name any, because I'd have to list all of the attendants in order not to forget anyone interesting. Anyway, here we go... BinkleyTerm 2.40 Release - Bob Hartman and Vince Perriello ---------------------------------------------------------- It had been quite a while since the Trio released BinkleyTerm 2.30 (September 5th, 1989), so something was to be expected. We were nevertheless semi-surprised and delighted that Bob and Vince came to Europe to give their first public presentation on BinkleyTerm 2.40 at TechCon. The features: - Most of the messages BinkleyTerm displays and puts in its log are now configurable, in order to accomodate non-English- speaking users. This will probably break every log analyser in existence, but what the heck :-). The messages are contained in a separate file (BINKLEY.LNG) which can be generated by a language file compiler. The structure of this file is published (by means of the Binkley source code), so log file analysers should make use of this structure, and compare the messages they find in the log to the ones they find in the .LNG-file. - Janus, the long-awaited full duplex file transfer protocol, has finally been added on an experimental basis. It is important for users to understand that it might break. (As it FidoNews 7-34 Page 10 20 Aug 1990 happens: evidence that there was indeed a problem had been popping up earlier that day. During the rest of their stay, Bob and Vince worked with their local beta team to start solving this and other problems, JC). Janus is rather counterproductive on HST connections, because of the long line turn-around times. It does work very well in V32 situations though. - A state engine has been implemented, providing a relatively simple way to implement new protocols should the need arise. This has also helped in assuring compatibility with FTS-0007 and FTS-0008, much to the delight of SEAdog users. - BinkleyTerm now supports 5D-addressing, that is: zone, net, node, point and domain. This includes support of FSC-0045 and FSC-0049. The nodelists for each of the domains are separate: they no longer have to be compiled into a set of huge files. A drawback is that no packer easily supports this new feature as yet. It can be done with some intricate batch file programming though. - The first pop-up windows have been added to Bink: Alt-G (interactively generates a file request), Alt-S (a file attach) and Alt-K (removes all mail for the named node from the outbound). This required another extension of the Colors- statement in the config file. - BinkleyTerm can now exit with a configurable exit code upon receipt of one or more files with a certain extension (say, .TIC). Comes in handy for SDS nodes. - Support for yet another multitasker was added: PC-MOS. Also, if no multitasker is detected nor declared, Binkley will call the DOS idle interrupt (0x28) whenever it would have called the multitasker's time slice release routine, had a multitasker been installed. This tremendously speeds up background tasks under DOS, such as the $25 Network. - Another long-awaited feature is MaxBytes: a limitation of the number of bytes a certain class of nodes is allowed to request during one session. Insufficient time was left before TechCon started for Vince to implement a limitation based on time (or baud rate, if you like) as well. This will be incorporated in a future release. - In order to avoid the dead-time between the CONNECT message from the modem and the start of the session, an MNP and V42 Modem Protocol Negotiation Filter has been implemented. The 3-second delay was required for the classic case where a non- MNP modem was called by an MNP modem. The MNP handshake had to be skipped, since it could contain an ESC, which would obviously cause Binkley to drop to the BBS. It is now filtered instead. - A Terminal-mode initstring was added. - Curmudgeon mode will no longer throw out new nodes who use the net/-1 or net/9999 convention, so as to allow NCs who like Curmudgeon mode to take calls from nodes in spe. - In order to support multi tasking even better, semaphore files are being placed in the outbound areas during sessions. Other tasks can look for these files (.BSY extension) and not do anything that might interfere with the ongoing session. Binkley will refuse to send files to a node if it detects that that same node is engaged in a session with a Binkley in FidoNews 7-34 Page 11 20 Aug 1990 another task (or on another workstation of the LAN). - The screen can now be unblanked during a session. The unblanking functionality can now also be selected: should the screen unblank when a key is pressed, or whenever something happens? - BinkleyTerm is definitely dolphin-safe. No Bink has ever killed a dolphin. (This is an undocumented feature, JC). Question time. (The following questions and answers reflect my interpretation of the discussion, JC). Q: Could you please implement a file request limit based on time as well? A: Yes, we're working on it. It could have been in this release, but we ran out of time. Q: Why does an .RSP-file need to be a file. Couldn't you send a packet like D'Bridge ? A: You can't always send a packet and expect the other side to know that you've sent mail. Not all protocols support sending more than 1 packet per session in each direction. Q: Can a BinkleyTerm user put a file on hold for a point that is not his own without knowing the point's private net? A: No. The reason why BinkleyTerm isn't fully 4D is that this poses a problem with Opus 1.03. Wynn defined a 4D structure in the hello-packet, but subsequently didn't use it himself. Therefore, if we were to implement this (Bink hasn't changed in this respect since 2.00), a point using BinkleyTerm would pick up the mail destined for his boss. This was not acceptable, because of the large number of nodes (a few thousand) that were using barefoot Opera, and the release of Opus 1.10 was far from imminent. Now that this problem has been addressed in Opus 1.10, the importance of this argument has obviously diminished, but we still don't think that the number of nodes that would have to change over overnight is sufficiently small yet. But we will address this problem in the near future ("It'll probably be in the next release"). Q: What do you think about EMSI? A: The way we see it, EMSI should address 3 problems: we'd like to see a novel way to update the nodelist, it would be nice if two nodes could exchange all the mail for their respective AKAs during a single session, and we'd like to be able to talk to mainframes, that have front-end processors requiring CRs between input records, as well as 7-bit data. The first two are indeed addressed by EMSI as of now, but we feel that the third-one is much more important, in view of the fact that large companies have offered us (FidoNet) their excess capacity for free. We're sure Chris and JoHo will work with us towards a solution to this problem. FidoNews 7-34 Page 12 20 Aug 1990 Message Digest -- Henk Wevers ----------------------------- Henk is a professional crypto-analyst. He talked about the MD4 method of message authentication, which was devised by an American corporation with the cooperation of M.I.T. The algorythm creates a 128-bit (16-byte) fingerprint which would take 2^128 computations to fake. Due to its simplicity, MD4 is very fast. Henk provided sample source code in Pascal and C (the files MD4PAS.ARC and MD4C.ARC are available from 2:295/27). He urges everyone to take a look at this, and to propose a way to utilise it in FidoNet. Before this, or any other method of authentication, can be used, we need to define exactly what the 'message text' is. Kludge lines are certainly not a part of the message text in this respect: they should be skipped when calculating the message digest, because they can change as the message progresses through the network. The problem is that there isn't really a definition of what a kludge line really is. Henk has been talking to Randy Bush about this, specifically about the definition of a 'physical line'. This must be solved first. Edifact -- Henk Wevers ---------------------- The type 2 packet, as it is currently in use, has proven to be problematic, in that many of its uses are too loosely defined, and that too little flexibility is allowed for. We therefore need a solid standard on message structure, for which there are two well-known contenders: X.400 and Edifact. The X.400 standard is very difficult to implement, so let's concentrate on Edifact. Edifact is an entirely text-based (not necessarily ASCII) message standard, which is very simple to implement. (As a matter of fact, the commercial version of Dutchie already supports Edifact.) The standard comprises specifications on the message format and on the bundling of those messages. The bundling part of the standard is very straightforward: messages are simply concatenated in a file to form a bundle. As for the message format: a group of people planning to exchange Edifact messages is free to define its own message building blocks, in addition to those that are predefined in the standard. The FTSC could be the body that maintains a list of building blocks for use in FidoNet: a database of centrally allocated building block definitions. FidoNews 7-34 Page 13 20 Aug 1990 The character set in use in most Edifact implementations to date is 7-bit ASCII, because of the wide range of platforms the messages need to be processed on. The standard is already in common use in the transportation, the medical and the banking sectors. Edifact allows for the easy implementation of forms: a company could send its customers an Edifact message containing a form for them to fill out, to order certain goods, for example. Likewise, an NC could send such a message to an applicant for a node number. Form fields can be mandatory or optional, conditional, repetitive, etc. This implies that a message editor for Edifact looks more like a form processor than like a 'conventional' message editor. This standard is not difficult to implement, and it'll gain us a lot of credibility in the world at large. For more info on Edifact, please ask Henk Wevers in netmail how to order a copy of the standard. Echomail -- Vince Perriello --------------------------- A brain storming among a few attendants during the coffee break caused Vince to bring a subject up that had previously been discussed by a subcommittee of the FTSC: a way to distribute conferences without having to insert PATH and SEEN-BY information (or its equivalent). Vince's version of this concept was based on the idea that each node has a maximum of one uplink for a certain area, and that a bit in the message header (like the file request bit, which isn't used in echomail anyway) would specify whether a message is on its way up in the topology, or on its way down. After a number of questions from the audience, this mechanism was proven not to be immune against dupes, and it was agreed that any type of conference distribution system without PATH or SEEN-BY information should be. Bob pointed out that GroupMail actually does all the things we want, and that it's a mystery why the GroupMail standard hasn't been used more widely. The standard is published, and there is no reason why groupmail processors could not be written that support different compression programs than Arc. OK, so that's the first part. The rest of it will appear in the next issue, or so I hope... FidoNews 7-34 Page 14 20 Aug 1990 Jan Ceuleers (2:295/53) ----------------------------------------------------------------- FidoNews 7-34 Page 15 20 Aug 1990 ================================================================= LATEST VERSIONS ================================================================= Latest Software Versions MS-DOS Systems -------------- Bulletin Board Software Name Version Name Version Name Version DMG 2.93 Phoenix 1.3 TAG 2.5f* Fido 12s+ QuickBBS 2.64 TBBS 2.1 Lynx 1.30 RBBS 17.3A TComm/TCommNet 3.4 Kitten 2.16 RBBSmail 17.3A Telegard 2.5 Maximus 1.00 RemoteAccess 0.04a* TPBoard 6.1 Opus 1.13+* SLBBS 1.77* Wildcat! 2.15 PCBoard 14.2 Socrates 1.00 XBBS 1.13 Network Node List Other Mailers Version Utilities Version Utilities Version BinkleyTerm 2.40* EditNL 4.00 ARC 7.0* D'Bridge 1.30 MakeNL 2.20 ARCAsim 2.30 Dutchie 2.90C ParseList 1.30 ARCmail 2.07 FrontDoor 1.99c* Prune 1.40 ConfMail 4.00 PRENM 1.47 SysNL 3.11 Crossnet v1.5 SEAdog 4.51b XlatList 2.90 EMM 2.02 TIMS 1.0(Mod8)* XlaxDiff 2.35* Gmail 2.05 XlaxNode 2.35* GROUP 2.16 GUS 1.30 InterPCB 1.30* LHARC 1.13 MSG 4.1 MSGED 2.00* PK[UN]ZIP 1.10 QM 1.0 QSORT 4.03 Sirius 1.0w SLMAIL 1.35 StarLink 1.01 TagMail 2.20 TCOMMail 2.2 Telemail 1.20 TMail 1.15 TPBNetEd 3.2 TosScan 1.00 UFGATE 1.03 XRS 3.40 ZmailQ 1.12* FidoNews 7-34 Page 16 20 Aug 1990 Macintosh --------- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Red Ryder Host v2.1b10 Tabby 2.2 MacArc 0.04 Mansion 7.15 Copernicus 1.0d* ArcMac 1.3 WWIV (Mac) 3.0 StuffIt 1.6b1* FBBS 0.91* TImport 1.331 Hermes 0.88* TExport 1.32 Timestamp 1.6 Tset 1.3 Import 3.2 Export 3.21 Sundial 3.2 PreStamp 3.2 OriginatorII 2.0 AreaFix 1.6 Mantissa 3.21 Zenith 1.5 UNZIP 1.02b Amiga ----- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Paragon 2.06+ BinkleyTerm 1.00 AmigArc 0.23 TrapDoor 1.50* AReceipt 1.5* WelMat 0.35 booz 1.01 ConfMail 1.10 ChameleonEdit 0.10 ElectricHerald1.66* Lharc 1.10 MessageFilter 1.52* oMMM 1.49b ParseLst 1.30 PkAX 1.00 PK[UN]ZIP 1.01 PolyxAmy 2.02* RMB 1.30 TrapList 1.12* UNzip 0.86 Yuck! 1.61* Zoo 2.00 Atari ST FidoNews 7-34 Page 17 20 Aug 1990 -------- Bulletin Board Software Network Mailer Other Utilities Name Version Name Version Name Version FIDOdoor/ST 1.5c* BinkleyTerm 1.03g3 ConfMail 1.00 Pandora BBS 2.41c The BOX 1.20 ParseList 1.30 QuickBBS/ST 0.40 ARC 6.02* GS Point 0.61 LHARC 0.51 LED ST 0.10* BYE 0.25* PKUNZIP 1.10 MSGED 1.96S SRENUM 6.2 Trenum 0.10 OMMM 1.40 Archimedes ---------- BBS Software Mailers Utilities Name Version Name Version Name Version ARCbbs 1.44* BinkleyTerm 2.03* Unzip 2.1TH ARC 1.03 !Spark 2.00d* ParseLst 1.30 BatchPacker 1.00* + Netmail capable (does not require additional mailer software) * Recently changed Utility authors: Please help keep this list up to date by reporting new versions to 1:1/1. It is not our intent to list all utilities here, only those which verge on necessity. ----------------------------------------------------------------- FidoNews 7-34 Page 18 20 Aug 1990 ================================================================= NOTICES ================================================================= Christopher Baker MetroFire, 1:135/14, Miami_FL_USA This Time it's More than a Phone Number! MetroFire is changing numbers AND locations this time. As of Nodelist.229 on 17 Aug 90, MetroFire will cease to be 1:135/14 and will become 1:374/14 in Titusville_FL_USA. 135/14 will continue to be listed in Net 135 for a couple weeks while I make the transition to my new locale and get the requisite dedicated line. It will appear as a Hold Node in both Nets 135 and 374 during the changeover. Those of you who have active links to MetroFire are advised to note this change and to change any passwords or links to 1:374/14 from 1:135/14 after you've compiled Nodelist.229. Those linked to Echos that I originate [FHCOOK and MENSANS_ONLY] will continue to get those Echos sent to you directly. You will not be able to poll the new listing for a couple weeks, at least. This move is sudden and a direct result of a Workmans Compensation case I've been embroiled in for some time. I have received a judgement in my favor but it still has not been paid and I can no longer afford to live in Miami while my former employer attempts to reverse it on appeal. I apologize to anyone who is being inconvenienced by this change. I am not leaving FidoNet or BBSing but I must move to Titusville [and was going to anyway when the case was settled] where my family resides before the sheriff throws me out [I haven't been paid since 29 Mar 90]. [grin] Mail sent to either Node number will eventually make it to me but I suggest you start using 1:374/14 as soon as you compile Nodelist.229. My thanks to Net 135 for their generosity and cooperation and Hello to Net 374! Here comes trouble. [snicker] ----------------------------------------------------------------- FidoNews 7-34 Page 19 20 Aug 1990 The Interrupt Stack 5 Oct 1990 21st Anniversary of "Monty Python's Flying Circus" 6 Nov 1990 First anniversary of Van Diepen Automatiseert, 2:500/28 14 Nov 1990 Marco Maccaferri's 21rd Birthday. Send greetings to him at 2:332/16.0 1 Jan 1991 Implementation of 7% Goods and Services Tax in Canada. Contact Joe Lindstrom at 1:134/55 for a more colorful description. 16 Feb 1991 Fifth anniversary of the introduction of Echomail, by Jeff Rush. 7 Oct 1991 Area code 415 fragments. Alameda and Contra Costa Counties will begin using area code 510. This includes Oakland, Concord, Berkeley and Hayward. San Francisco, San Mateo, Marin, parts of Santa Clara County, and the San Francisco Bay Islands will retain area code 415. 1 Feb 1992 Area code 213 fragments. Western, coastal, southern and eastern portions of Los Angeles County will begin using area code 310. This includes Los Angeles International Airport, West Los Angeles, San Pedro and Whittier. Downtown Los Angeles and surrounding communities (such as Hollywood and Montebello) will retain area code 213. 1 Dec 1993 Tenth anniversary of Fido Version 1 release. 5 Jun 1997 David Dodell's 40th Birthday If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. -----------------------------------------------------------------