F I D O N E W S -- Volume 14, Number 7 17 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. | +----------------------------------------------------------------------+ IT'S PRESIDENTS' DAY IN THE U.S.A. Table of Contents 1. EDITORIAL ................................................ 1 Echomail anniversary and other gripes .................... 1 2. GUEST EDITORIAL .......................................... 3 Another viewpoint about FidoNet .......................... 3 3. ARTICLES ................................................. 5 Common Sense for Fidonews ................................ 5 FTSC - Maybe this article should be .jok ................. 5 4. COLUMNS .................................................. 7 FIDONET IN EUROPE ........................................ 7 5. GETTING TECHNICAL ........................................ 8 FSC-0037 - AVATAR proposal ............................... 8 FSC-0038 - A Domain Proposal ............................. 12 FSC-0039 - A Type-2 Packet Extension Proposal ............ 13 6. COORDINATORS CORNER ...................................... 20 Nodelist-statistics as seen from Zone-2 for day 045 ...... 20 7. NET HUMOR ................................................ 21 Jeane Dixon didn't see it coming? ........................ 21 8. NOTICES .................................................. 24 Future History ........................................... 24 9. FIDONET SOFTWARE LISTING ................................. 26 Latest Greatest Software Versions ........................ 26 10. FIDONEWS PUBLIC-KEY ..................................... 33 FidoNews PGP public-key listing .......................... 33 11. FIDONET BY INTERNET ..................................... 34 And more! FIDONEWS 14-07 Page 1 17 Feb 1997 ================================================================= EDITORIAL ================================================================= As I write this Issue's editorial, it is the 11th anniversary of the invention of Echomail by the now infamous Jeff Rush. Echomail is now the reason why many people belong to FidoNet. What a concept! More opinion on the size of FidoNet this week but differing views of where the 'bloat' is. I guess it depends on whose ox is gored. [grin] Below is the text of an exchange with a Z2 Sysop. I didn't have time to get his permission to post his side but his name is removed for the sake of discussion and only my quoted reply is included. Date: 16 Feb 97 14:08:46 From: Christopher Baker on 1:18/14 Rights On! in Edgewater FL To: Zone 2 Sysop Subj: Re: FNews ______________________________________________________________________ > CB> but smaller IS better, right? [chuckle] > I think you won't understand. i think understanding is important. we all need to understand what is going on here. > It has nothing to do with smaller or bigger ... good, because size is irrelevant unless FidoNews in archive gets too big to fit on a floppy. > Posting old (and almost uninteresting) Doc's (while not practicised) > is pure nonsense. practice makes perfect. the publishing is for historical and technical purpose. the FTSC has lain dormant for years. the folks who went to all the trouble of creating the various proposals and technical essays contained in the FTSC docs never got much of an audience. the publishing serves to illustrate where we came from and may stimulate some action on some of these plans. it also acquaints people with the underpinnings of the hobby many do not understand at any technical level. > And the Fidonet-Software-Listing ? > Isn't there a FIDOSOFT conference where the listing may be posted ? > In Germany there is FIDOSOFT.xxx where discussions are going on and > a bigger list is posted frequently. Echomail is not mandatory and not what FidoNet is or does. it's a nice add-on that is useful for specific topics but it is not universal nor available to everyone in toto. your reference to FIDOSOFT.xxx is a good example of a local phenomenon that nobody outside your area knows about. that's why FidoNews is an important conduit for such FIDONEWS 14-07 Page 2 17 Feb 1997 information. > I crashed this file month ago to Peter ... nothing happens. did you get any mail back from him? perhaps, he has incorporated some of the info into his listings or used it as a contact point for the authors involved? i cannot answer for Peter. he has taken on a monumental and thankless task in reorganizing and winnowing this list. the software list is VERY important to FidoNet. it is the ONLY centralized list of what is available for new Sysops [or current Sysops looking for a change]. it won't always be the size it is now. it is being actively maintained which means the dead wood will be removed eventually. this is going to take time, however, and FidoNews is not going to suffer for its size or content while that process continues. it is important information and the only way to get it to everyone [including the authors] at once is via FidoNews. the point is that FidoNews is the only place [other than the Nodelist] that is standard to all FidoNet Nodes. it is the appropriate place to recount FidoNet history and to disseminate material peculiar to FidoNet. i hope this helps our mutual understanding. [grin] thanks. QOFM. Chris -30- We have another Guest Editorial in response to Clay's of 1406. Keep 'em coming! I also see that Clay Tannacore HAS returned to the Nodelist as of .045 on Friday. That's the spirit! C.B. ----------------------------------------------------------------- FIDONEWS 14-07 Page 3 17 Feb 1997 ================================================================= GUEST EDITORIAL ================================================================= [This was slightly reformatted and edited for spelling and punctuation and clarification of which Net is being referred to only.] Ed. Hi Chris.. I don't suppose this will be in the proper format for a submission, but I am ignorant of such things. Please do as you see fit. I'm responding to a few pieces in the latest issue of Fidonews - volume 6/97. Specifically, the article by Clay Tannacore about the direction of Fidonet. I found myself nodding my head in agreement with just about everything Clay says in his article. I particularly found agreement in his position #5, regarding the overuse of quoting in echomail. This has long been a thorn in my side in every echo I read, or have read and left. I have, on numerous occasions, taken it upon myself to attempt to educate writers in the proper methods of quoting in echomail. Among them, only quoting enough of the original message so others know your point of reference. I've also campaigned against the geeks with the multi-line, Internet style, high ascii "sigs" people have become so fond of lately. As a SysOp myself, I'm aware of the costs involved in moving echomail. I take it personally when people abuse our largesse with this crap. Unfortunately, the response to most of my pleas has been to "mind your own business - you ain't the Moderator!" Now you would expect such from the elements who regard anonymous communications as there personal playground to practice "Beavis and Butt-Headisms", but when you get the same response from an echos Moderator - saying "Leave the Moderating to the Moderator" - it's a bit much. After all, had the Moderator been doing his job - such conduct would not have been tolerated. The attitude seems to be "Fido is dying, let them talk or they'll go to the Net." Well fine - let them go if that's what Fido has degenerated into -I don't like paying the freight for it! Clay's point on the plethora of "Pay to Use" BBSes also struck a cord here. I've run a board since 1992 - as a hobby. Shareware BBS software (TriBBS 10/Pro, registered, thank you), bottomline all the way. I've never charged for access to my board. Yes - I do offer subscriptions for cash or donations of equipment in exchange for increased file limits. Now, there are 2 schools of thought on Pay vs. Free boards. The first is that people seeing a board charges for access will assume it has to be pretty good or they wouldn't charge. Interesting! The second is that, as Clay points out - we do this as a hobby, and therefore shouldn't charge for access. I tend to see points of agreement in each, since a few pay boards in my area are doing great, while free boards like mine are suffering. Doubly interesting since on "free previews" I've taken on these boards, neither the graphics work, features, games, nor filebase are as extensive or good as mine. But there ya go - different strokes. Clay's proposition that pay boards are sometimes thinly disguised pirated software hangouts, i.e. "Elite" FIDONEWS 14-07 Page 4 17 Feb 1997 boards, has an element of truth to it. That is certainly the case in my areas anyway. I limit non-members on my board to specific but generous download levels. Members are allowed practically unrestricted downloads. That's it. All callers have full access to the 15 CDROMs I carry, all message networks and echos, and all the games. I do know of several boards running hacked software, with logon procedures like speakeasys of the 20's - complete with "joe sent me" doorways and phony menus. Pretty neat if you want to spend 3 hours online downloading a copy of Win95 at 14400. Not me, thanks. A final point is Clay's mention of the effects of the [Inter]Net on local "hobby" bulletin boards. The [Inter]net has hurt me badly. Calls have dropped significantly over the last year, for a number of reasons. One of those is new computer owners/users don't need additional communications software and the accompanying knowledge to call the [Inter]Net - most PCs come with the software. They can connect to the [Inter]Net and play. To call a BBS they have to locate and install a comm program, find some local boards numbers, then plod through setting up to connect properly with ANSI, etc. Not a lot of fun for todays crop of "point and click or forget it" PC users. We should indeed stress the FREE nature of our boards, and the usefulness of Fidonet in messaging all over the world via a local call. I've found myself making close friends I've yet to meet in countries the world over, as well as states of this great country I've never visited. That means something, and should be made note of. There has to be a simpler method of interfacing local boards with beginners PCs. How that could be accomplished I have not a clue - the more technical aspects of these toys we play with escape me, and at this time of my life (age 50), there is no hope of my learning. That I will leave up to others more capable. Fido[Net] has some problems, to be sure. None of them are insurmountable, in my opinion. Surely the "in your face" mentality of certain recent critics does nothing to enhance its prospects. Fidonet after all is a mirror image of politics - many criticize, yet too few offer solutions. Not surprising since criticism is easy. Finding solutions takes work and some semblance of intelligence - both characteristics lacking in the harbingers of doom. Respectfully, Bruce Emmott SysOp, Aegis BBS 1:2619/121 Merrick, NY ----------------------------------------------------------------- FIDONEWS 14-07 Page 5 17 Feb 1997 ================================================================= ARTICLES ================================================================= Common Sense for Fidonews by Lee Kindness, 2:259/7, lkindnes@csl.co.uk Gary Gilmore was quite rash in a number of his comments a couple of weeks back... However a couple of valid comments can be made regarding Fidonews's size and content: o Internet distribution sites - A simple link to a web page that contains these address would suffice. It goes without saying that everyone that is interested in these sites would have internet access, and hence be able to access such a page. o Zone, Region, Net Homepages - As above, a reference to a web page would do. o Jokes & ASCII 'pics' - Not the thing we should *promote* for Fidonews inclusion. It's the type of thing anyone with an email address gets bombarded with daily from friends and in the humour echoes (PUNCH et al). So before you think about submitting these jokes and pictures consider that you've got - it's more than likely everyone else has too! o Software listing - Monthly rather than weekly would be a better frequency, and lets get rid of the old software section - a pile of meaning less names and version numbers is of no use to anyone! o PGP key - A pointless peace of INet poseur? Lets cut down on all the static information... And now onto the positive aspects... The posting of FTSC documents is a great idea (i waiting to see how the RTF FSC is handled thou ;) and Chris has done a great job in reviving Fidonews after Tees's death grip. -- _____ _ _ _____ ( __ )(_)-coco-moko-cwewe-modete-escro-(_)( __ ) \/ (_)(_)-loko-noko-lkindnes@csl.co.uk-(_)(_) \/ ----------------------------------------------------------------- FTSC - Dead and Buried? by Lee Kindness, 2:259/7, lkindness@csl.co.uk Last year i submitted 3 FTS update proposals to the FTSC Chair Dave Nugent. 5 months later, no reply. Speaks volumes really... I wonder how many people remember the words of Dave when he took over the position, pot calling the ke... I FIDONEWS 14-07 Page 6 17 Feb 1997 really must dig them up and post them! We need a solution, The 'new' FTSC-something leaded by R1EC seems too elitist (All this FTSC_PUBLIC echo bollox, get into NET_DEV where the developers are!) A point to ponder... -- _____ _ _ _____ ( __ )(_)-coco-moko-cwewe-modete-escro-(_)( __ ) \/ (_)(_)-loko-noko-lkindnes@csl.co.uk-(_)(_) \/ ----------------------------------------------------------------- FIDONEWS 14-07 Page 7 17 Feb 1997 ================================================================= COLUMNS ================================================================= Fidonet in Europe ----------------- by Dave Meikle (2:259/24.105 , postmaster@rjambo.abel.co.uk) Send info to europe@2:259/24.105 or europe@rjambo.abel.co.uk Nothing much happening apart from THE Zone 2 Fidonet Home page @ http://www.z2.fidonet.org . Dave P.S. TO GET THE LATEST FIDONET IN EUROPE INFO SEND A FIDONET MESSAGE TO infomail@2:259/24.105 with the subject line: Fido-in-europe . ----------------------------------------------------------------- FIDONEWS 14-07 Page 8 17 Feb 1997 ================================================================= GETTING TECHNICAL ================================================================= FSC-0037 Updates: FSC-0025 [This is part of the continuing series of FidoNet Standards and proposals presented as FidoNet History. These docs have been reformatted to 70 columns where required. As always, full text versions are available via the sources listed in the Masthead info at the end of each Issue.] Ed. Pittsburgh, PA 1 May 1989 A V A T A R Advanced Video Attribute Terminal Assembler and Recreator George A. Stanislav Fidonet 1:129/39.0 Information This FSC is being distributed to members of the FidoNet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to FidoNet standards, they may be interesting to implementers. Distribution of this document is unlimited. Revised on 25 November 1989 Definitions Avatar, level 0 - The Avatar protocol as presented at Fidocon '88 and described in AVATAR0.C, dated 23 August 1989, plus extensions defined in this document. AVT/0 - An abbreviation for Avatar, level 0, suggested by Joaquim Homrighausen. Current attribute - Video attribute defined by the last ^V^A, ^V^L, ^V^M or ^L AVT/0 command whichever happened last. In AVT/0, ^L sets the value of current attribute to 3, ^V^L, ^V^M and ^V^A to an explicit value. In addition, ^V^B turns blink on. Extending AVT/0 It has become clear some of the Avatar commands originally reserved for AVT/1 would be very useful in AVT/0. I was hesitant to add them for one simple reason: Any addition on level 0 will break all existing Avatar emulating software. FIDONEWS 14-07 Page 9 17 Feb 1997 However, at present there are only three programs I know of that have implemented Avatar emulation: My own TinyTerm, Joaquim Homrighausen's FrontDoor and Jason Galanter's Jterm. Both Joaquim and Jason have assured me they would put the new commands in their programs, thus nothing will be broken. With that assurance in mind, I feel confident no chaos will result from adding these new commands. New Commands (brief definitions) <^V><^I> - Turn insert mode ON. It stays on until any other AVT/0 command except <^Y> and <^V><^Y> is encountered after which it is turned off; <^V><^J> - scroll area up; <^V><^K> - scroll area down; <^V><^L> - clear area, set attribute; <^V><^M> - initialize area, set attribute; <^V><^N> - delete character, scroll rest of line left; <^V><^Y>[...] - repeat pattern. Detailed Description Insert mode: Insert mode controls the way characters are printed on the screen. Insert mode is always assumed OFF unless explicitly set ON by the ^V^I command after which it stays on until another AVT/0 command except for ^Y or ^V^Y is encountered. Then it reverses back to off. Whenever insert mode is OFF, characters are printed on the screen like this: 1. Print character at current cursor position using current attribute, overwriting whatever was previously displayed at current cursor position; 2. Move cursor to next position, usually one character to the right. At end of the line, move the cursor to next line (possibly scrolling the display or current window if in AVT/1). Whenever insert mode is ON, characters are printed on the screen as follows: 1. Starting at current cursor position and going all the way to the second last character on current line, scroll the text one character to the right; FIDONEWS 14-07 Page 10 17 Feb 1997 2. Discard the character previously at the end of the line, do NOT move it at the beginning of the next line; 3. Print character at current cursor position using current attribute; 4. Move cursor to next position, precisely as in par. 2 of insert mode off. If ^Y or ^V^Y are encountered, the string of characters they compress is first expanded, then treated as an ordinary stream of characters printed according to the above rules. Any other AVT/0 command turns insert mode back off. Please note that in either case the cursor is moved to its next position in an identical manner. The mere fact the cursor is moved to next line, or even scrolls the screen a line up, does NOT turn insert mode off. Only an AVT/0 except as mentioned above can change insert mode on or off. If control characters are a part of the text stream, they are interpreted indentically in insert mode on and off as follows: Carriage return - move cursor at the beginning of the same line; Line feed - move cursor one line down (scroll screen or window [in AVT/1] if necessary), do not change cursor column; Back space - move cursor one position to the left. Do NOT overwrite the character at that position. Do nothing if already at the leftmost position; Tab - move cursor to next tab position without overwriting anything. Tab positions are multiples of 8. Do nothing if already at the rightmost position. A space is treated as a character, not as a control character. Scrolling an area (^V^J and ^V^K): The area defined by its upper, left, lower and right coordinates is scrolled up <^V^J) or down (^V^K) by lines filling the gap with blank spaces using current attribute. If the value of is zero or exceeds the actual number of lines within the scrolled area, the area is filled with blanks using current attribute. These two commands do NOT change the position of the cursor, nor do they define the scrolled area as the default window. The coordinates are relative to the upper left corner of the screen (or current window in AVT/1). The coordinates of upper left corner are 1,1. If a coordinate contains 0, it is to be changed to 1. FIDONEWS 14-07 Page 11 17 Feb 1997 Initializing an area (^V^M): This command contains several steps: 1. Set current attribute to ; 2. Starting at current cursor position (inclusively), ending at current cursor position plus number of and , print at all position inside the defined area. Do not move the cursor. If the number of columns or lines exceeds whatever is available to the right and below current cursor position, truncate the dimensions to fit within the limits of the screen (or current window in AVT/1). Clearing an area (^V^L): This is a shortcut version of the ^V^M command. The character to be used to initialize the area of the screen is assumed to be a blank space. In other words, it sets current attribute and clears an area of the screen starting at current cursor position (which remains unchanged). Please note that the usual 7-bit restriction applies to ^V^L That means that the attribute byte should be anded with 7f hex before applying. If blinking is desired, ^V^B should be used next. On the other hand, requiring to ignore the high bit in ^V^M would make it impossible to fill the area of the screen with a blinking pattern (something I have seen used very creatively by Chris Gaal of PittNet). Therefore, if bit 7 of attr is set in ^V^M, current attribute is set to AND 7f hex and blink is turned on before filling the area with a character. Deleting a character (^V^N): Starting at the column one character to the right of current cursor position all the way to end of the line, scroll the text one character position to the left. This effectively deletes the character at current cursor position. Print a blank space using current attribute at the rightmost end of the line to fill the gap. Do not change current cursor position. If the cursor is at the end of the line, simply overwrite the last character with a blank space using current attribute. Repeat pattern: This is an extension of the ^Y command which allows a group of characters to form a repetititious pattern. determines the number of characters in the pattern, the number of times the pattern is to be printed out. The pattern may contain AVT/0 codes. For example, <^V><^Y><#3>ABC<#4> expands to "ABCABCABCABC". Scrolling Philosophy An important philosophical question has not been answered yet: When scrolling the contents of an area (in the scrolling commands ^V^J and ^V^J, in insert mode ON and in deleting characters ^V^N) should only the text be scrolled and the attribute of the scrolled areas remain where they are or should the attributes move as well. FIDONEWS 14-07 Page 12 17 Feb 1997 A case can be made for either approach. Obviously, the gaps created by scrolling are filled with current attribute, therefore, it seems more logical to scroll the attributes along with the text (else there would be no need to fill the gaps). Thus we follow a consistent principle of video attributes belonging to a character (be it a blank, a digit, or a true character), not to a location. Whenever a character is scrolled to a different location, it takes its attribute along. -30- ----------------------------------------------------------------- Document: FSC-0038 Version: 001 Date: 02/22/90 A Domain Proposal For Fidonet(r) jim nutt 1:114/30@fidonet Information: This FSC suggests a proposed protocol for the FidoNet community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited. A. Rationale A recent proliferation of alternative networks based on Fidonet technology has brought to light the difficulty of maintaining a fully coupled addressing method for Fidonet. Additionally, Fidonet has joined the Internet, revealing a need for a transparent scheme for addressing messages across the networks. It is therefore proposed that a system be established whereby geographical or political sub units of the network can be broken off into an independent network called a "domain". These networks will be fully independent, even to the point of having duplicate net/node numbers or using a different addressing scheme altogether. This will allow continued growth of Fidonet without necessitating that the nodelist grow to an unmanageable size (if it isn't already there). Among the advantages of this type of system are reduced nodelist overhead, easier inter- network communication and greater autonomy of alternative networks. This document will only cover the definition of the necessary addressing extensions to support domain based addressing. It will not attempt to define standards for gating mail and conferences between domains. B. Description It is proposed that domain addressing be implemented in a fashion similar to the current ZONE extended addressing method. Domain names will be case insensitive. The domain extended addressing line will be comprised of a leading SOH (^A, 0x01) followed by the keyword FIDONEWS 14-07 Page 13 17 Feb 1997 "DOMAIN", the destination domain of the message and then the full address (zone:net/node.point) of the destination node in that domain, followed by the source domain of the message and the full address of the originating node. The line will be terminated by a (0x0d) and an optional linefeed (0x0a), fields within the line will be separated by one or more spaces or tabs. i.e. ^ADOMAIN dstdmn daddress srcdmn saddress Where "dstdmn" is the name of the destination domain and "daddress" is the address of the destination system in a format appropriate to the destination domain. "srcdmn" and "saddress" are similar, except that they express the origination address of the message in a format appropriate to the originating domain. This allows a seamless gateway to the Internet and other large system networks. The destination address in the FTS-001 message header should be that of a gateway to the destination domain. C. Summary Domains are independent networks that are fully decoupled from the Fidonet nodelist. Message traffic is passed back and forth between domains via domain gateways that can understand the DOMAIN extended addressing line and act accordingly upon the message. The advantages include reduced nodelist size and easier communication with other networks. -30- ----------------------------------------------------------------- Document: FSC-0039 Version: 04 Date: 29-Sep-90 A Type-2 Packet Extension Proposal Mark A. Howard 1:260/340@FidoNet Status of this document: ------------------------ This FSC suggests a proposed protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. FTS-0001 is a copyrighted work of Randy Bush. Introduction ------------ This document serves two major purposes. The first is an attempt to define and document the Type-2 packet which is widely in use in FidoNet today. Although FTS-0001 defines the structure of a Type-2 packet, the natural evolution of our network, mostly with regards to FIDONEWS 14-07 Page 14 17 Feb 1997 addressing methodology, has made it necessary to utilize hitherto unused portions of the header to insert Zone and Point information. Also, it has become apparent that some of the existing fields are not large enough to accomplish their original tasks. The second is to propose a simple mechanism to allow FidoNet to begin to utilize advanced mail packing techniques. It is quite apparent that while Type-2 has served us faithfully for some time now, the evolution of our network in terms of technical and physical complexity has caused us to consider more efficient and functional ways to pack mail. It should be made clear that with the exception of the Capability Word, Capability Word Validation Copy, ProductCode(hi), and Revision(minor), which are proposed extensions to the Type-2 packet header, this FSC is an attempt to correctly document existing practices with regards to the insertion of zone and point info by at least three mail processors in use today. The Type-2 Header (Where's the Zone?) ------------------------------------- Although FTS-0001 has recently been updated to reflect the use of some of the areas in the packed message header for zone data, at least two other methods for inserting the zone information have been adopted, making it necessary to provide support for both formats in all of the zone aware mail processors. The end result is more code, and redundant information in the packet header. This has presented a problem in logistics, as it is difficult to consider the project of updating mail processors using one type to use the other. As sufficient indentification is provided, in the form of the product code, to determine the expected location of the zone information, and because code already exists in most of the mail processors to overcome this, this proposal does not attempt to suggest that one method be used over the other, rather the intent is to attempt to document the extensions in use, and the products involved. See the accompanying chart and cross-reference. The Product Code ---------------- Based upon the current rate of requests for product codes from the FTSC, it is probable that the Product Code byte will not be large enough to accomodate all of the codes required. While it is not reasonable to expect that all Type-2 processors will eventually check the hi-order byte proposed here, it is likely that 'current' mail processors will. This can be nothing but benefical, as it will force users to upgrade their mail processors to a product which will as a minimum, support Type-2 with Zone and Point extensions, and quite possibly, processors that will utilize more advanced mail packing techniques, making Type-2 extinct once and for all. The Capability Word (How do we GET there from here?) ----------------------------------------------------- Everybody would like to see more efficient and functional ways to FIDONEWS 14-07 Page 15 17 Feb 1997 pack and exchange mail. Several Type-3 message bundle proposals exist, but none really address a problem which must be solved first. The problem is that since FidoNet is a hobbyist network, no demands can be placed on any one sysop to upgrade or change their bundling software. Because of this, it is necessary to consider strategies which allow for the existence of Type-2 bundlers in the network topology. Considerable advantages can be realized, however, between systems that consent to use advanced bundling techniques. One way to do this is to simply send netmail to all of your connecting systems, saying "Hey, I've got a Type-3 bundler now, how about you?" This could become quite tiresome, and does not represent much of an improvement on the current situation. What would be desirable is a network that would 'upgrade itself'. Given a situation where mail processors of various capabilities will exist in a network topology, the goal is to provide a mechanism whereby two links can determine and utilize the most efficient bundling method to use, in a manner transparent to the sysop. For instance, let's say that the FTSC releases the Type-7 All New Singing and Dancing bundle format. Well, your current version of SlingToss can only support Types 2, 3, and 5. One of your downlinks gets a new version of MailMangle which can support Types 2, 3, 4, and 7. Well, it is quite obvious that since you and he are exchanging 4 megs of mail each night, and it's an overseas call, that it would be in your interest to obtain a new version of SlingToss which can support Type 7. Note that this is *optional*. Because both processors can support Type-3, they will continue to exchange Type-3 mail quite happily, even though MailMangle is happily advertising the availability of Type-7. Even your downlinks which are still using stone-age Type-2 processors will be fine, as SlingToss will always export Type-2 bundles when no higher capability can be determined. So, after dashing off the check to the author, your new version of SlingToss comes in the mail! You rush over to your system, and install it. The next time SlingToss exports mail to the MailMangle system, it says "Hey! I can now support Type 2, 3, 5, and 7! So, whattya got?" This is no skin off MailMangle's nose, he's had Type-7 for quite a while, and he begins to export Type-7 bundles to SlingToss. "It's about time.", he says. Now, this scenario is made possible by implementing a 'Capability Word' in the present and future packet headers. The Capability Update mechanism depends on several assumptions: 1) Any Advanced Capability Bundler *MUST* be capable of receiving and faithfully processing Type-2 bundles. Hopefully, the inbound packets will be in the new format proposed by this document, but then again, this is not an exact science. What this means is that it is likely that some packets may arrive with the Capability Word (CW) set to 0. In this case, Type-2 is assumed, assuring compatibility. The only caveat is that it is FIDONEWS 14-07 Page 16 17 Feb 1997 conceivable that some obscure mail processor uses the location proposed for the CW for other arcane purposes. This | can detected through the CWValidation Copy, which is byte-swapped and | compared with the CW at that time. If a mismatch is found, a CW of | type 0 is assumed, and a Type-2 bundling method is used. 2) An Advanced Capability Bundler, hereafter referred to as a Type-N Bundler, must have a method to store and maintain the node-by- node capability information. This can be done many ways, and in fact several processors already have begun to maintain node information outside of that found in AREAS.BBS, mostly to implement pre-arranged alternate compression methods. In a text configuration file, you might see the following: ; Address Comp Send LastCW ; Comments Node 1:260/340 ZIP Auto 7 ; Auto detect & upgrade Node 1:135/20 LZH 3 2,3,7 ; Always send Type-3 Node 1: ARC 2 0 ; Stone-Age processor Node 1:135/4 --- Auto 7 ; Sent me netmail Node 1: --- 0 0 ; Don't send CW In this example, the fields are: Address - downlink address. Note that this is not necessarily relative to echomail, only, it is possible to append information to the node database as netmail packets are receieved from different addresses. Comp - desired mail compression method. Send - Auto - automatically determined maximum common packing method to use. Automatically update to LastCW when packing. LastCW - Last CW received from remote system. 3) A Type-N Bundle will always advertise it's capabilities in the CW regardless of the type being sent. As shown in the above example, it allows Type-N processors to automatically track the capability of your system. Again, in cases where a stone-age processor is being used, this field will be ignored, and in the unusual event that it is not ignored, and is somehow harmful to the far system, the Type-N processor can be configured to send a CW of 0. The format of the Capability Word is designed to support up to 15 future bundle types, and is bit-mapped to facilitate the easy determination of the maximum common level supported between two nodes: msb Capability Word lsb Node Supports ------------FTSC Type Supported---------------- U 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 FIDONEWS 14-07 Page 17 17 Feb 1997 2, 3, and 7 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 2, 3, and 5 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 2 (this FSC) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 Stone Age** 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ^ +--- Indicates UseNet RFC-822 capability ** - a mismatch in the CWValidation Copy also produces a CW=0. In this example, the Type-N bundler would first compare the remote CW | and the byte-swapped remote CWValidation Copy, and check for a mismatch. Prior to the compare, the MSB of the CW's are masked, as this bit is reserved to indicate whether the mail processor is capable of also accepting UseNet RFC-822 bundles. Following the MSB mask, and bit comparison, if they do not match, a remote CW of 0 is assumed. If they match, the Type-N processor would AND the local and remote CW words, obtaining a CW expressing the Types which are in common to both systems. The most significant Type will be used, by default, but note that this assumes that new bundling Types will be increasingly more efficient or in some way more beneficial. Because this may not always be the case, there should be a method provided, as illustrated above, to override the automatic upgrade should this become the case. The MSB of the CW is used to indicate whether the mail processor can accept UseNet RFC-822 bundles or not. It is a separate indicator, and not intended to be used as a part of the above comparison, however can be used to also advertise RFC-822 capability to other systems. Since RFC-822 is 'set in stone', there is no need to assign more than one capability bit. It might seem somewhat limiting to only consider the possibility of 15 different future bundling methods, but it is my opinion that the careful use of a 'Sub-Type' byte in the packet header can allow for the variations on a single theme, and that proposals for new formats should be evaluated by the FTSC to determine whether sufficient benefit can be realized in the implementation of the given format, prior to assigning a new type code. Mailers ------- It is quite clear to me that should this concept take hold, that the logical place to store node capability data is in the local nodelist database, or an index-associated data file. As above, it is necessary to generate Type-2 packets for whatever purpose, unless it is known by prior association, that the far mailer can accept other types of packets. It is also quite reasonable to assume that a nodelist flag could be assigned to advertise the CW for a given node, which the native mailer nodelist compiler could then immediately determine the preferred bundling method for any given node in FidoNet. Another possibility would be to pass a capability advertisement in the extensible portion of a handshake protocol, which may or may not FIDONEWS 14-07 Page 18 17 Feb 1997 already exist in FidoNet. The approach suggested previously in this document suggests the use of a text configuration file, but it is quite obvious that many benefits can be realized through the use of the nodelist, including the use of additional flags to indicate the preferred compression method, etc. Summary ------- This document has been created in an attempt to define a method to allow the future expansion and enhancement of FidoNet technology mail processors and mailers, and in a way that is the least disruptive to existing mail operations. The intent is to provide for an environment that is as open, and extensible as p