F I D O N E W S -- Volume 14, Number 4 27 January 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. | +----------------------------------------------------------------------+ HAPPY BIRTHDAY PERI HORNER! Table of Contents 1. EDITORIAL ................................................ 1 SuperBowl edition? ....................................... 1 2. ARTICLES ................................................. 2 The PALMTOPS Echo ........................................ 2 3. GETTING TECHNICAL ........................................ 3 FSC-0024 - Proposal for a Type-3 Mail Bundle ............. 3 FSC-0025 - AVATAR information ............................ 16 4. COORDINATORS CORNER ...................................... 23 Nodelist-statistics as seen from Zone-2 for day 024 ...... 23 5. WE GET EMAIL ............................................. 24 ACLU Cyber-Liberties Update .............................. 24 6. NET HUMOR ................................................ 29 Geekonics - the next step? ............................... 29 7. WANTED ................................................... 32 Looking for Mr. Surveyed equipment? ...................... 32 8. NOTICES .................................................. 33 Future History ........................................... 33 Update on the WebRing status for FidoNet World Wide Web .. 34 9. FIDONET SOFTWARE LISTING ................................. 36 Latest Greatest Software Versions ........................ 36 10. FIDONEWS PUBLIC-KEY ..................................... 43 FidoNews PGP public-key listing .......................... 43 11. FIDONET BY INTERNET ..................................... 44 12. FIDONEWS INFORMATION .................................... 46 FIDONEWS 14-04 Page 1 27 Jan 1997 ================================================================= EDITORIAL ================================================================= Just a little bit early in compilation so I can watch those Packers do unto the Patriots what they did unto my Jaguars! [snicker] [Football for your non-Zone 1 folks.] The WebRing server is still in transition. Those of you still trying to link your webpages to the FidoNet webring please note the notice at the end of this Issue. I will advise all when they get it back up. I got an inquiry from a fellow in Denmark [who seems to have written a FidoNet to Internet mail/file handling utility for Windows95] about writing an article for FidoNews detailing his invention. I told him to go ahead and send me one. In the meantime, if you want to look at his effort [it's 19 pounds sterling], his site is at: http://www.terminate.com/fido2int.htm Other than those, it's been a slow week here at FidoNews. Still no new ASCII art or .BIOs. [sigh] Go Packers! [grin] C.B. ----------------------------------------------------------------- FIDONEWS 14-04 Page 2 27 Jan 1997 ================================================================= ARTICLES ================================================================= The PALMTOPS ECHO by Jim Henry, 1:273/408, jim@airgunhq.com The PALMTOPS echo is a new echo I started for users of various Palmtop computers, such as but not limited the HP 100LX and HP 200LX. What IS a Palmtop? More than just an electronic organizer, a Palmtop is a real PC no larger than a video cassette, and most are considerably smaller. The HP Palmtops fit easily into a shirt pocket and are loaded with built in software, such as Lotus 1-2-3, an appt. scheduler, phone book, word processor, telecommunications, scientific calculator, Quicken, and more. Then you can add even more software depending on what your needs are. Among the other software I have added, is a ballistics program I can use at the range, and 1ST Reader, the combination terminal program and Qwkmail reader from Sparkware. Using 1st Reader on my Palmtop, I have been able to reclaim what other-wise would be lost or un-productive time. I can catch up on my email when stuck in the waiting room at my car dealer, or doctor's office. Beats the heck out of reading 6 month old magazines! Waiting in the car to pick up my kids after school is another opportunity to read and reply to mail on my Palmtop. The PALMTOPS echo is not yet on the backbone, but please do join us and help make it happen. Pick up a feed from me at 1:273/408, or Jim Balcom at 1:109/334. One final warning: Palmtops are addictive! ----------------------------------------------------------------- FIDONEWS 14-04 Page 3 27 Jan 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of a continuing project of re-publishing all the FidoNet Technical Standards and Proposals in numerical order. It is also part of the FidoNet History series begun by this Editor. Documents have been reformatted to the 70 column limit where required and some tables may be distorted as a result. Anyone wishing unmodified forms should file-request the actual file.] Ed. FSC-0024 - A Proposal for a Type-3 Mail Bundle - Oliver McDonald Notes on Type three bundlers. The first important note is that without Wynn Wagner's work on FTSC-0014, none of this would have come to fruition. I owe him a great debt in this area, as well as the debt for Opus itself that got me into this. Thanks Wynn. Type 3 bundlers offer opportunities for new levels of sophistication in mail processing. As the first step Aurora Computer Technologies plans to provide the minimum specified by the existing Type 3 bundle specifications with one minor addition. This addition is the inclusion of the features of ReMapper. This addition is not a required inclusion for other software authors producing a Type 3 bundler. To sum up, standard required features are: Must be able to create and unbundle Type 2 Bundles (See FSC-0001) Must be able to create and unbundle Type 3 Bundles (See attached) Must be able to Toss EchoMail from either Type 2 OR 3 bundles Must generate an update-required message for the sysop if the MinorVersion changes. Must generate an update-required message if it encounters a misc packet type it does not recognize. Initial optional features are: May Duplicate the functionality of ReMapper. May automatically generate an F.Req. from source of bundle when the minor version changes. May generate an F.Req from source of bundle if it encounters a misc packet type it does not recognize. All error messages are placed in Matrix Mail messages to the Sysop. Will create outbound bundles on the fly from the inbound FIDONEWS 14-04 Page 4 27 Jan 1997 bundle. Does not need to scan these messages. Note, if this option is exercised it is IMPERATIVE that the areas are scanned prior to the unbundle process. Type 3.0 proposal (preliminary) This proposal allows for automatic updating of the Type 3 bundle to allow for further revisions and enhancements. Thus we will refer to it as a Type 3.0 with further versions becoming Type 3.1 etc. All multi-byte data forms (int/long) are considered to have the MSB first and the LSB last. Int is two bytes, and Long is four. Bundle Header struct _BundleHeader { struct _Address B_Destination; struct _Address B_Origination; unsigned nybble B_BundlerVersionMajor; unsigned nybble B_BundlerVersionMinor; unsigned byte B_ProductCode; unsigned byte B_VersionMinor; unsigned byte B_VersionMajor; unsigned long B_CreationTime; unsigned byte B_Password[8]; }; Bundle Header Notes This works out to 32 bytes which is a nice size to work with. Here follows a short explanation for each field: "B_BundlerVersionMajor/Minor" provide for version numbers from 0.0 to 16.16, this should be enough for all except TJ. "B_ProductCode" is the FTSC assigned product code. This can be used to identify just which type 3 bundler created the bundle; it should not be considered an error if this is unidentified, and need not be processed on unbundling but MUST be included _correctly_ at the bundling stage. "B_VersionMinor" is a version number that will initially start at Zero and is used to allow non backward compatible changes to Type 3 bundles, such as header length change. If this is LOWER in the bundle than the corresponding version number in the unbundler it should abend. It is suggested that a short message be written to the Sysop in NETMAIL with as much information gleaned from the header as possible. (All info up to and including "B_VersionMajor".) FIDONEWS 14-04 Page 5 27 Jan 1997 "B_VersionMajor", always 3. This and all data prior to this point is position dependant and will never be changed in future Type 3.0 bundle revisions. "B_CreationTime" is an Unix 1970 based creation time indicating the time/date the bundle was created. "B_Password" is a NULL padded character array that may contain uppercase alpha bytes or ASCII digits. It should not contain lowercase characters, punctuation, control characters etc. A maximum of 8 characters are significant. Struct _Address struct _Address { unsigned int Zone; unsigned int Net; unsigned int Node; unsigned int Point; }; struct _AddressShort { unsigned int Net; unsigned int Node; }; Bundle Footer Struct _BundleEnd { Unsigned Byte E_Packet_Type /* Always 0 * / }; Bundle Footer notes. All bundles end with this packet. It is not optional and the packet should be considered grundged if it is missing. Area header Struct _AreaHeader Unsigned byte E_Packet_Type /* Always 1 */ Unsigned byte E_NameLength /* Actual bytes in E_NAME */ Unsigned Byte E_Name[1] /* Variable length field */ Area Header Notes The area header packet marks the start of a sequence of messages destined to the same message area. The area indicated in the Area Header will remain valid until either the end of the bundle OR another Area Header is FIDONEWS 14-04 Page 6 27 Jan 1997 encountered. E_Name will usually contain the area name of the echo area that subsequent messages should go. If E_NameLength is zero then the subsequent messages should go the NetMail area. Any messages that occur prior to the first Area Header in a bundle should also go to the Netmail area. The Maximum value for E_NameLength is 63. E_Name is NOT null terminated. Message Header Struct _MessageHeader {