F I D O N E W S -- Volume 13, Number 53 30 December 1996 +----------------------------+-----------------------------------------+ | 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 NEW YEAR! AN EXTRA FIDONEWS ISSUE THIS YEAR! Table of Contents 1. EDITORIAL ................................................ 1 End of the Volume 13 year ................................ 1 2. COLUMNS .................................................. 2 FIDONET IN EUROPE ........................................ 2 3. FIDONET BIOGRAPHIES ...................................... 3 Joe Klemmer, 1:109/370, a .BIO finally! .................. 3 4. GETTING TECHNICAL ........................................ 5 FSC-0004 - Zones & ZoneGates explained ................... 5 FSC-0005 - Opus passwording explained .................... 6 FSC-0007 - Message Format Specification .................. 10 5. COORDINATORS CORNER ...................................... 17 Nodelist-statistics as seen from Zone-2 for day 362 ...... 17 6. WE GET EMAIL ............................................. 18 FCC information .......................................... 18 7. NET HUMOR ................................................ 22 End of the year laugh? ................................... 22 8. COMIX IN ASCII ........................................... 24 Keep watching the skies! ................................. 24 9. ADVERTISE YOUR FREE SERVICE/EVENT ........................ 27 Announcing the CRICKET_ECHO .............................. 27 Announcing the WRESTLING_CHAT Echo ....................... 27 10. NOTICES ................................................. 28 Future History ........................................... 28 11. FIDONET SOFTWARE LISTING ................................ 29 And more! FIDONEWS 13-53 Page 1 30 Dec 1996 ================================================================= EDITORIAL ================================================================= We get an extra Issue this year since we're still in 1996 for this last Issue. Is that luck or design? [snicker] The complete year is available here as: FNEWS13.ZIP at about 700K compressed. It also contains the complete Table of Contents for 1996 by Issue in chronological order. The complete year is also available on the FidoNews webpage at: http://ddi.digital.net/~cbaker84/fidonews.html and will be available at the other archive sources listed in the Masthead at the end of every Issue. ARTSPEC.DOC has been revised again. The new version has been hatched into the FIDONEWS file echo and into the SDS area SOFTDIST as ARTSPEC.ZIP. It will be published in full in Issue 1401 next week. The only change is the addition of a new filetype for submissions. It is called: .INT for FidoNet sources via the Internet. A new Section appears in this Issue just before the Masthead. It contains Internet addresses for Administrative links and for Zone, Region, and Net homepages. It will appear every week with accumulated info. Submissions of independent info using the .INT file extension will also be written to the new Section. The listed sites are also available from the FidoNews webpage [see above address]. To date, only Zone 1 sites are known and listed. I invite all other Zones, Regions, and Nets to submit their site addresses for listing via Netmail, email, or .INT submission. This doesn't mean FidoNet is being taken over by the Internet. It's just another way to communicate and for many it's much cheaper for files and docs. FidoNet IS part of the Internet after all. [grin] It's been a good year for FidoNews with your help and submissions. So keep them coming! We even have our FIRST .BIO submission this week! I hope it starts a trend and encourages the rest of you lurkers to get out of that closet. [Thanks, Joe!] Starting in Volume 14, Issue 01, the FidoNews PGP public-key will begin appearing again barring any injunction from the ZCC. A majority of ZCs responding to my direct Netmail have no problem with its inclusion in FidoNews. Tom Jennings certainly has no problem with it. Happy New Year to all! C.B. ----------------------------------------------------------------- FIDONEWS 13-53 Page 2 30 Dec 1996 ================================================================= COLUMNS ================================================================= Fidonet In Europe ----------------- by Dave Meikle ( NOTE NEW NET ADDRESS : 2:259/24.105) Sorry about last week , I was getting my new net address do you forgive me ? :-) Nothing happened anyway :-( Newz just in: THE (UN)OFFICAL DALKEITH THISTLE F.C. Web PAGE. http://members.aol.com/rebeljambo/thistle Thats all folks. Dave ----------------------------------------------------------------- FIDONEWS 13-53 Page 3 30 Dec 1996 ================================================================= FIDONET BIOGRAPHIES ================================================================= Joe Klemmer 1:109/370 I was born on November 12th, 1962 in Bremerhaven of what was then known as West Germany. My father was a teacher for the DoD Depend Schools over there. I grew up bouncing back and forth between the U.S., mostly PA and DE, and Germany until 1976. That summer we moved to Kaiserslautern where I attended the American High School there. I was one of three people who went all four years at the school, such is the life of the Overseas Brat. After graduating HS in 1980 I "attempted" collage but, well, let's just say I wasn't cut out for a prolonged academic career. My first "real" job was as a U.S. Government Civilian (GS) computer operator on an old IBM 4331 mainframe. This is where I got my initial exposure to what is now referred to at the "Cyberworld". I spent the next 8 years working at many jobs including a dish washer, truck driver, teacher, more computer operator, football coach, rock guitarist (paying job doing clubs), still more computer operator and other things I can't remember. In July of 1988 we moved to the Washington DC area where I got a job as. . . No, it wasn't a computer operator. It was a 7-11 clerk! That lasted about a month till I COULD find a job as a computer operator. :-) This was with also a GS job and it was here that I first met my future wife, Joy. After a year and a half of stalking. . . uh, "wooing" her, we were married on July 28th, 1990. During this time I fell into a job as a GS computer programmer. I was still working on mainframe systems, this time an IBM 3090 running MVS, and my primary work was in COBOL-85. Now, after I got married and we got a place of our own, I found that I needed a computer to access the system at work. I got a 386sx-16 with 40meg HD, 2meg RAM and a 2400bps modem. Hot stuff in late '90, huh? Anyway, I'd heard about BBS's and such so I figured I'd try some out, since I had the modem and all. Well that got me hooked and, OC, it wasn't long before I fired up my own BBS. It was called "My UnKnown BBS" and came up around November of '91. After a little while I started to get interested in message networks so I joined (actually I helped create) a QWK net that is now known as the World Message Exchange or WME. By now I'd met a number of other Sysops, some of whom were in Fidonet. I started to look into Fido and, to make a long story short [too late!], in Nov '92 I got a node number of 1:109/370 thanks to Dave Aronson and Bruce Feist. About this time I had also started to notice some discomfort in my hands and a slight numbing of the fingertips but didn't think it was anything. So, now I'm in Fido. What's one of the first things to do when you're in? Dump over 55,000 dupes onto the backbone in a 3 hour FIDONEWS 13-53 Page 4 30 Dec 1996 period. Needless to say I made many friends at this point, not the least of which was the NEC for Net-109. After finding the problem (bad software) and getting it fixed (long story for some other venue) I was allowed to carry echos again. Since I'd been in such a close working relationship with the NEC for about a year, I volunteered to become a backbone hub now that I had a stable setup. I was still running the BBS and it had become slightly popular but the discomfort I'd been feeling in my hands had now become unbearable. In the spring of '94, I was diagnosed with CTS and had to go in for surgery on both hands. At this point I'd been pretty much unable to maintain the BBS so I shut it down but kept on as a Fido hub. The surgery worked and, for a brief time, I had regained 99% of the use of my hands. It was the fall of that year that the current NC decided it was time to step down so, being the big mouth. . . uh, Active Citizen that I am, I stepped in and was elected NC for Net-109. OC, since I was running unopposed this wasn't much of a surprise. Not long after that my hands had started to bother me again. Luckily as NC I didn't need them for much typing. A good NC should be virtually invisible to the net he's in. If an NC is sending lots of "admin" messages he's not doing his job right. The problem with my hands turned out to be something different. It's called Myofacial Pain Syndrome and is a musculature disorder that has made my left hand/arm nearly useless and greatly reduced the use of my right. Because of this, by the beginning of 1996 I'd been thinking about stepping down as NC. This decision was reinforced when, to our great surprise, Joy became pregnant with our first child. In September, I stepped down as NC. During this time my "real" job has moved into the world of the Web. I built and maintain a site for the Army Publications & Printing Command and am learning a LOT about perl and java on the fly. Additionally, we had the best Christmas present ever this year; our son was born at 1:12 a.m. on Dec 16th. Between him and the web stuff, I don't think I'll ever get to run a BBS again but. . . I _AM_ still running a major Backbone hub, though, and will continue in Fidonet for as long as I have a system and a phone line. --- The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny . . ." -- Isaac Asimov -30- ----------------------------------------------------------------- FIDONEWS 13-53 Page 5 30 Dec 1996 ================================================================= GETTING TECHNICAL ================================================================= [This is part of our continuing series of FidoNet Technical Proposals. This Issue contains three FSCs since they were small. They have been reformatted to 70 columns where required.] Ed. FSC-0004 Date: Mon 9 Feb 87 21:46 From: Randy Bush on 105/6, PSG Portland of VanPort Area, Portland OR To: Wynn Wagner on 124/108, The POLE: Opu of Dallas Metrop, Dallas TX Subj: Re: Zones The FSC has been working with existing implementations based on a year or two old paper by Kilgore Trout describing Zones and Points, zone gates, and nodes supporting points. [ The paper was published in FidoNews last year, but unfortunately was mostly to do with exploiting FidoNet financially, but had pretty good technical requirements buried underneath. ] The FSC's goal is to send to some place for which one does not have the nodelist. The underlying problem we are addressing is nodelist growth. We envision over 10^5 nodes in a few years. Our approach may be a bit more disjoint than you were considering. We have private nodelists already, and many of us use them (including remapping to private nodelists using Points and/or addressees' names). This has been in use for long enough that we almost understand half the uses to which folk seem to put it. But the important part of Zones is not the nomenclature, rather the mapping of addresses. What the FSC was seeking with Zones (and is implemented and being tested) is a method of getting mail to Bialystok (sp) without having a Polish phone book. In the following example, please imagine possible sugar such as using POLAND for 42 etc. When I, 1:105/6 address a message to Krzystzof in Bialystok, 42:451/666, it addresses the message header to and creates a ^a line something like ^aINTL 42:451/666 1:105/6 The ^aINTL line is noticed by a smart router at either my node, or my outbound host's node. To date the only ways to create the ^aINTL line are SEAdog's Mail program and some private utilities. Either in a batch run on the smart node (currently implemented by the program ZoneGate) or in a truely smart mailer program (not yet known) the smart router changes the destination net/node of the message containing the ^aINTL to the outbound gateway to (or toward) zone 42 by a simple algorithm shown below. Thus, the message will travel within zone 1 (this zone) as if its final destination was the net/node FIDONEWS 13-53 Page 6 30 Dec 1996 of the outbound gate. This allows Opera and Fidos 11w to carry it on its meanderings within any particular zone. When it arrives at the destination outbound zone gate, the smart router there notices it, and o may strip the seenbys (we had thought of it but not yet implemented it) except for that of the zonegate o hands the message to the corresponding inbound zone gate by an unspecified means (intl zone gates tend to be other than FidoNet) The recipient inbound zone gate looks at the message's ^aINTL line and, using the same algorithm as all the other smart routers that have seen the message, (* I hope you were waiting for the algorithm *) IF msg.aINTL.toZone = myzone THEN msg.address := msg.aINTL.toNetNode ELSE msg.address := outboundZoneGate [ msg.aINTL.toZone ] And thus the message travels onward, with its header address net/node representing it's intra-zone routing within the current zone and the ^aINTL line showing smart routers the true final destination. Observe that smart routers and zone gates only need know the local addresses of the outbound zone gates from their own zone's nodelist, and nothing about the nodelists of other zones. One imagines the truely international FidoNet having more than 10^5 nodes, with Opera and Fidos and other pre-Zone clones will carrying the international traffic on its way within a zone in complete innocence. The return address for the message is also stored in the ^aINTL line, so a 'smart' recipient node can reply. Rather than trading private nodelists, the only information that needs to be given to smart routers is the addresses of zone gates out of the current zone. And, of course anybody can set up Zones, zone gates, and all those nice egalitarian sentiments, all they need is a simple mapping utility and a way of telling folk that they're a zone gate and to what. There are some who consider a Unix gate merely a zone gate. Usenet certainly is another zone. -30- ----------------------------------------------------------------- FSC-0005 The Opus Computer-Based Conversation System FIDONEWS 13-53 Page 7 30 Dec 1996 (c) Copyright 1987, Wynn Wagner III, All Rights Reserved OPUS-CBCS Matrix Password Methods MATRIX PASSWORDS USED BY OPUS ----------------------------- Opus uses two kinds of passwords for matrix sessions: SESSION LEVEL access code is roughly the same sort of thing as a user's password. It is passed from one system to another during the session negotiation sequence (aka YooHoo) and is in effect for the entire matrix session. TRANSACTION LEVEL passwords are valid only for WaZOO "ZedZap" style file requests. They are a way to protect requestable material on a file-by- file basis. MATRIX PASSWORDS USED BY OTHER SYSTEMS ------------------------------------------ It is possible that Opus will be sensitive to passwords produced by other netmail software. Because other password methods have not been documented or their behavior publicly explained, the compatibility between Opus and non-WaZOO systems isn't assured. Apparently the behavior of some other methods involves protection against unauthorized "pickup" of material that is on hold. You can make a case that Opus does this as well. Opus uses a true session-level protection scheme. Unauthorized pickup is avoided in that the remote system will find itself without a carrier. Within a couple of days of the scheduled release of Opus 1.00, we discovered a change in the implementation of some "bark" style file request programs. The change was made to the method of exchange the name of the file being requested and apparently offers some kind of transaction-level password. There was no attempt to include this change in Opus 1.00. PASSWORDS --------- FIDONEWS 13-53 Page 8 30 Dec 1996 A password consists of 4 to 6 characters or numbers and is case insensitive. The password cannot contain white space, control codes, or punctuation (except an underscore). Valid characters for passwords are "a".."z", "A".."Z", "0".."9", "_" SETTING UP A SESSION LEVEL PROTECTION SYSTEM -------------------------------------------- UPFRONT ------- Both sides of a password protected session use the same access code. My system's password on your system is your password on my system. OPUSNODE -------- The OPUSnode program (by Wes Cowley) has facilities for dealing with Opus-compatible passwords beginning with version 1.4.4. STORING PASSWORDS ----------------- This is fairly technical information about the storage of matrix passwords. There are plans to change the structure of the node list file (NODELIST.SYS), and the new structure has room for a 6- character password. That's in the future. For the present, we have to have some place to store the password. This kludge is about as temporary as they come. The correct way to handle passwords is to have a structure that can handle them. The current node list structure has no such field. It does, however, have an extra-ordinarily amount of space to hold the CITY. The CITY in the NodeList.Sys file is 40 characters. If you want to put a session level password in the node list file, you can do so. NORMAL CITY: ccccccccccccccccccnnnnnnnnnnnnnnn PASSWORDED CITY: ccccccccccccccccccn!ppppppnnnnnnn c = city information n = null (ascii zero) ! = exclamation point (or "=") FIDONEWS 13-53 Page 9 30 Dec 1996 p = password information In other words, to put a password into the node list CITY record, follow the city with a null and an exclamation point and a null-terminated password. An equals sign can appear instead of an exclamation point. This has a special meaning to ECHO GUARD (see below). METHOD ------ The session level password is used during the YooHoo negotiation. If there is a problem, Opus will drop carrier on the caller and make a "*" type log entry. As a confidence factor, successful passwords will be logged with a tracer ("#") style entry. SETTING UP A TRANSACTION LEVEL PROTECTION SYSTEM ------------------------------------------------ Transaction level passwords only work with WaZOO "ZedZap" style file requests. ORIGINATING SYSTEM ------------------ The REQUESTING system puts the required transaction level access code into its REQ file. EXAMPLE: NEATFILE.ARC !mypass_x SYSTEM WITH REQUESTED FILES --------------------------- The REQUESTED system has passwords in its `OkFile.' EXAMPLE: c:\files\neat*.arc !mypass_x NOTE: Password protected files will not be available to non-WaZOO file requesters. There is no known method for having an access code in the "BARK" style file request, so Opus just pretends it doesn't have the file available if such a request comes in. ECHOGUARD --------- FIDONEWS 13-53 Page 10 30 Dec 1996 IMPORTANT: As with the rest of Opus, there is no guarantee that anything will work as documented. Because EchoGuard is a security feature, this fact needs to be stressed... THERE IS NO ASSURANCE THAT ECHOGUARD WILL OFFER YOU ANY KIND OF PROTECTION. EchoGuard is a method to trap many attempts "unauthorized" echomail attempts. There is an undocumented control file switch for this: ECHO Guard If this switch is set, Opus will mark many unauthorized messages so they won't be scanned and sent to other systems. EchoGuard does NOT prevent the message(s) in an unauthorized bundle from being tossed. Opus assumes bundles from password-protected systems have already passed the access code test. If it finds a "=" instead of a "!" in the NodeList.Sys file where the password would go, it treats the packet as though it were approved. In other words, you can use EchoGuard even though you exchange echomail with some non-WaZOO systems. For the WaZOO systems, use a "!" and password in NodeList.Sys. For the non WaZOO systems, use a "=" character. The equals sign tells the ECHO GUARD routine that the system in question is not capable of handling session level passwords. Unauthorized messages sent to echomail areas will be flagged as "Sent" and "Orphan" to keep other scan programs from sending them to anybody else. ### -30- ----------------------------------------------------------------- Document: FSC-0007 Version: 002 Date: 17-Apr-90 FidoNet(r) RFC822-Style Message Format (Informal Proposed Message Format Specification - Draft, revised) Robert Heller @ 1:321/153.0 April 17, 1990 FIDONEWS 13-53 Page 11 30 Dec 1996 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. 1. Purpose. =========== The purpose of this document is to outline my ideas concerning FidoNet (r) message format, both as stored on disk as message files handled by BBS (or other "conferencing" programs) and as these messages exist packed into "bundles" or "packets" as transmitted from machine to machine. I think using a uniform format for normal message storage will make things easier, at least in terms of "standardized" message bundling and transmiting software is concerned. If done right it also makes things easier for BBS and conferencing software writers too. This specification is only a first draft proposal. Just something to put on the table for discussion. Feel free to comment on it. I am open to suggestions. 2. Preliminary Definitions. =========================== I will be using BNF notation to describe the format of data fields. This is a fairly standard notation and should be familar to anyone who has taken a compiler design course. To make things a little briefer, I will be using some pre-defined psuedo-terminal symbols. These symbols are defined as: o The symbol ALPHA referes to any ASCII alphabetic character, including the uppercase letters ('A' thru 'Z', 41H thru 5AH), the lowercase letters ('a' thru 'z', 61H thru 7AH) and these characters: '#' (23H), '$' (24H), '&' (26H), '*' (2AH), '+' (2BH), '-' (2DH), '=' (3DH), '^' (5EH), and '_' (5FH). o The symbol DIGIT refers to any of the ASCII characters '0' thru '9' (30H thru 39H). | o The symbol NEWLINE refers to the single ASCII character LF (0AH), | when the message is in transit, and refers to the local O/S's | newline convention for text files (i.e. LF under UNIX, CRLF under | MS-DOS and CP/M, CR under OS-9, etc.), or whatever is convient | for the BBS software. o The symbol WHITESPACE refers to one or more ASCII space (20H) or tab (09H) characters. o The symbol OPTWHITESPACE referes to zero or more ASCII space (20H) or tab (09H) characters. FIDONEWS 13-53 Page 12 30 Dec 1996 o The symbol TEXT referes to zero or more printable ASCII characters not including a NEWLINE sequence. o The symbol NULL referes to the null string (no characters at all). Oh, one other thing: message files contain only printable ASCII characters and NEWLINE sequences (packed messages will have non- printable bytes). Also, I'll number the definations. I am also only using six BNF operator characters: a vertical bar (|) for alteration, braces ({}) for comments, single quotes (') for character and string literals and parens (()) for expression grouping. 3. Definations 1: Stored Message. ================================= Changed or added definations are indicated by an '*' after the def number. The goal symbol is "". { A message consists of a header followed followed by a NEWLINE followed by a message body. } ::=
NEWLINE {Def 1.1} { A message body is just unbounded text. } ::=NULL | (TEXT NEWLINE ) {Def 1.2} { A header is more complicated: There are a series of header line types. }
::= NULL | ( NEWLINE
) {Def 1.3} * { This syntax defines the posiblity of a null header - this needs to be checked for by sematic routines, since it makes no sense. } ::=|||| |||| |||| | {Def 1.4} * { Now for the header line formats themselves. Some notes: certain header lines are required (, , and ), and some can only occur once (, , , and ). Except for these restrictions, most header lines can either be omited or can occur more than once. } ::='To: '
{Def 1.5} ::='From: '
{Def 1.6}
::= OPTWHITESPACE '@' OPTWHITESPACE {Def 1.7} ::= ALPHA {Def 1.8} ::= (ALPHA | DIGIT | WHITESPACE | NULL) {Def 1.9} { Note: this is the full blown FidoNet node address - includes optional zone and point numbers. It does not include the "domain". I am not sure about this - I think more discussion on the whole idea of "domains" and "zones" is needed. My feeling is we should look into a symbolic addressing system, simular to what the InterNet uses. } FIDONEWS 13-53 Page 13 30 Dec 1996 ::= (( ':') | NULL) {zone} '/' {basic net/node} (('.' ) | NULL) {point} {Def 1.10} ::= DIGIT | (DIGIT ) {Def 1.11} ::='Date: ' {Def 1.12} { Here it is: my idea for a *standard* date string } { day-of-week month date, year hour:minute AM/PM time-zone } { Although not specified, hours and minutes are zero padded to two digits. The date and year are not padded at all.} ::= ' ' ' ' ', ' ' ' ':' ((' ' | NULL) {Def 1.13} ::= 'Mon" | 'Tue' | 'Wed' | 'Thu' | 'Fri' | 'Sat' | 'Sun' {Def 1.14} ::= 'Jan' | 'Feb' | 'Mar' | 'Apr' | 'May' | 'Jun' | 'Jul' | 'Aug' | 'Sep' | 'Oct' | 'Nov' | 'Dec' {Def 1.15} { If the AM/PM indicator is missing (null), the hours field is assumed to in 24-hour format (i.e. 00 to 23) } ::= 'AM' | 'PM' | NULL {Def 1.16} { This field is optional. It makes sense given that FidoNet is international. } ::= ALPHA | (ALPHA ) {Def 1.17} ::=('Subject: ' | 'Subject (Private): ') TEXT {Def 1.18} ::='Cost: ' (('.' ) | NULL) {Def 1.19} { This is tricky, given the internationalness of FidoNet(r). I guess it isn't critical. } ::= '$' | '#' | NULL {Def 1.20} ::= 'Via: ' ', ' {Def 1.21} ::= NULL | (' ' TEXT) {Def 1.22} ::= 'Processed-by: ' TEXT {Def 1.22.1} * { This replaces the 'tear' line. } ::= 'Origin: ' TEXT '(' ')' {Def 1.23} * ::= 'Area: ' {Def 1.24} { I'm leaving the question of all caps for the area name open: other than ease of comparision, is it neccessary to be all caps? } ::= ALPHA | (ALPHA ) {Def 1.25} ::= 'Seen-By: ' {Def 1.26} * ::= | ( ) {Def 1.27} * ::= (( ':') | NULL) (( '/') | NULL) ( | NULL) (('.' ) | NULL) {Def 1.28} * { This is also open-ended. Should there be a standard format for this? The syntax here is somewhat ambigious - it allows for certain bogus forms. It needs sematic routines to handle these forms (raise an error or whatever). Writing the grammer to avoid these problems would add complexity not needed at this level. } ::= 'Path: ' {Def 1.28.1} * ::= 'Message-id: ' ' ' {Def 1.29} * FIDONEWS 13-53 Page 14 30 Dec 1996 { This is the syntax proposed by Jim Nutt } ::= {8 hex digits} {Def 1.29.1} * { I've left out a proper grammer rule or token for a hexidecimal number. } ::= 'Attributes: ' {Def 1.30} ::= | ( ', ' ){Def 1.31} { This is probably not complete, but...} ::='Kill Sent' | 'File Attached' | 'File Request' | 'Sent' | 'Crash' | 'Audit' {Def 1.32} { Maybe we should forget about an 'Attributes: ' header tag and instead have a collection of additional header tags to handle each posible attibute - i.e. 'File-Attached: ', 'File-Request: ', 'Sent: ', etc. header lines. } ::= ': ' (TEXT | NULL) {Def 1.33} { This is the expandsion hook. } ::= ALPHA {Def 1.34} ::=NULL | ((ALPHA | WHITESPACE | DIGIT | ) {Def 1.35} { This is also open-ended. Restriction: colon (:) cannot be allowed! } ::='(' | ')' | '.' | ',' | ';' {Def 1.36} 4. Packed Message Format. ========================= A packed message is simply a regular message with some binary header (i.e. an "envelope") info and a NUL (00H) byte after the message text: Offset dec hex .-----------------------------------------------. 0 0 | 0 | 3 | 0 | 0 | +-----------------------+-----------------------+ 2 2 | origZone (low order) | origZone (high order) | +-----------------------+-----------------------+ 4 4 | origNet (low order) | origNet (high order) | +-----------------------+-----------------------+ 6 8 | origNode (low order) | origNode (high order) | +-----------------------+-----------------------+ 8 8 | origPoint (low order) | origPoint (high order)| +-----------------------+-----------------------+ 10 A | destZone (low order) | destZone (high order) | +-----------------------+-----------------------+ 12 C | destNet (low order) | destNet (high order) | +-----------------------+-----------------------+ 14 E | destNode (low order) | destNode (high order) | +-----------------------+-----------------------+ 16 10 | destPoint (low order) | destPoint (high order)| +-----------------------+-----------------------+ 18 12 | Attribute (low order) | Attribute (high order)| +-----------------------+-----------------------+ 20 14 | message text (includes ASCII header) | ~ unbounded ~ FIDONEWS 13-53 Page 15 30 Dec 1996 | null terminated | `-----------------------------------------------' Some notes: I've included both the Zone and Point addresses in the packed message headers. This does not really affect things like routing and point mapping. The packets themselves have addressing info in their headers (as described in FSC001). The addressing in the packet header - this addressing is used by the transmitting programs. The internal addressing info is processed by re-packing programs - that is programs which peel routed messages (messages that are "just passing through") and re-packet them for later re-transmitsion to another node during a future mail event. Messages destined for the current node (one whose address exactly matches all four destination address words), get extracted from the packet and stored in the message base. Note that only the ASCII message text is stored. The binary header is discarded at this point. 5. Conclusions. =============== It is my idea that FidoNet(r) is going to sooner or later going need some of the extendablity provided by this sort of message format. If fact it allready needs some of these fields, and has been "faking it" for some time now: things like EchoMail ("Area: ", "Origin: ", "Seen- By: ", and "Path: " header lines), points and zones (extra addressing hacks), uucp gatewaying (more extra addressing hacks), routing ("Via: " header lines). Going to a RFC822-style message format also helps to increase the varity of BBS and conferencing software - this will help improve the "state of the art" in this regard. Also, using a RFC822- style message format allows indefinite extensablity - as new ideas regarding messages and conferencing develope, the message format can be easily extended to handle these new ideas with ease. 6. Contact Info. ================ Comments, suggestions, gripes, etc. can be sent to me at any of these addresses: ARPANet: Heller@CS.UMass.Edu BITNET: Heller@UMass.BitNet Genie: RHELLER BIX: lockshill.bbs CompuServe: 71450,3432 FidoNet Robert Heller @ 1:321/153.0 USMail: HC82 Box 29 LH1, Locks Hill Road, Wendell, MA 01379 Voice Phone: Home: 617-544-6933, Work: 413-545-0528 Data Phone: 617-544-8337 at 300, 1200, or 2400 BAUD 24hours, except during FidoNet(r) mail periods. 7. More Information. ==================== I have written a set of EchoMail processing using a message format FIDONEWS 13-53 Page 16 30 Dec 1996 described in this document. The code is in C and is freely available for evalation. If you would like a copy, let me know and I will get a copy to you. I developed the code under OS-9/68000, but the code should easily port to other platforms. -30- ----------------------------------------------------------------- FIDONEWS 13-53 Page 17 30 Dec 1996 ================================================================= COORDINATORS CORNER ================================================================= Nodelist-statistics as seen from Zone-2 for day 362 By Ward Dossche, 2:292/854 ZC/2 +----+------+------------+------------+------------+------------+--+ |Zone|Nl-334|Nodelist-341|Nodelist-348|Nodelist-355|Nodelist-362|%%| +----+------+------------+------------+------------+------------+--+ | 1 | 10931|10931 0 |10737 -194 |10564 -173 |10452 -112 |36| | 2 | 16240|16185 -55 |16150 -35 |16127 -23 |16104 -23 |55| | 3 | 886| 882 -4 | 882 0 | 878 -4 | 876 -2 | 3| | 4 | 584| 578 -6 | 572 -6 | 413 -159 | 556 143 | 2| | 5 | 94| 94 0 | 94 0 | 93 -1 | 93 0 | 0| | 6 | 1008| 1006 -2 | 1003 -3 | 1003 0 | 1075 72 | 4| +----+------+------------+------------+------------+------------+--+ | 29743|29676 -67 |29438 -238 |29078 -360 |29156 78 | +------+------------+------------+------------+------------+ ----------------------------------------------------------------- FIDONEWS 13-53 Page 18 30 Dec 1996 ================================================================= WE GET EMAIL ================================================================= --- Following message extracted from FIDONEWS @ 1:18/14 --- By Christopher Baker on Thu Dec 26 15:37:56 1996 From: Mike Bilow To: Christopher Baker Date: 26 Dec 96 02:15:12 Subj: FCC fines LDSI/LDS for "slamming" * Forwarded (from: NESYSOP) by Mike Bilow using BilowMail0.2. * Originally from Mike Bilow (1:323/107) to All. * Original dated: Dec 26 '96, 02:10 This is an official FCC news release which may be of importance to some Fidonet sysops if they have had dealings with the companies concerned. -- Mike xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx NEWSReport No. CC 96-21 COMMON CARRIER ACTION December 17, 1996 COMMON CARRIER BUREAU FINDS TWO COMPANIES APPARENTLY LIABLE FOR FORFEITURE FOR SLAMMING Today the Common Carrier Bureau issued two Notices of Apparent Liability ("NALs") for alleged violations of the Commission's "slamming" rules. The Bureau's action was directed at two companies, Long Distance Services, Inc. (LDSI) and a separate entity with the same name located in Michigan, Long Distance Services, Inc., (LDS, Inc.). The Bureau found each company liable for forfeiture penalties for violating Commission rules and orders concerning changes to consumers' long distance carriers. Under Commission rules, changes in a consumers long distance service by another long distance carrier must be confirmed by a document known as a Letter of Agency ("LOA"), which is signed by the customer to authorize the change. The Bureau noted that if carriers rely on LOA's to change a consumer's long distance service that the carrier must ensure that the authorization has been validated by the consumer. The Bureau's action against LDSI today generated from consumers who alleged that they did not authorize changing their long distance service to LDSI. Based on an investigation by the Enforcement Division, the Bureau found no similarities between the signature on the LOA authorizing the changes and the signature on the consumer complaint submitted to the Commission. The Bureau assessed a forfeiture of $80,000 for the violations. In the case involving LDS, Inc., the Bureau received two FIDONEWS 13-53 Page 19 30 Dec 1996 complainants from consumers who alleged that they did not authorize a change in service to LDS, Inc. The Bureau found in the first case that the LOA authorizing the change in long distance service used by LDS, Inc. did not bear a valid signature or address. A second consumer admitted to entering a raffle by completing an entry form to win a prize, but claimed that he did not sign an LOA to authorize a change in his long distance service. The Bureau found that the LOA in question violated Commission rules regarding proper LOA form and content. The Bureau issued an NAL for $40,000 for the unauthorized conversion and $40,000 for the violation of proper LOA form and content, for a total of $80,000. In both actions announced today, the Common Carrier Bureau found that each carrier in question apparently violated the Commission's "slamming" rules by substituting itself as the long distance carrier for a consumer without that consumer's authorization. The practice of changing a consumer's long distance carrier without authorization is commonly known as "slamming." Last year, the Commission implemented new rules to better protect consumers from the practice of "slamming". The Common Carrier Bureau's Enforcement Division investigates consumer complaints and takes action against responsible carriers. Actions by the Chief, Common Carrier Bureau, December 17, 1996, by Notices of Apparent Liability (DA 96-2101, DA 96-2102). -FCC- News media contact: Jodie Buenning (202)418-1500 Common Carrier Bureau contact: Kathie Kneff at (202) 632-7553 or Kaylene Shannon at (202) 418-0960. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --- Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/HST16.8 (1:323/107) --- Following message extracted from FIDONEWS @ 1:18/14 --- By Christopher Baker on Thu Dec 26 15:38:12 1996 From: Mike Bilow To: Christopher Baker Date: 26 Dec 96 03:23:06 Subj: ISPs to be charged IEXC access fees? * Forwarded (from: NESYSOP) by Mike Bilow using BilowMail0.2. * Originally from Mike Bilow (1:323/107) to All. * Original dated: Dec 26 '96, 03:22 Mike Bilow wrote in a message to Mike Bilow: MB> See: MB> Linkname: CNNfn - FCC dials up reform of local-access fees - MB> Dec. 24, 1996 MB> URL: http://cnnfn.com/hotstories/companies/wires/9612/24/fcc_wg/ FIDONEWS 13-53 Page 20 30 Dec 1996 MB> According to a minor comment at the end of the story, the MB> FCC is now asking for public comment on whether ISPs should MB> be treated like long distance companies for purposes of MB> local access fee charges. The FCC has posted a news release on this subject at http://www.fcc.gov/Bureaus/Common_Carrier/News_Releases/nrcc6088.txt and the full text in both ASCII and WordPerfect 5.1 for Windows formats at http://www.fcc.gov/Bureaus/Common_Carrier/Notices/fcc96488.txt http://www.fcc.gov/Bureaus/Common_Carrier/Notices/fcc96488.wp The FCC seems quite cautious, if not outright terrified, realizing that messing with the Internet too much could kill it. In fact, the FCC very much seems to understand the real problem: 288. We tentatively conclude that information service providers should not be required to pay interstate access charges as currently constituted. As we have explained throughout this Notice, the existing access charge system includes non-cost-based rates and inefficient rate structures. We see no reason to extend this regime to an additional class of users, especially given the potentially detrimental effects on the growth of the still-evolving information services industry. Although our original decision in 1983 to treat ESPs as end users rather than carriers was explained as a temporary exemption, we tentatively conclude that the current pricing structure should not be changed so long as the existing access charge system remains in place. The mere fact that providers of information services use incumbent LEC networks to receive calls from their customers does not mean that such providers should be subject to an interstate regulatory system designed for circuit-switched interexchange voice telephony. We seek comment on this tentative conclusion. Comments in response to the inquiry are due February 21, 1997 and reply comments are due March 24, 1997. The FCC will accept informal filings by Internet e-mail; see http://www.fcc.gov/isp.html for instructions. Internet e-mail filings must contain the proper caption code in the subject line, in this case "CC Docket No. 96-263." The full official caption for the Notice of Inquiry is "Usage of the Public Switched Network by Information Service and Internet Access Providers, Common Carrier Bureau Docket No. 96-263." -- Mike --- Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/HST16.8 (1:323/107) FIDONEWS 13-53 Page 21 30 Dec 1996 -30- ----------------------------------------------------------------- FIDONEWS 13-53 Page 22 30 Dec 1996 ================================================================= NET HUMOR ================================================================= From: "Mike Riddle" To: "Baker, Christopher" Subject: Fwd: An end of the year laugh ==================BEGIN FORWARDED MESSAGE================== >From: rsd381 >To: solosez@abanet.org >Subject: An end of the year laugh I saw this while surfing. Even though this is not law related we all are entitled to a laugh once in a while. Ten Things That Would Be Different if Microsoft Started Building Cars. 1: A particular model year of car wouldn't be available until after that year instead of before it. 2: Every time they repainted the lines on the road, you'd have to buy a new car. 3: Occasionally, your car would just die for no reason, and you'd have to restart it. For some strange reason, you'd just accept this. 4: You could only have one person in the car at a time, unless you bought a Car 95 or Car NT. But then you'd have to buy more seats. 5: Sun Motorsystems would make a car that was powered by the sun, was twice as reliable, and five times as fast - but it would only run on 5 percent of the roads. 6: The oil, engine, gas, and alternator warning lights would be replaced by a single "General Car Fault" warning light. 7: People would get excited about "new" features in Microsoft cars, forgetting completely that they had been available in other cars for years. 8: We'd all have to switch to Microsoft gas. 9: The U.S. government would be getting subsidies from an automaker, instead of giving them. 10: New seats would force everyone to have the same size butt. Robert Daniels FIDONEWS 13-53 Page 23 30 Dec 1996 rsd381@sgi.net ===================END FORWARDED MESSAGE=================== ----------------------------------------------------------------- FIDONEWS 13-53 Page 24 30 Dec 1996 ================================================================= COMIX IN ASCII ================================================================= From: kay.shapero@salata.com (Kay Shapero) Date: 17 Dec 96 21:54:14 -0800 Subject: ASCII art Organization: An Internet Gateway To: cbaker84@digital.net You were asking about ascii art for FidoNews... :-> The following is the record of a little zap war conducted between yours truly and Keith Glass. I don't know who originally drew the Klingon Cruiser; the Shadow BattleCrab is Keith's, the rest mine. I led off with: _ _|_|_ ^/ . ..\^ ___[=========]___ ___-==++""" . /. . . \ . """++==-___ __-+"" __\ .. . . | .. . | . . . /__ ""+-__ /\__+-"" `-----=====\_ _/=====-----' ""-+__/\ _/_/ ""="" \_\_ /_/ \_\ // | \\ /") \ | / ("\ \o\ \*/ /o/ \_) --**O**-- (_/ /*\ / | \ | Ahem... Keith countered with: / / / _- / / # / _- ####/ _____/ ######### ##########--___ ########## ########## @ / ######| @ / / | |@ / / | |@ / / | | FIDONEWS 13-53 Page 25 30 Dec 1996 @ @ \# @ #/ > \@/ _ > _|_|_ > ^/ . ..\^ > ___[=========]___ > ___-==++""" . /. . . \ . """++==-___ > __-+"" __\ .. . . | .. . | . . . /__ ""+-__ > /\__+-"" `-----=====\_ _/=====-----' ""-+__/\ > _/_/ ""="" \_\_ > /_/ /@\ \_\ > // /#@#\ \\ > /") /##@##\ ("\ > \o\ @ /o/ > \_) @ (_/ And I responded with.... \ / \ / \ / _- _\ PSSST!!!!! / / \ \ # / _- \ \--| /.................................####/ _____/ \____/ /.....................................######### ! !=============================================##########--__ _( )_ \........................########## | / \ \...................... ########## ! ! / ######| ! R ! / / | ! ! / / | ! A ! / / | ! ! ! I ! ! ! ! D ! ! ! \-----/ When last seen, things had degenerated into words, and a hail of custard pies as contributed by yours truly: __ __ __ __ --- ! \ --- ! \ --- ! \ --- ! \ --- ! ! --- ! ! --- ! ! --- ! ! --- !_/ --- !_/ --- !_/ --- !_/ SPLATSPLATSPLATSPLAT!! __ __ __ __ / ! --- / ! --- / ! --- / ! --- ! ! --- ! ! --- ! ! --- ! ! --- \_! --- \_! --- \_! --- \_! --- FIDONEWS 13-53 Page 26 30 Dec 1996 !!TALPSTALPSTALPSTALPS If anything else of interest emerges from the front I'll let you know... :-> -30- ----------------------------------------------------------------- FIDONEWS 13-53 Page 27 30 Dec 1996 ================================================================= ADVERTISE YOUR FREE SERVICE/EVENT ================================================================= Emanuel Edwards 1:348/963 emanuel@pangea.ca Hello all Cricket Lovers: This ad is to inform you that there is a cricket echo now on fidonet. The echo tag is called CRICKET_ECHO. The cricket_echo describe all aspects on how the game is played, the latest scores and upcoming tours and events in the cricket world. Please request the cricket_echo onto your bbs. Thanks Emanuel Moderator. ----------------------------------------------------------------- Emanuel Edwards 1:348/963 emanuel@pangea.ca Hello all Wrestling Fans: This ad is to inform you that there is a new wrestling echo on the fidonet backbone. The echo tag is called WRESTLING_CHAT. This echo is a free speech wrestling echo. It gives all the latest rumours of what's going on in the wrestling world, upcoming matches and events in the wrestling world. Please request the WRESTLING_CHAT onto your bbs. Thanks Emanuel Moderator. ----------------------------------------------------------------- FIDONEWS 13-53 Page 28 30 Dec 1996 ================================================================= NOTICES ================================================================= Future History 26 Jan 1997 Australia Day, Australia. 6 Feb 1997 Waitangi Day, New Zealand. 16 Feb 1997 Eleventh Anniversary of invention of Echomail by Jeff Rush. 29 Feb 1997 Nothing will happen on this day. 25 May 1997 Independence Day, Argentina 11 Jun 1997 Independence Day, Russia 1 Dec 1998 Fifteenth Anniversary of release of Fido version 1 by Tom Jennings. 31 Dec 1999 Hogmanay, Scotland. The New Year that can't be missed. 15 Sep 2000 Sydney (Australia) Summer Olympiad opens. -- If YOU have something which you would like to see in this Future History, please send a note to the FidoNews Editor. ----------------------------------------------------------------- FIDONEWS 13-53 Page 29