F I D O N E W S -- Volume 14, Number 10 10 March 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. | +----------------------------------------------------------------------+ WHO WON THE IC ELECTION? Table of Contents 1. EDITORIAL ................................................ 1 Conspiracy theories for FidoNet? ......................... 1 2. ARTICLES ................................................. 2 The Fido Saga continues .................................. 2 Is a Fidonet Takeover in the works ....................... 2 3. GETTING TECHNICAL ........................................ 4 FSC-0045 - A New Packet Header Format .................... 4 FSC-0046 - Product Identifier for FidoNet Msg Handlers ... 5 FSC-0047 - The ^ASPLIT Kludge Line for Splitting msgs .... 7 FSC-0048 - Proposed Type-2 Packet Extension .............. 11 4. COORDINATORS CORNER ...................................... 20 Nodelist-statistics as seen from Zone-2 for day 066 ...... 20 5. ECHOING .................................................. 21 North American Backbone Echo Changes [Jan-Feb 97] ........ 21 6. NET HUMOR ................................................ 23 Redneck Computer Talk? ................................... 23 7. ADVERTISE YOUR FREE SERVICE/EVENT ........................ 24 Announcing the CRICKET_ECHO .............................. 24 8. NOTICES .................................................. 25 Future History ........................................... 25 9. FIDONET SOFTWARE LISTING ................................. 26 Latest Greatest Software Versions ........................ 26 10. FIDONEWS PUBLIC-KEY ..................................... 32 FidoNews PGP public-key listing .......................... 32 And more! FIDONEWS 14-10 Page 1 10 Mar 1997 ================================================================= EDITORIAL ================================================================= A couple of "FidoNet is going to hell in a handbasket" entries this week. We're half way through the FSC docs this week. Responses are picking up for the FidoNet by Internet list. All listings below the Region level will be found on the FidoNews webpage instead of the weekly listing here. The FidoNews webpage address is in the Masthead information at the end of every Issue. Many thanks to all the ZCs and RCs who passed my request down their respective chains for this information. The Coordinator structure can work. [grin] Otherwise, enjoy! C.B. ----------------------------------------------------------------- FIDONEWS 14-10 Page 2 10 Mar 1997 ================================================================= ARTICLES ================================================================= Subject: The Fido Saga Well, according to the latest nodelist analysis in FidoNews, Fido will be gone sometime next year. Tsk, tsk. If it weren't for all those self-serving, power hungry idiots up at Fido's Mount Olympus, the network wouldn't be facing its demise so quickly. Looks like some things will never change. Maybe you guys should have adopted P5 when you had the chance. Glad I left when I did. Have a Nice Day! David V. Dillard III formerly 1:10/110 formerly 4:92/0 BTW, I thought the discussions we had in the old Region Coordinators echo were pretty interesting. Take care. ----------------------------------------------------------------- Is a Fidonet Takeover in the works by Bob Moravsik 2606/583 Unknown to the masses in Fidonet, there is a subtle but posibble effective plan in the works to take over Fidonet. The method is simple. Gain control of Fidonet's Technical Standard Committee, then start writing policy under the banner of technical standards. An entire administrative system could be created within Fidonet based on the arguement that once a technical standard is approved by the "official committee", "officials" need to be created to implement. A history lesson: In the "old" times there was an attempt to position echomail in such a way that IT would drive Fidonet. An echopol was attempted in Zone one. It was stricken under policy 4.07 section one which prohibits conflicting or restrictive local policies. Z2 is trying the same trick. When this failed a "bop" was written that tried to convince nodes that it was the rules to follow to get echomail. No follow, no echomail. It failed (see Mr. Sorvestre...due process is needed) Not to be stopped by details, we in Zone one got "bopfaq". Another policy dressed as a harmless question and answer file. Never the less. Its quoted as if its policy rather then the ravings of one person (Bruce Bodger) who was admonished when he started kicking around Jason Garcia (a teenager) for over using a software registration trial period. (Decision FIDONEWS 14-10 Page 3 10 Mar 1997 available on request). NOW...we got the FTA files. What are these. Proposals to create a Fidonet Standard Technical Committee. Who can create. YOU GUESSED IT...any "rec". (plus others). This standard committee can be created by people who don't hold any recognized Fidonet position (*ec's are not recognized). The current proposal is flawed. More then one committee can exist . And who's behind it. Yep...the "bopfaq" boy who is now fighting with the RC's. Bruce Bodger through his hat in the ring for the non-ZC election. He desperately wants the job. He wants to "rule" Fidonet. Bodger got NO SUPPORT for the ZC position... his position. He did this to slow down the process. !!! (The ZC is elected by the RC's when there was a vacancy). There was no process although he is trying to create one to maintain his diminishing credability. Bottom line. As you read this. The "boppy boys" are trying to convince the masses that they know how to run Fidonet. Since they can't get their foolishness RATIFIED like Fidonet's policy requires, they do end runs. First there was "echopol".. then "boppy".....then "bopfaq"....now "FTA xxx". The *C's are getting wiser now. Bodger's been thrown out of the *C conference and lurks. What needs to be done is for Bob Satti, the Z1 ZC, to delete all that foolish 1/2XX numbers from the nodelist and have the RC's coordinate all activity in their respective regions as they see fit. Fidonet is NOT echomail. Nodes should not have to jump for the echomail grapes. Backdoor attempts to force a minority's will on the majority should be exposed. Laugh at the FTA documents. Take them for what they are...a pathetic attempt to do what a few can't do via RATIFICATION. Fidonet is a communication media. People have been driven to Internet by this constant attempt to make people "pay" for free communications by OBEDIENCE. Mr. Bodger and small crew are busy in the background. At least know that they are. Mr. Bodger...I'll be more then happy to argue your position in Fidonews. DO IT IN PUBLIC. Stop this incessive lurking in the shawdows. Let's start with your title. Bob Moravsik 2606/583 ----------------------------------------------------------------- FIDONEWS 14-10 Page 4 10 Mar 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of the continuing series of FTSC docs provided as a segment of FidoNet History. These docs have been reformatted to 70 columns as required.] Ed. Document: FSC-0045 Version: 001 Date: 17-Apr-90 A Proposal for A New Packet Header Format Thom Henderson 1:107/542.1@FidoNet April 17, 1990 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. Provisions have been made for storing full five-dimensional addresses (i.e. zone, net, node, point, and domain) in a packed message such that it is possible (albeit somewhat clumsily) to extract a full five dimensional origin and destination for any message. This has not, however, been extended to packet headers. It would be useful for various reasons, such as mail pickpus and password protection of mail links, to be able to quickly and easily extract similar five dimensional addresses from a packet header. This is a proposal for a packet header structure that would make that possible. The proposed packet header structure is as follows: Offset Width Description ====== ===== =========== 0 2 Originating node number 2 2 Destination node number 4 2 * Originating point number 6 2 * Destination point number 8 8 Reserved, must be zero 16 2 Packet sub-version (2) 18 2 Packet version (2) 20 2 Originating network 22 2 Destination network 24 1 Product code 25 1 Product revision level 26 8 Password FIDONEWS 14-10 Page 5 10 Mar 1997 34 2 * Originating zone 36 2 * Destination zone 38 8 * Originating domain 46 8 * Destination domain 54 4 Product specific data 58 --- Start of first packed message * Field only guaranteed accurate in a type 2.2 header All numbers are in decimal. The point of this proposed structure is that it is backwards compatible. All significant fields of a normal type 2 packet header are preserved and are in the same places. The following data fields of a type 2 packet have been discarded and replaced with new informational content: Packet creation date (6 bytes) Packet creation time (6 bytes) Packet baud rate (2 bytes) Reserved for future use (16 bytes) The field formerly occupied by the packet baud rate has been replaced by the packet sub-version number. If this number is set to "2" (an impossible baud rate), then that indicates a type 2.2 packet header, and the fields marked above with an asterisk become valid. If this field contains anything other than a 2, then only the original type 2.0 data may be regarded as accurate. -30- ----------------------------------------------------------------- Document: FSC-0046 Version: 005 Date: 30-Aug-94 A Product Idenfifier for FidoNet Message Handlers Joaquim Homrighausen 2:270/17@fidonet or joho@abs.lu August 30, 1994 Copyright 1994 Joaquim Homrighausen; All rights reserved. Status of this document: This FSC suggests a proposed protocol for the FidoNet(r) FIDONEWS 14-10 Page 6 10 Mar 1997 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. Purpose This document should serve as a guide for the product identfier, PID hereafter, format for FidoNet message handlers. The purpose behind PIDs is related to my attempt to remove the requirement of Origin lines in conference mail messages. While I fully understand that this won't happen in all conferences, I would like to provide the facility to those who can use it (i.e. for conferences where all the participants are using software that supports messages without origin lines). Another use for PIDs is to minimize the excessive amount of information some programs put on the tear lines which increases overall transportation cost and time of conference mail. PID A PID replaces the program identifier often seen on the tear line of conference mail messages and is hidden behind a ^A (ASCII SOH, 01h). This also allows for better tracking of software causing problems in conferences. : Only one PID per message is allowed and should only be added by : the program that creates the message. I.e. programs passing the : message on to someone else may not add additional PIDs. If a PID : is added, no program information may be present after the tear : line. A PID also offers the ability to add serial numbers to identify a specific copy of a program as being the source of a message with little or no effort. Format ^APID: [ ] Sample ^APID: FM 2.11.b Would identify FrontDoor's editor, beta version 2.11 and replace: --- FM 2.11 (beta) Fields pID The ID of the product responsible for creating the FIDONEWS 14-10 Page 7 10 Mar 1997 message. This should be kept as short as possible. The maximum length for this field is 10 characters. version The version of the product including any alpha, beta, or gamma status. Only the relevant part of the version should be included. I.e. 1.00 should be expressed as 1, 1.10 as 1.1 and 1.01 as 1.01. Alpha, beta, or gamma status should be expressed by appending a / or . followed by a, b, or g and optionally a revision indicator, such as a1, b2, etc. The maximum length for this field is 10 characters. serial# The serial number of the product, omitted if irrelevant or zero. The maximum length for this field is ten (10) characters. TID TIDs or "Tosser IDs" started to appear shortly after the first revision of this document was released. They are added by Conference Mail ("EchoMail") processors when a message is exported from the local message base and injected into the network distribution scope for a conference. When a Conference Mail processor adds a TID to a message, it may not add a PID. An existing TID should, however, be replaced. TIDs follow the same format used for PIDs, as explained above. List of products The accompanying file, PIDLIST.TXT, is a list of products known to support the PID proposal. Software authors are encouraged to inform the author of this document of changes and additions to this list. --- end of file "fsc-0046.005" --- -30- ----------------------------------------------------------------- Document: FSC-0047 Version: 001 Date: 28-May-90 The ^ASPLIT Kludge Line For Splitting Large Messages Pat Terry 5:494/4.101 pat.Terry@p101.f4.n494.z5.fidonet.org pterry@m2xenix.psg.org FIDONEWS 14-10 Page 8 10 Mar 1997 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. Objectives =========== Several packers place a limit on the size of message that can be transmitted. This is often of the order of 14K which, while sufficient for most purposes, is inadequate for several applications, and in particular for long messages gated to and from UUCP land. A SPLIT/UNSPLIT suite of two programs has been developed, intended to handle this problem. SPLIT will split long .MSG format messages into smaller packets. After transmission to a remote site, the packets may be merged by UNSPLIT to recreate the original message, as closely as possible. The only differences are the addition of a kludge line and, possibly, a few line breaks. The system ensures that each large message, when split, generates a collection of small messages, each of which is still valid in its own right. If recombination is not effected, the messages will still be usefully received, and, in particular, split messages to UUCP should still all get to their destinations, albeit in parts. After some weeks of testing, the system seems to be sufficiently stable and useful to justify making an FSC proposal. The ^A SPLIT kludge line ======================== Messages split and joined by this system make use of an ^A kludge line, which has the form below. It is proposed in this note that this become the basis for a "standard". One of these lines is added to the list of kludges preceding each part of a split message. When recombined, a line of this form remains, for reasons which will appear later. Generically the lines look like this, in fixed columns: ^ASPLIT: date time @net/node nnnnn pp/xx +++++++++++ where nnnnn gives the original message number from which the components have been derived (cols 41 - 45) pp gives the part number (cols 47 and 48) xx gives the total number of parts (cols 50 and 51) FIDONEWS 14-10 Page 9 10 Mar 1997 For example ^ASPLIT: 30 Mar 90 11:12:34 @494/4 123 02/03 +++++++++++ | | | | | | | | | | @ | | | | | Date Time Node MSG | | Eye catcher (when split) (of origin) (at time | Total parts of split) Part number Thus a large file (existing as 123.MSG when the splitter was run) originating from 494/4 might be split into 3 parts with the split lines ^ASPLIT: 30 Mar 90 11:12:34 @494/4 123 01/03 ++++++++++++ ^ASPLIT: 30 Mar 90 11:12:34 @494/4 123 02/03 ++++++++++++ ^ASPLIT: 30 Mar 90 11:12:34 @494/4 123 03/03 ++++++++++++ Columns 9 through 45 are really a "uniquefier". The nnnnn message number is just the one the message had when it was split, and is of no other significance. Similarly, the system does not use 4-d addressing for the node/net component, because this is of no real interest to this application, and requires parsing a file like BINKLEY.CFG, or similar extra work, to determine the other components. This is, admittedly, verbose, but if recombination fails for any reason (like all the packets not arriving at once) one can still recombine or examine the relevant pieces manually. Note also that the lines are added to messages that are themselves "long", and the *relative* increase in length is actually very small. Further justification will be found below. Splitting large messages ======================== When splitting large messages, the following happens: The message base is scanned for large messages. For each of the (few) large messages found that qualify, the large message is split into parts. The original FTSC header is placed in each component part, save that the FileAttach bit (if any) is removed from the 2nd, 3rd ... parts. No attempt is made to modify the To:, or From: fields. The Subject: field for the 2nd, 3rd ... parts is modified to include a leading part number. The original kludge lines are retained in the first part. Most other "leading" kludges, like ^AFMPT, ^ATOPT, ^AINTL are retained in these parts. However, ^AEID and ^AMSGID lines, if any, are removed from the 2nd, 3rd ... parts. This is potentially awkward, but is to avoid "dupe detectors" discarding the 2nd, 3rd ... parts, and in practice should cause no real problems. Large echomail messages originating on a system will presumably have their ^AEID lines added to the constituent parts at scanning/packing time on that system (ie AFTER splitting), and other large messages should probably not reach this stage - they FIDONEWS 14-10 Page 10 10 Mar 1997 should have been split or discarded earlier. A ^ASPLIT line is added to each part to allow for possible later recombination. If the message is addressed "TO UUCP: in the FTSC header, the To: lines at the start of the message text are copied to all parts. The "body" of the message is then split between the various parts. An attempt is made to split at the end of a line in each case. The trailing tear line, ^AVia ^APath etc lines are added to all parts. Joining ("unsplitting") messages ================================ When reconstituting large messages, the following happens: The message base is scanned for messages with ^ASPLIT lines. A list is made of messages to be unsplit, with each message having a list of its component parts. If a duplicate component part is found, it is discarded (thus partially getting around the problem of any discarded ^AEID lines in the components). Messages marked "in transit" or "sent" are not eligible for recombination. Nor are messages with a split component number of 00, as these will only exist as the result of an earlier recombination. For each set of components of messages to be recombined the following happens: The first component is examined so as to extract the Kludge lines, and any UUCP "To: " lines. These, and the FTSC header, are written out to a new file, with the ^ASPLIT line modified to have a component number of 00, so as to prevent further splitting should the splitter program be reapplied to the recombined message. If this is not done, large messages can get into a tedious split-unsplit- split-unsplit... cycle each time the system is run. The text portions of the first and subsequent parts are then merged (discarding extra copies of kludges, UUCP "To:" lines and the like). Any tearline, Origin, ^APATH, ^AVia lines etc are appended. Normally the component files are then automatically deleted. Justification for "human readable" uniquifier. ============================================== Most systems do not display kludge lines, and the ^ASPLIT line should be of no real interest. However, in one particular application which was using this system, the ^ASPLIT lines were FIDONEWS 14-10 Page 11 10 Mar 1997 made visible for messages that could not be recombined (because they become too large for gating from FidoNet to another RFC-822 compliant network), and hence it has been deemed essential that a "visible" line derived from ^ASPLIT became human readable, easily spotted, and comprehensible. For much the same reason, fixed columns have been used, rather than free format, so that archaic FORTRAN programmers could easily develop "unsplitters" after getting all the pieces! Lastly, in this system a sort was done to order the ^ASPLIT line to be the last kludge line before the message body proper. Acknowledgements ================ Particular thanks must be expressed to Randy Bush for offering to test this system in its earliest releases on the very busy 1/5 zonegate, and for suggesting various improvements. Thanks for testing are also due to Dave Wilson who operates the 5/1 zonegate at the other end of the link from Randy, and to Mike Lawrie of Rhodes Computer Centre for useful suggestions regarding the form of the ^ASPLIT line acceptable to non-Fido users. Prototype system ================ A version of SPLIT/UNSPLIT using this system may be FREQ'd from 1:105/42 or 5:494/4 using the magic name SPLITTER. As at this time I have unsubstantiated reports that it does not work in conjunction with systems running Novell software (I have no access to Novell). It works fine using Msged and QMail. -30- ----------------------------------------------------------------- Document: FSC-0048 Version: 002 Date: 21-Oct-90 A Proposed Type-2 Packet Extension Jan Vroonhof 2:281/1.12@fidonet Oct 21, 1990 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 FIDONEWS 14-10 Page 12 10 Mar 1997 Software. Purpose ======= The final goal of this document is to become a widely used standardised extension to FTS-0001, like FTS-0006, 0007 and 0008 are, and provide an elegant way to switch to a new bundling method without requiring major effort or breaking anything. Prologue ======== The main thing that needs stressing is that the additions covered by this document are FULLY (I repeat FULLY) BACKWARDS COMPATIBLE with FTS-0001 (and other existing standards and practices in FidoNet and WhatEverOtherNets that I know of). When I say "backwards compatible" I mean that problems it would create already exist in the current FTS-0001 system (e.g. zone conflicts when dealing with a non compliant system). In short it only corrects some flaws in FTS-0001 WITHOUT generating new ones. In this document I have tried to stay as much as possible on the paths of existing practices. Therefore I think implementation of the additions it proposes will not be too hard. ! Prologue to revision 2 ! ====================== ! Revision 2 of this document reserves a bit in the ! CapabilityWord for one bundle type already in use outside of ! FidoNet, RFC-822. A small change was made to the "receiving" ! flowchart in order to ensure compatibility with FSC-0039.004. ! In the process a lot of errors and omissions in the spelling, ! credits etc. were corrected. =============== ! All references in the following to FSC-0039 are to Revision 1 ! of that document. My thoughts on FSC-0039 and FTS-0001 rev 12 =========================================== First, revision 12 of FTS-0001 introduced the term "(some impls)" to indicate that some implementations used their own ! extensions to FTS-0001 (Note that in later revisions this was ! changed to "optional"). The problem is that this info cannot be relied upon, because there is no way to actually validate the data. One can only check whether the values of these fields are in the range of valid values and hope for the best. Second, FSC-0039 introduced the idea of having a bitfield FIDONEWS 14-10 Page 13 10 Mar 1997 (called the Capability Word) indicating whether extension data was valid. Through the Capability Word, it also made it possible to indicate the ability to support other, non type 2, packets, thus allowing for flexible migration towards type 3. It also documented the addressing extensions used by various programs. However, FSC-0039 has two flaws: 1. One cannot be sure the bitfield is zero because other implementations might use this field for their own purposes. Therefore this document includes a second validation copy for the Capability Word (CW hereafter). This copy allows the FSC-xxxx compliant software to validate the CW by comparing the two. The chance of some junk portraying itself as a CW is significantly reduced by this. ! Please note that the validation copy is byte swapped ! compared to the normal capability word. While this started ! out as a typo, I decided to leave it in as it introduces ! some extra safety, without requiring much extra code effort. ! In later revisions of FSC-0039, Mark adopted this idea of a ! validation copy too and eliminated the problem. 2. Although FSC-0039 provides a way to make packet headers 4D it is not backwards compatible. It cannot be used in FTS- 0001 sessions to unknown systems, making FidoNet still not totally 4D capable. Although it implements fields for zone and point number, an FTS-0001 compliant application is not required to look at these fields. When a point mails using these fields to implement its 4D address, a system only looking at the net/node info, as is required by FTS-0001, still sees it as a boss node, causing the obvious problems. This document provides a way for transparent point handling, using a technique already exploited by many mailers internally. It will allow this document to be implemented and used by mailers not supporting it. At the same time the danger that a point is seen as the boss node is eliminated. It does NOT provide full inter-zone backwards compatibility, but that is not needed as badly, as problems are not yet too great. Any measures to ensure backwards compatibility in this area might harm communication with non-supporting programs, when the old system could handle the situation. Packet Header ============= The "|" character is used to indicate extensions documented in FTS-0001 revision 12, the ":" character indicates those documented here and in FSC-0039. Offset dec hex .-----------------------------------------------------. FIDONEWS 14-10 Page 14 10 Mar 1997 0 0 | origNode (low order) | origNode (high order) | +--------------------------+--------------------------+ 2 2 | destNode (low order) | destNode (high order) | +--------------------------+--------------------------+ 4 4 | year (low order) | year (high order) | +--------------------------+--------------------------+ 6 6 | month (low order) | month (high order) | +--------------------------+--------------------------+ 8 8 | day (low order) | day (high order) | +--------------------------+--------------------------+ 10 A | hour (low order) | hour (high order) | +--------------------------+--------------------------+ 12 C | minute (low order) | minute (high order) | +--------------------------+--------------------------+ 14 E | second (low order) | second (high order) | +--------------------------+--------------------------+ 16 10 | baud (low order) | baud (high order) | +--------------------------+--------------------------+ 18 12 | 0 | 2 | 0 | 0 | +--------------------------+--------------------------+ 20 14 | origNet (low order) | origNet (high order) | : | Set to -1 if from point | +--------------------------+--------------------------+ 22 16 | destNet (low order) | destNet (high order) | +--------------------------+--------------------------+ | 24 18 | ProductCode (low order) | Revision (major) | | +--------------------------+--------------------------+ | 26 1A | password | | | 8 bytes, null padded | | +--------------------------+--------------------------+ |: 34 22 | origZone (low order) | origZone (high order) | } | +--------------------------+--------------------------+ } As in |: 36 24 | destZone (low order) | destZone (high order) | } QMail : +--------------------------+--------------------------+ : 38 26 | AuxNet (low order) | AuxNet (high order) | : +--------------------------+--------------------------+ : 40 28 | CWvalidationCopy (high) | CWvalidationCopy (low) | : +--------------------------+--------------------------+ : 42 2A | ProductCode (high order) | Revision (minor) | : +--------------------------+--------------------------+ : 44 2C | CapabilWord (low order) | CapabilWord (high order) | : +--------------------------+--------------------------+ : 46 2E | origZone (low order) | origZone (high order) | } : +--------------------------+--------------------------+ } As in : 48 30 | destZone (low order) | destZone (high order) | } FD etc : +--------------------------+--------------------------+ : 50 32 | origPoint (low order) | origPoint (high order) | } : +--------------------------+--------------------------+ } As in FIDONEWS 14-10 Page 15 10 Mar 1997 : 52 34 | destPoint (low order) | destPoint (high order) | } FD etc : +--------------------------+--------------------------+ : 54 46 | Product Specific Data | : + + : | 4 Bytes | +--------------------------+--------------------------+ 58 3A | zero or more | ~ packed ~ | messages | +--------------------------+--------------------------+ | 0 | 0 | 0 | 0 | '-----------------------------------------------------' Packet = PacketHeader { PakdMessage } 00H 00H PacketHeader = origNode (* of packet, not of messages in packet *) destNode (* of packet, not of messages in packet *) year (* of packet creation, e.g. 1986 *) month (* of packet creation, 0-11 for Jan- Dec *) day (* of packet creation, 1-31 *) hour (* of packet creation, 0-23 *) minute (* of packet creation, 0-59 *) second (* of packet creation, 0-59 *) baud (* max baud rate of orig and dest *) PacketType (* old type-1 packets now obsolete *) origNet (* of packet, not of messages in packet set to -1 if orig=point *) destNet (* of packet, not of messages in packet *) + productCode Lo (* 0 for Fido, write to FTSC for others *) |+ serialNo Maj (* binary serial number (otherwise null) *) | password (* session pasword (otherwise null) *) | origZone (* zone of pkt sender (otherwise null) *) | destZone (* zone of pkt receiver (otherwise null) *) | auxNet (* contains Orignet if Origin is a point *) +! Bytesw. CWvalidationCopy (* Must be equal to CW to be valid *) FIDONEWS 14-10 Page 16 10 Mar 1997 + ProductCode Hi + revision Minor + origZone (* zone of pkt sender (otherwise null) *) + destZone (* zone of pkt receiver (otherwise null) *) + ProdData (* Product specific filler *) When the two copies of the CW match they can be asumed to be valid and used. Stone-Aged: Old FTS-0001 Type-2+ : Old FTS-0001 plus changes indicated by "|" and ":" are valid A Type-N Bundle will always advertise its capabilities in the CW regardless of the type being sent. As shown in the example below, the CW 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+ 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 Doc) 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 ! ^-- "U" Indicates nodes able to process RFC-822 ! bundles. ** - In the example bit definitions only type 2, and the Stone-Age type, are defined now. The rest are to be concidered "reserved by FTSC". The receiving Type-N bundler would AND the two words, obtaining a word expressing the Types which are common to both the receiving and the sending system. The most significant Type will be used for future sessions, by default. Please 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 to override the automatic upgrade, as illustrated above, should this ever happen. FIDONEWS 14-10 Page 17 10 Mar 1997 ! N.B. The one bit left over (Msb) is now used as indicator for ! RFC-822 type bundles. For info on RFC-822 please check out ! the relevant documents themselves. ! For a more explanatory text on using the CW to its full ! potential, refer to the FSC-0039 text by Mark Howard. ! Mark also gives some more rationale for the origional idea ! of the CW. Generating Type-2+ bundles ========================== Do we have a CW Does CW indicate stored for dest? YES ----> higher packets YES ---> Generate higher NO we support? packet | NO \|/ | +-----<----------------------+ | Fill header with all info | \|/ | Are we sending from a point? (origPoint != 0) YES --+ | | NO | | \|/ | set AuxNet = OrigNet \|/ set OrigNet = -1 | | +-----<--- -------------------------------------+ | Add Messages | Terminate packet | Send packet Receiving Type-2+ bundles ========================= Receive Packet | Packettype = 2 NO -------------> Process Type-Other YES | | CWcopies match NO --------+------> Treat as normal Stone-Age packet YES | | | | | Store CW /|\ | | | /|\ CW is 0 YES --------------+ | NO | FIDONEWS 14-10 Page 18 10 Mar 1997 | | | | CW indicates support for 2+ NO --+ YES | | ! OrigPoint is not 0 and OrigNet = -1 YES -------+ NO | | \|/ ! \|/ Set OrigNet is AuxNet | | +------<------ -----------------------------+ | Process using added info Credits ======= To Mark Howard, for introducing the idea of a CW in his FSC- 0039 document and quite rightly pointing out one big omision in revision 1 of this document. To Rick Moore, for doing a good job in processing all these revisions by Mark and myself, and for his work for the FTSC in general. To Joaquim Homrighausen, for his contributions to FidoNet software in general, and especially for his time devoted to reading, discussing and implementing the ideas Mark and I introduced. To Andre van de Wijdeven, for producing and letting me beta test his TS-MM software, which in my opinion is the best poi