F I D O N E W S -- Volume 13, Number 45 4 November 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. | +----------------------------------------------------------------------+ HEADLINE CONTEST! SEND YOUR ENTRIES NOW! Table of Contents 1. EDITORIAL ................................................ 1 A long Issue but a good start ............................ 1 2. ARTICLES ................................................. 2 A Short *.MSG Programming Tutorial [III] ................. 2 Read Read Read ........................................... 8 The FTSC Charter? ........................................ 11 FTSC Comments ............................................ 13 Trias Politica and FidoNet ............................... 14 Are we talking about the same net? ....................... 16 3. COLUMNS .................................................. 18 Fidonet in Europe ........................................ 18 4. GETTING TECHNICAL ........................................ 19 FTS/FSC Master List ...................................... 19 FTS-0001 - The Basic FidoNet Standard for Operation ...... 21 5. COORDINATORS CORNER ...................................... 48 Nodelist-statistics as seen from Zone-2 for day 306 ...... 48 6. NET HUMOR ................................................ 49 Who are Computer people? ................................. 49 7. NOTICES .................................................. 51 Future History ........................................... 51 8. FIDONET SOFTWARE LISTING ................................. 52 Latest Greatest Software Versions ........................ 52 9. FIDONEWS PUBLIC-KEY ...................................... 59 This Space intentionally left blank? ..................... 59 And more! FIDONEWS 13-45 Page 1 4 Nov 1996 ================================================================= EDITORIAL ================================================================= This Issue is long as I begin to publish the FTSC files on a weekly basis. The first one is FTS-0001 which specifies all the basic parameters for a FidoNet mail and file exchange session along with the message packet structure. In converting the original 80 column document to MAKENEWS' 70 column limit, the large tables became scrambled. They can be unscrambled if you send that section to an 80 column file or simpler yet, freq the original from here or from the source. Also included in this first effort is a complete list of all the FTS and FSC docs extant to my knowledge. All of the ones not marked *Obsolete* are available from the sources listed in the Masthead for FidoNews as well as here or from the FTSC Chairman's system at 3:632/348 in Australia. Please consider FTS-0001 as this week's FidoNet History entry, too. A complete archive containing every doc listed further down is available here by the magicname of: FTSC or FTSC-ALL. Individual files are available here as listed. At the source [in Zone 3], the files may have alphanumeric designations so you might want to use an * for the file extensions if freqing from 'down under'. C.B. ----------------------------------------------------------------- FIDONEWS 13-45 Page 2 4 Nov 1996 ================================================================= ARTICLES ================================================================= A Short *.MSG Programming Tutorial [III] Damian Walker, 2:2502/666 In this last article of the *.MSG programming series I'll introduce some important issues about writing message files, and I'll also include the full source code for the message list program discussed in the previous two articles. Writing *.MSG Files Somewhere in FTS-1 it is mentioned that life is not a one-way street. Perhaps this is an odd observation to be found in a technical specification document, but it did provide me with a timely reminder that this tutorial should include something on writing messages as well as reading them. Most of the processes involved in writing a message should be reasonably obvious, being the opposite of reading. Instead of reading a message and extracting addressing information and text, you build up the header and the text before writing to a file. There are some extra considerations to be taken into account, however. The first is that of message numbering-- there must be some way to find out what number a new message should bear. This is not an issue when rewriting an old message (to change its attributes, for instance), but it is essential that new messages should not overwrite existing ones, and it can be reasonably important in certain applications that the message is numerically the highest. The following simple section of code can find out the next available message number: long findnextavail(char *filename, char *directory) { long nextavail, current; struct ffblk f; int done; char wildcard[128]; nextavail = 1; sprintf(wildcard, "%s*.msg", directory); done = findfirst(wildcard, &f, FA_ARCH); while(!done) { current = atol(f.ff_name); if(current >= nextavail) nextavail = current + 1; done = findnext(&f); } sprintf(filename, "%s%ld.MSG", directory, nextavail); return nextavail; } FIDONEWS 13-45 Page 3 4 Nov 1996 When the while loop is finished, 'nextavail' will contain the next available message number, which be returned to the calling process. I've also chosen to return the message number as a full *.MSG path and filename since this is more consistent with the examples used so far; a more elegant function would do one or the other. It is not always advisable to include this code in a generic write routine, since such a routine may also be needed to rewrite existing messages. This is why I've included it in a separate function findnextavail(), which will return the information to a calling process which can then go on to pass the message number to the generic write routine. Values must be placed in the message header fields, and kludges must be prepared for extended addressing information, before the message is actually written out. This information is more often than not prepared before the next available message number is sought. Not all fields need to be filled with meaningful data; some should preferably be used properly but are a little too advanced for this tutorial. For example: timesread int/2 Times read Can often be zeroed. Also, cost int/2 Cost word could be zeroed unless you wish to include message accounting in your program. And then consider: destzone int/2 Recipient's zone number origzone int/2 Sender's zone number destpoint int/2 Recipient's point number origpoint int/2 Sender's point number Since these fields are not reliable, they are not actually used by software when reading messages. Personally I fill them anyway, as a generic message write routine can take values placed in here to form the kludges which are actually used for the purpose of 4D addressing. replyto int/2 Reply linking information This field can often be zeroed or ignored, as can: nextreply int/2 Next reply to this message since they appear to be useful only in echomail, and most people store echomail in more advanced message bases than a *.MSG directory. All the other fields are mandatory, and the way they are filled really is application dependent, just as the way they are used after reading is also application dependent. The difference is that few of the fields can be ignored when writing; you have to at least zero most of the fields mentioned above so that their contents are not mistaken for real values. As a simple example, let's imagine that I want to create an automatic robot message such as the following: ================================================================ FIDONEWS 13-45 Page 4 4 Nov 1996 By: Automatic Robot, 2:2502/666.3 To: Damian Walker, 2:2502/666.0 Re: Netmail reminder St: Pvt Local ---------------------------------------------------------------- This is your netmail reminder ================================================================ This message could be typical of one generated by a netmail reminder program or appointments calendar, an idea I had for my newly found netmail programming skills, which I never took up. Rather than use such a program as context for C code, I'll cheat and generate the message directly in the following program excerpt: #include #include #include "fidomsg.h" #define MAXMSGSIZE 2048 void main(void) { struct fts1 msg; char text[MAXMSGSIZE]; strcpy(msg.fromusername, "Automatic Robot"); msg.origzone = 2; msg.orignet = 2502; msg.orignode = 666; msg.origpoint = 3; strcpy(msg.tousername, "Damian Walker"); msg.destzone = 2; msg.destnet = 2502; msg.destnode = 666; msg.destpoint = 0; strcpy(msg.subject, "Netmail reminder"); msg.attribute = MSGPVT | MSGLOCAL; strcpy(text, "This is your netmail reminder\r"); msg.timesread = 0; msg.cost = 0; msg.replyto = 0; msg.nextreply = 0; /* post message */ } In this example I have filled in the zone and point fields, in order that the generic post routine can pick these up and use them to generate the INTL, FMPT and TOPT kludges. Notice also the fact that I've zeroed four of the fields I'm not really interested in. I've left the date/timestamp generating code for the generic write function, although you can see that I've included the header in readiness. So let's see what such a generic write function would look like: int writemsg(struct fts1 *msg, char *text, char *filename) FIDONEWS 13-45 Page 5 4 Nov 1996 { FILE *msgfile; /* message file handle info */ int successful = 0; time_t timer; msgfile = fopen(filename, "wb"); if(msgfile != NULL) { time(&timer); strftime(msg.datetime, 20, "%d %b %y %H:%M:%S", localtime(&timer)); fwrite(msg, sizeof(struct fts1), 1, msgfile); if(msg.origzone != msg.destzone) fprintf(msgfile, "\01INTL %d:%d/%d %d:%d/%d\r", msg.destzone, msg.destnet, msg.destnode, msg.origzone, msg.orignet, msg.orignode); if(msg.origpoint != 0) fprintf(msgfile, "\01FMPT %d\r", msg.origpoint); if(msg.destpoint != 0) fprintf(msgfile, "\01TOPT %d\r", msg.destpoint); fprintf("%s\0", text); fclose(msgfile); successful = 1; } return successful; } Notice the order of operation. First the message file is opened. If the open is successful, the timestamp is generated in standard Fidonet date/time format as described earlier, before the header file is written. Then the INTL kludge is written if the origin and destination zones differ. Then the FMPT and TOPT are written as required. Finally, the rest of the message text is added before the file is closed. This code does not include the MSGID kludge which netmail messages so often have now. The MSGID kludge is in the form: ^AMSGID: zone:net/node.point xxxxxxxx where the xxxxxxxx is a 32-bit number. Generation of this number is left to the implementation, but it must be as unique as possible. Some programs generate a completely random MSGID, but this runs the risk of identical MSGID's on two messages. When restricting your programming to netmail this isn't too much of a problem, since MSGID's are primarily intended for dupe checking and there is no dupe checking in netmail. However, you may wish to experiment with more advanced algorithms for ensuring unique message identifiers, perhaps including the timestamp as a factor in the calculation. Final Message Lister The code in this tutorial has been pieced together, but never shown in its final form. For convenience, I've included the full final message lister below. I've taken the liberty of adding a few more comments to FIDONEWS 13-45 Page 6 4 Nov 1996 this listing, in order to make the complete program more easy to follow. ====================================================================== FIDOMSG.H ---------------------------------------------------------------------- /* FTS-1 message structure */ struct fts1 { char fromusername[36], tousername[36], subject[72], datetime[20]; int timesread, destnode, orignode, cost, orignet, destnet, destzone, origzone, destpoint, origpoint, replyto, attribute, nextreply; }; #define MSGPVT 0x0001 /* Private */ #define MSGCRASH 0x0002 /* Crash message */ #define MSGRECD 0x0004 /* Message received */ #define MSGSENT 0x0008 /* Message sent */ #define MSGFILE 0x0010 /* File attached */ #define MSGTRANSIT 0x0020 /* In transit */ #define MSGORPHAN 0x0040 /* Orphan */ #define MSGKILL 0x0080 /* Kill/sent */ #define MSGLOCAL 0x0100 /* Local */ #define MSGHOLD 0x0200 /* Hold for pickup */ #define MSGFREQ 0x0800 /* File request */ #define MSGRRR 0x1000 /* Return receipt request */ #define MSGIRR 0x2000 /* Is return receipt */ #define MSGAUDIT 0x4000 /* Audit request */ #define MSGUPDATE 0x8000 /* File update request */ ====================================================================== MSGLIST.C ---------------------------------------------------------------------- #include #include #include #include #include "fidomsg.h" #define MAXMSGSIZE 2048 #define MYZONE 2 int readmsg(struct fts1 *msg, char *text, int limit, char *filename) FIDONEWS 13-45 Page 7 4 Nov 1996 { FILE *msgfile; /* message file handle info */ int successful = 0; char *kludgefind; int textlen; /* read and process message */ msgfile = fopen(filename, "rb"); if(msgfile != NULL) { /* read header and text */ fread(msg, sizeof(struct fts1), 1, msgfile); textlen = fread(text, 1, limit, msgfile); if(textlen < limit) text[textlen] = '\0'; else text[limit - 1] = '\0'; fclose(msgfile); successful = 1; /* identify zone information */ kludgefind = strstr(text, "\01INTL"); if(kludgefind == NULL) { msg->origzone = MYZONE; msg->destzone = MYZONE; } else { kludgefind = strchr(kludgefind, ' '); msg->destzone = atoi(kludgefind); kludgefind = strchr(&kludgefind[1], ' '); msg->origzone = atoi(kludgefind); } /* identify point information */ kludgefind = strstr(text, "\01FMPT"); if(kludgefind == NULL) msg->origpoint = 0; else msg->origpoint = atoi( &kludgefind[6] ); kludgefind = strstr(text, "\01TOPT"); if(kludgefind == NULL) msg->destpoint = 0; else msg->destpoint = atoi( &kludgefind[6] ); } return successful; } void main(void) { struct fts1 msg; struct ffblk f; char text[MAXMSGSIZE], directory[128], wildcard[128], FIDONEWS 13-45 Page 8 4 Nov 1996 msgname[128]; int done; /* initialise directory and wilcard */ strcpy(directory, "\\fd\\mail\\"); sprintf(wildcard, "%s*.msg", directory); /* main list output section */ done = findfirst(wildcard, &f, FA_ARCH); while(!done) { sprintf(msgname, "%s%s", directory, f.ff_name); readmsg(&msg, text, MAXMSGSIZE, msgname); printf("%-12s From: %s (%d:%d/%d.%d)\n", f.ff_name, msg.fromusername, msg.origzone, msg.orignet, msg.orignode, msg.origpoint); done = findnext(&f); } } ====================================================================== Conclusion Although there is much more to know about *.MSG netmail messages than is covered in this brief tutorial, I hope that it has given a start to those of you who were interested in message programming. If you're a programmer who uses a language other than C, but you can read C code, then the concepts discussed here can be easily transferred. I've successfully written message routines in both C and BASIC using the same principles. And now a few acknowledgements. Thanks must go to Bill Birrell at 2:2504/200, as he originally showed in the C_ECHO how simple the rudimentary message programming could be, and thus got me started along the road to writing a successful piece of Fidonet software. Information about *.MSG files was drawn from FTS-1 and from my own code. Most of the code was written specially for this tutorial, with the exception of a small section of the header file extracted from the InfoMail source code. Some general information on the C language and its functions as used here was obtained from K&R's 'The C Programming Language' (second edition) and from the 'info' documentation for the DJGPP compiler. As with all articles submitted by me for FidoNews, feedback is always welcome. ----------------------------------------------------------------- Read Read Read by Bob Moravsik I'll limit this article to addressing only three issues: 1. The foolish attempt at a local policy in Z2 2. Our nodelist policeman 3. The Elist and R13 conference. FIDONEWS 13-45 Page 9 4 Nov 1996 Mr. Kindness of Z2 dismisses section one of policy 4.07 by the old...its none of your business. Probably the only rebutable he has left in his diminishing arsenal. An "echopol" in Z2, because it might only apply to Z2 is a "local policy". Section one of Fidonet's policy (a brilliant piece of work) addresses this: "Seperate policy documents may be issued at the zone, region or net level to provide ADDITIONAL detail on local procedures." let's stop here for a minute. This policy may only profide ADDITIONAL details not different ones and the must address local PROCEDURES. Very limiting...let's go on "Ordinarily, these local level policies may not contradict this policy. However (the exception), with the APROVAL OF THE INTERNATIONAL COORDINATATOR (note) local policy can be used to implement differences REQUIRED due to local conditions." OK let's pause. Can't contradict, but they may if: 1. Approved by the IC 2. and differences are REQUIRED... Again...pretty limitting. "These local policies MAY NOT place additional restrictions on members of Fidonet beyond those included in this document OTHER then enforcement of local periods." 1. No additional restrictions. Simply taken all together: Z2 Woodmorepol: 1. Limited to ADDITIONAL details 2. Must be approved by the IC if there are differences. 3. These difference must be REQUIRED (not desired) 4. They can interpose ADDITIONAL restrictions. Section one was designed to prevent a local policy for the sake of itself. Mr. Kindness indicates that a Zone 2 policy would only apply to Z2 conferences. What's a Z2 conference ? Originates in Z2 ? Travels only in Z2 ? Has only a Z2 moderator. ? See the foolishness. A Z2 router routes FN_SYSOP and Z2_SYSOP. Does Woodmorepol apply to one and not the other ? In summary...a geographic policy is impractical in an internation society. It serves NO PURPOSE. It does nothing good except serve as a "prayer" to the local Fidogods. FIDONEWS 13-45 Page 10 4 Nov 1996 Mr. Kindness, I do applaud you recognition of a global policy HOWEVER...Fidonet has 6 zones. Any replacement policy which includes echomail or conferences requires 50%+1 of the RC's to present to the IC THEN 50%+1 of the *C's to vote for it positively. Until then all you have is a "circle jerk" which any node in Z2 can "attack" as being violative of section one. Section 8 does not provide for a local ratification of Woodmorepol. You have to use wild imagination to read THAT into 9.9. Lastly...it IS my business and I will continue to make it my business. By not filing a PC against me it is your admission that I'm right and you are wrong. My NC is Sean Aldrich 1:2606/0...the lines are open. ++++The Nodelist police I see an article which is a netmail from John Souvestre aka John John where he is doing ZC1 impressions. I looked through policy to see where they define a John John. Not there (at least I'm an HC). In the Fidonet conference John John was as who made HIM the spokesperson for the ZC1. The reply was a "sidestep" with a not ma job retort. Is John John looking for the IC slot ? Remember, John John runs a business selling echomail links via internet for $30 a month. Is there a connection ? Is Fidonet going "commercial". What's the motivation for John John to strap on a cap gun, get the plastic badge from a cerial box and point the guns at the ZC2. Seems to me Bob Satti should be resolving this issue IF IN FACT IT REALLY EXISTS. The absense of the ZC1's statement on the Z2 segment is indicative of an issue made up for a purpose OTHER then Fidonet. But then its hard to discuss much with John John. He filters out anybody that doesn't agree with him. +++++Region 13's echos and the Elist. Region 13 has lots of region echos now. None anymore official then the rest. The RC's conference is limited to his friends and the rest of the region uses the original ones. Region 13 is composed of two practical regions. The one the RC coordinates with 5/6 nets and the rest which is "self coordinaed". The nodes have the choice as to the conferences. Its what Fidonet is all about. The free and unrestricted right to communicate subject only to the restrictions in Policy 4.07. To conclude this matter. The RC 13 became guided more by an emotional outburst then his obligation to provide for smooth operations. After sending threating EMAIL and now seeing that he was 100% in the wrong chooses to remain unavailable to most of the region and will bide his time until replaced. Pretty PATHETIC. Bob Moravsik FIDONEWS 13-45 Page 11 4 Nov 1996 ----------------------------------------------------------------- Furry, Tender, Sad Creatures by Lee Kindness, 2:259/7, lkindnes@csl.co.uk When i asked about the FTSC 'charter' in NET_DEV i received this via crash mail. It makes quite interesting reading, especially points B1 and B3c, which have not been met by the FTSC. It is also worth noting that FSC-0000 (or FTS-0000) no longer exists in the FTSC archive. Oh, just for the hell of it, I've highlighted the three spelling mistakes in the FTSC's document - Spelling ain't their strong point ;) FidoNet(tm) Standards Committee FSC Goals and Organization FSC000-6 - August 18, 1986 A. The Problems 1. Implementors of FidoNet software (Fido itself and the many emerging 'FidoClones') need a rigorous definition of FidoNet. 2. When deciding whether to list a class of nodes in the node list, the IFNA has no way of knowing if a FidoClone is sufficiently compatible with FidoNet to be 'safe' to list. 3. Sysops need to know if a particular system will allow them to access FidoNet. 4. There are already two significant FidoNet standards, the one that is implemented by Fido, and SEAdog's extensions; plus at least one clone that seems incompatible (not by intent). The situation is becoming urgent. B. The Goals 1. Provide to implementors a rigorous definition of FidoNet and all FidoNet protocols sufficient to implement a FidoClone without recourse to other sources. 2. Provide to IFNA the means to determine whether a system is compatible with FidoNet. This will allow the IFNA to list compatible systems so Sysops may decide which system to install. 3. Produce the standards in three stages: a) Immediately document the existing FidoNet as implemented by Fido itself, FIDONEWS 13-45 Page 12 4 Nov 1996 b) Expand the definition to include SEAdog's capabilities, and c) Produce a newer, better, prettier, ... standard which incorporates all the wonderful ideas we hear while defining the first two above. C. What is to be Standardized 1. The Data Transmitted 2. The Connection 3. The Protocols 4. The Node List 5. Routing D. The Products 1. Base FidoNet Definition - FidoNet as implemented by Fido See document FSC001 2. Standard for FidoNet with SEAdog and Other Existing Extensions This is a similar to the Fido version above, but provides a place to note the extensions and structural differences a) Extensions o File Request o Update Request o Return Receipt Request o Audit trail request o Passwording Pickup o Always do CRC b) Deletions 3. Extended FidoNet Definition Suggestions and ideas without regard to merit. Inclusion implies absoloutely no commitment to standardization. ^^^^^^^^^^^ [absolutely] a) Extensions 1) Expanded net hierarchy (TH) 2) Make connection like logon so mono-modal implementations can be done (JB) 3) Add who REALLY from/to packet (TH) 4) Room for product-specific info in packet (TH) 5) Security (GW) a> Sending passwords (validating GETs and PICKUPs) b> Message encryption. When on an intermediate node, origin and final destination may be confidential. 6) Non-homogenous messages in packet using MSGX2 (GW) ^^^^^^^^^^ [homogeneous] b) Deletions 4. NodeList and NodeList Processing See document FSC002 E. Members 1. Ben Baker 100/76, IFNA Technical 2. Randy Bush 122/6, Documentation 3. Bob Hartman 132/101, Protocol Review 4. Thom Henderson 107/8, SEAdog FIDONEWS 13-45 Page 13 4 Nov 1996 5. Tom Jennings 125/1, Fido 6. Ken Kaplan 100/22, IFNA Admin 7. Gee Wong 107/312, Testing and Validation F. Acknowledgements ^^^^^^^^^^^^^^^^ [Acknowledgments] FidoNet is a trademark of Tom Jennings ----------------------------------------------------------------- FTSC Comments, observations and general lilac wallpaper by Lee Kindness, 2:259/7, lkindnes@csl.co.uk, http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html Editorial of fnewsd43: > The FTSC does NOT create standards nor does it impose standards. > The FTSC documents existing standards as they become de facto > operational practices for the majority of FidoNet participants > and/or software That quote and various other messages by Heller in NET_DEV lead to the interpretation that even thou the FTSC has not published or promoted FTS documents in the recent past (OK there was a FTS-0005 UPDATE) this is because the current FTS documents represent the present standards in use in Fidonet... hmmm... I invite all the FTSC to have a quick look in some packets on their (well here we're assuming there Fidonet members) systems. Chances are you'll find a type 2+ or 2.2 packet there and not an FTS-0001 type 2 packet. So does FTS-0001 reflect common practise? There's more to be picked at in FTS-0001 too. But you know what the worst thing is? FTS-0001 is a document that is copyrighted by a person THAT NO LONGER IS A FIDONET MEMBER, we cannot update it without his consent (along with a number of other FTS documents) The FTSC should never have accepted copyright documents into its archive! And now lets take a look at FTS-0004... Oh this one is a real treat! o It's just an extract from a programs documentation! (Published by a FTSC that will not promote the IEMSI spec to FTS status due to its format) o Tear line: o Do we need it? o What's the maximum size? o Origin line, that is nice! FTS-004 states: o It is optional (ha, send a message and see how far it gets, FIDONEWS 13-45 Page 14 4 Nov 1996 or what the recipient thinks your address is) o Although it shows an example with the network address in brackets, it does not state these are required. o No maximum size. o SEEN-BY lines: o No maximum line length o No maximum amount of lines (even thou the Conference Mail System itself strips lines after a certain amount). o Does not state SEEN-BY lines must be stripped at zone gates (due to their 2D nature). o Does not state net/node pairs must be in sorted order, with a sticky net. o PATH lines: o States no maximum line length. o No maximum amount of lines. o States the PATH line is OPTIONAL!!! o Does not state net/node pairs must be in sorted order, with a sticky net. FSC-0074 should have been adopted as FTS-0004 the minute it was submitted to the FTSC! (well before the FTSC put the stupid ^A should be handled equally rubbish). When Chris said he'll be posting the FTS documents in future issues of Fidonews I was sitting there saying "Yeh, FTS-0004 will have an extension of .JOK" The structure and membership of the FTSC is also amazing. Long gone are the days of the FTSC echo, the FTSC now communicates using an internet e-mail list... Long gone are the days of the FTSC file echo to transport updated/new documents to fidonet nodes, got to get them by the internet now... Actually I'd be willing to bet that at least half of the FTSCs members don't even use Fidonet! I'm sure that's a couple of points for the FTSC to mull over... ----------------------------------------------------------------- Trias Politica and FidoNet By Frederik Retsema (2:280/905.1) ------------------------------------------------------------------ - Readers in Holland: this article is an English translation of - - the Cursief-part in R28-nieuws of October 1996. You might want - FIDONEWS 13-45 Page 15 4 Nov 1996 - to read the Dutch article and react in the Dutch echomailarea - - CSO.028. - - - - Readers in zone 2: this article is also posted in the area - - ECHOPOL2. You might want to react there. - ------------------------------------------------------------------ In zone 2 we are trying to make a new Echomail-policy. One of the main problems seems to be the "powerplay" of some moderators. I think one of the basics of the "real-world", the so-called Trias Politica may help to solve this problem. At school (an IT-school with much Economic stuff) I learned about this Trias Politica. It means that the way we deal with rules is split up in three parts: 1 people who make rules (normally: the Government) 2 people who take care that others obey the rules (normally: the police) 3 people who judge about people who don't agree with each other about the rules (on a case-by-case base). Each of these parts is independent of each other: judges f.e. don't make rules, politicians don't judge in specific cases (but: are allowed to change rules to prevent judges to judge in the same way again). Someone can have a role in one of these parts, but never in more then one. This prevents powerplay: judges are independent, but have to stick to the rules, police must stick to the rules, but if a judge dis- agrees with the way the rules are dealt with he can overrule the decision of the police. The Government can play powerplay with the rules, but well, there has to be a great majority of people who agrees with these rules to implement these rules. The less contro- versial the rule, the more change to be implemented. Now let's have a look at FidoNet. Moderators are allowed to make the rules (part 1), are allowed to judge about these rules (part 3) and are allowed to act against people who don't obey these rules (part 2). See the problem ? This is _the_ base of powerplay. Let's go one step higher: the *EC's. These people are allowed to deal with problems between moderators and echo-participants (part 3), are allowed to take actions against people generating dupes (part 2) and in zone 2 the ZEC has also a key-role in making the rules for echomail (part 1). FidoNet has separated the tasks of netmail- and echomail- coordinators by making *C's and *EC's, has also separated the task at regional levels (area, net, region and zone), but at each level each coordinator has ALL types of powers. I think it would be wise to change this. An example of how this could be done: FIDONEWS 13-45 Page 16 4 Nov 1996 Area-level: ----------- Moderators: I think anyone agrees that the key-role of a moderator is to enforce the echorules. So let him ONLY enforce the rules: if someone doesn't stick to the rules, let the moderator warn him and let him cut links if he thinks links should be cut. Echomail-keeper: to make it possible for *EC's to see what has happened IN the area an independent echomail-keeper should keep at least (let's say) three months of echomail of that area. This task should NOT be done by the moderator, as the moderator is likely to be one of the party's in the judgement of the *EC (and therefore the moderator might gain profit by deleting some messages). Rule-changes: When someone wants the rules to change, then he may make a proposal of better rules. This new rules-file can then be subject to a vote. When more than 50% of the people who voted agrees that the new proposal is a good one, this new rules-file will act as the new echomail-rules. The moderator should NOT be the returning officer of the vote, as the moderator would have two different parts of the Trias Politica. Net/Region/Zone-level --------------------- *EC's: let these people ONLY judge. Not dealing in making policy's (this can as well be a dedicated task, performed by a skilled node or point), not enforcing rules at dupes, etc. CRP-organisations: Cost Recovery Program-organisations (in Holland also called CSO's: Cost Sharing Organisations) do deal already with links: let these organisations also deal with the dupes. Problems with dupes can be dealt with by people or workgroups within these CRP's, just as people in these CRP's please. When more than one CRP is active for one area, let the CRP's coordinate the links between the CRP's and let the *EC-structure judge when two CRP's disagree. Rule-changes: see area-level. Let ANYONE who thinks some rules can be improved say so in the international areas or in FidoNews, let's think about it, discuss it and let's vote about it. It is not recommended to let a *EC to be the returning-officer. A reaction to these ideas would be appreciated ;-). Frederik Retsema (2:280/905.1) ----------------------------------------------------------------- Are We Talking About the Same UN'I-Net? Seanette Blaylock, 1:206/2735, seanette@aol.com This is in response to a Fidonews article submitted by Rob A Shinn (surak@juno.com). Mr. Shinn, in citing examples of networks with overly restrictive FIDONEWS 13-45 Page 17 4 Nov 1996 rules, cites UN'I-Net as being so restrictive that a user can be kicked off the net for misspelling the net's name. With no disrespect to Mr. Shinn intended, I can't help wondering if he's thinking of the same UN'I-Net that I've been an active, regular participant in since about April 1994. In that time, I've seen a very few people given temporary "vacations" from specific conferences for behavior that in Fido terms would be deemed "excessively annoying" and was in direct violation of conference rules and/or what few net guidelines exist. My husband has been a regular, active participant on UN'I-Net for considerably longer than I have. In his time on the net, he recalls exactly *one* case of a user being kicked off the net, and this was for *repeated* posting of commercial advertisements in conferences in which this was a violation of conference rules. The offender, according to my information, deliberately continued these posts after receiving warnings from the hosts of the affected conferences. I've heard quite a bit of hearsay about Intelec, but have never participated in that network, so I won't comment on Mr. Shinn's remarks, except to say that his comments about Intelec match what I've heard from sources I consider reliable. I've greatly enjoyed my participation on UN'I-Net. It's not as varied or geographically wide-spread as Fido, but both nets have their good points, mostly the people who use them. I'm sorry Mr. Shinn apparently has a grudge against UN'I-Net, but his remarks about the net in question were completely at odds with my own experiences on that net. Respectfully submitted, Seanette Blaylock ----------------------------------------------------------------- FIDONEWS 13-45 Page 18 4 Nov 1996 ================================================================= COLUMNS ================================================================= [This is the first of a promised series of weekly reports from Europe.] Ed. FIDONET IN EUROPE ----------------- by Dave Meikle [2:259/58.90 , Europe@p90.f58.n259.z2.fidouk.org] No mail has been send to me but there is two things hapening in Scotland First: <-> THE REBEL JAMBO BBS <-> Home Of The Fidonet in Europe Coloum Fidonet: 2:259/58.90 Sysop@p90.f58.n259.z2.fidouk.org We have produced a WWW page , it is at : http://www.thebbslist.com/free-page/rebeljambo.html Second: The /\/ess BBS Fidonet: 2:259/57.7 Amiganet: 39:137/10.7 Ufo/BBSnet: 405:126/2.7 eMAIL: Zerox@thenet.co.uk +44 (0)1463 230062 7days 10pm-7am Uk. Thats all this week Remember the Submission address's are FIDONET: Europe@2:259/58.90 eMAIL: euro@p90.f58.n259.z2.fidouk.org Cheers Dave ----------------------------------------------------------------- FIDONEWS 13-45 Page 19 4 Nov 1996 ================================================================= GETTING TECHNICAL ================================================================= [This is a list of all the Standards and Proposals recorded at the time of its publishing. These files are available at most of the sources listed in the Masthead info at the end of FidoNews. They are all available here at 1:18/14. An FTS is a Standard. Some are mandatory and some are not. If they are used, they must be used as published. An FSC is a proposal. If they are used, they should be used as published but such use cannot be mandated.] Ed. - FidoNet Technical Standards Committee Document Archive - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Official FidoNet Technical Standards - FTS-0001.ZIP A basic FidoNet(r) technical standard, R Bush FTS-0002 *Obsoleted by FTS-0005* FTS-0003 *Obsoleted by FTS-0006* FTS-0004.ZIP Echomail specification, B Hartman FTS-0005.ZIP The distribution nodelist, B Baker, R Moore FTS-0006.ZIP YOOHOO and YOOHOO/2U2, V Perriello FTS-0007.ZIP SEAlink protocol extension, P Becker FTS-0008.ZIP Bark file-request protocol extension, P Becker FTS-0009.ZIP Message identification and reply linkage, j nutt - - FidoNet Standards Proposals And Miscellaneous Documents - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ FSC-0001 *Obsoleted by FTS-0001* FSC-0002 *Obsoleted by FTS-0005* FSC-0003.ZIP FidoNet Route Files Explained, B Baker FSC-0004.ZIP Zones and Zonegates explained primitively, R Bush FSC-0005.ZIP Opus 1.01 Netmail passwording scheme, W Wagner FSC-0006 *Obsoleted by FTS-0006* FSC-0007.ZIP RFC-822-style msg header proposal, R Heller FSC-0008.lzh *Obsoleted by FSC-0015 FSC-0009.ZIP Nodelist Flag Draft Document Gwinn/Dodell FSC-0010.ZIP Dutchie 2.80 SEAlink File Resynch, H Wevers FSC-0011.ZIP Experiences/corrections to FSC-0001, B Hartman FSC-0012 *Obsoleted by FTS-0004* FSC-0013 *Obsoleted by FTS-0008* FSC-0014.ZIP Binary-style msg proposal, W Wagner FSC-0015.ZIP FOSSIL 5.0 Documentation, R Moore FSC-0016.ZIP FidoNet Mail Session Startup, R Hartman FSC-0017.ZIP Archive Philosophy and Document Naming, R Bush FSC-0018 *Obsoleted by FTS-LIST* FSC-0019 *Obsoleted by FTS-0007* FSC-0020.ZIP Alternate Nodelist Flag Proposal M Presnell FSC-0021.ZIP VFOSSIL, OS/2 Video FOSSIL Appendage R Moore FSC-0022 *Obsoleted by FSC-0090* FSC-0023.ZIP Bundle naming convention proposal R Meyer FSC-0024.ZIP Binary bundle proposal, O McDonald FSC-0025.ZIP AVATAR Video Spec, G Stanislav FSC-0026 *Obsoleted by FTS-LIST* FIDONEWS 13-45 Page 20 4 Nov 1996 FSC-0027 *Obsoleted by FTS-0005* FSC-0028.ZIP Proposed file-forwarding standard, H Lee FSC-0029 *Reserved for future use* FSC-0030.ZIP Proposal for message identification, J Cowan FSC-0031.ZIP Proposed message id/linkage standard, M Ratledge FSC-0032.ZIP Proposed message quoting standard, M Ratledge FSC-0033.ZIP Proposal for message identification, T Kover FSC-0034.ZIP Gateways to and from FidoNet, R Bush FSC-0035.ZIP Transparent gateways to/from FidoNet, M Shiels FSC-0036.ZIP Group Mail specification, D Lovell FSC-0037.ZIP AVATAR 0+ Video Spec, G Stanislav FSC-0038.ZIP Proposed domain gating protocol, j nutt FSC-0039.ZIP A type-2 packet extension proposal, M Howard FSC-0040.ZIP Proposed modem handling extension, M Shiels FSC-0041 *Obsoleted by FTS-0009* FSC-0042.ZIP A modified gateway agreement, S Furber FSC-0043.ZIP Some hints on recognizing control lines in FidoNet(r) message text, R Bush FSC-0044.ZIP Improved duplicate detection, J Decker FSC-0045.ZIP Proposed new packet header, T Henderson FSC-0046.ZIP Proposed product identifier, J Homrighausen FSC-0047.ZIP The ^ASPLIT kludge line, P Terry FSC-0048.ZIP Proposed type-2 packet extension, J Vroonhof FSC-0049.ZIP A proposal for passing domain information during FTS-0006 sessions, B Hartman FSC-0050.ZIP A character set identifier for FidoNet message editors, T Sundblom FSC-0051.ZIP A system-independent way of transferring special characters, T Gradin FSC-0052.ZIP A proposal for making the PATH zone aware, G van der Land FSC-0053.ZIP Specifications for the ^aFLAGS field, J Homrighausen FSC-0054.ZIP The CHARSET proposal, D McNutt FSC-0054.ZIP A system independant way of transferring special characters, Duncan McNutt FSC-0055.ZIP Security passwords in nodelist updates, L Kolin FSC-0056.ZIP EMSI/IEMSI Protocol Definition, J Homrighausen FSC-0057.ZIP Echo Area Managers - Specifications For Requests, F Fabris, J Homrighausen FSC-0058.ZIP A New Way Of Addressing In FidoNet, W Van Sebroeck, J Spooren FSC-0059.ZIP Newsgroup Interchange within FidoNet, J Decker FSC-0060.ZIP Calculation and Usage of CRC's, F van der Loos FSC-0061.ZIP Proposed Guidelines for the FileBone, E VanRiper FSC-0062.ZIP Nodelist Flag Indicating Online Times, D Thomas FSC-0063.ZIP Proposal For FidoNet Messages, J Miller FSC-0064.ZIP InterDomain Message ID, Gating, Linking and Addressing, J Penner FSC-0065.ZIP Type 3 ASCII: A Proposal, M Kimes FSC-0066.ZIP Type 3 Binary: A Proposal, M Kimes FSC-0067.ZIP A Proposal For Sensible Kludge Lines, M Kimes FSC-0068.ZIP A Proposed Replacement For FTS-0004, M. Kimes FSC-0069.ZIP A FidoNet (FTN) Domain Name Service, R Heller F Arnaud FSC-0070.ZIP Improving FidoNet/UseNet Gating and Dupe Checking, FSC-0071.ZIP Distributed FREQ (DFREQ) Specifications, B Auclair FSC-0072.ZIP The HYDRA file transfer protocol, J Homrighausen, A Lentz FSC-0073.ZIP Encrypted message identification for FidoNet, John Mudge FIDONEWS 13-45 Page 21 4 Nov 1996 FSC-0074.ZIP Proposed echomail specification, J Souvestre, D Troendle, B Davis, G Peace FSC-0075.ZIP Proposal for ISDN capability flags in the nodelist, J Ceuleers FSC-0076.ZIP Proposal for netmail areatags, S Gove FSC-0077.ZIP Proposed type-10 packet format, J Steck FSC-0078.ZIP Gateway between FidoNet compatible networks, C Lacerda FSC-0079.ZIP RTF mail: proposal for message formatting in the type-2 message packet, K Axon FSC-0080.ZIP Describing FidoNet with a layered model, Mikael Staldal FSC-0081.ZIP A type-3 packet proposal, Mikael Staldal FSC-0082.ZIP A proposed new packet type, S. Slabihoud FSC-0083.ZIP A proposed standard for message IDs on FTN systems, J.de.Boyne.Pollard FSC-0084.ZIP EDX1: Electronic Data Exchange standard level 1, D.Bider FSC-0085.ZIP Proposal for the "NOZIP" and "ERX" nodelist flags, D.Bider FSC-0086.ZIP SRIF: Description of a new Standard Requestion Information File, M.Mucko FSC-0087.ZIP File forwarding in FidoNet technology networks, R.Williamson FSC-0088.ZIP Compatibility and Link Qualifier Extensions for EMSI sessions, R.Williamson FSC-0089.ZIP The INTL: netmail addressing control line, R.Williamson FSC-0090.ZIP FTSC Product Codes and Application Form FSC-0091.ZIP Proposal for ISDN nodelist flags, A Lentz FSC-0092.ZIP New control lines for forwarded messages, M.Hohner FSC-0093.ZIP Reduced seen-by lines, F.Ellermann - - FTSC Administrative Files - FTSCLIST.ZIP Directory of all FTSC files FTSCPROD.ZIP FTSC Product Codes (see also FSC-0091) - FTSC-ALL.ZIP Archive of all FTSC files as above -30- ----------------------------------------------------------------- [This FTS was reformatted to fit the 70 character limit. The large tables suffered in the conversion. These are for info only. File- request a real copy soon for a neater presentation.] Ed. Document: FTS-0001 Version: 016 Date: 30-Sep-95 A Basic FidoNet(r) Technical Standard | Revision 16 Formerly known as FSC001, FSC-0001 | Randy Bush, Pacific Systems Group | September 30, 1995 FIDONEWS 13-45 Page 22 4 Nov 1996 Status of this document: This FTS (FidoNet(r) Technical Standard) specifies a standard for the FidoNet community. FidoNet nodes are expected to adopt and implement this standard. Distribution is subject to the restrictions stated in the copyright paragraph below. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Copyright 1986-95, Randy Bush. All rights reserved. A right to distribute only without modification and only at no charge is granted. Under no circumstances is this document to be reproduced or distributed as part of or packaged with any product or other sales transaction for which any fee is charged. Any and all other reproduction or excerpting requires the explicit written consent of the author. A. Introduction FidoNet has grown beyond most peoples' fantasies, and new FidoNet implementations are appearing regularly. Unfortunately, the scattered nature of the documentation and absence of clear testing procedures have made implementation difficult. FidoNet, in its desire to promote and encourage FidoNet implementations, suggested a project to create a technical standard for FidoNet. The author did not design or specify the data formats or protocols, only attempted to document them. This document defines the data structures and communication protocols which a FidoNet implementation must provide. The implementor of FidoNet compatible systems is the intended audience of this document. The layered metaphor of the ISO Open Systems Interface reference model has been used to view FidoNet from a standard perspective. As with most prospective ISO/OSI descriptions, FidoNet does not always make this easy. The content of this document was gleaned from the references given at the end. Please direct technical comments and errata to | Randy Bush randy@psg.com | Pacific Systems Group 9501 S.W. Westhaven Drive Portland, Oregon US-97225 | 1. Basic Requirements for a FidoNet Implementation Compatibility is a set of abilities which, when taken as a whole, make it safe to list a net or node in the FidoNet nodelist. In other words, if another node should attempt contact, does it have a reasonable chance of successful FIDONEWS 13-45 Page 23 4 Nov 1996 communication? This is a social obligation, as the calling system pays money for the attempt. Conversely, an implementation should be able to successfully contact other systems, as life is not a one-way street. A FidoNet implementation must be able to call other nodes and transfer messages and files in both directions. This includes pickup and poll. A FidoNet implementation must be able to accept calls from other nodes and transfer messages and files in both directions. This includes pickup. FidoNet implementations must be able to receive and process the FidoNet format nodelist, and transfer nodelists to other nodes. A companion document, FTS-0005, defines the FidoNet format nodelist and how to interpret and process it. A FidoNet implementation must route messages which do not have files attached through net hosts as shown in a FidoNet format nodelist. 2. Levels of Compliance This documents represents the most basic FidoNet implementation. A future document will define well tested extensions which are optional but provide sufficient additional function that implementors should seriously consider them. SEAdog(tm), from System Enhancement Associates, is an excellent example of such an extended FidoNet implementation. 3. The ISO/OSI Reference Model (cribbed from "Protocol Verification via Executable Logic Specifications", D. P. Sidhu, in Rudin & West) In the ISO/OSI model, a distributed system consists of entities that communicate with each other according to a set of rules called a protocol. The model is layered, and there are entities associated with each layer of the model which provide services to higher layers by exchanging information with their peer entities using the services of lower layers. The only actual physical communication between two systems is at the lowest level. Several techniques have been used in the specification of such protocols. A common ingredient in all techniques is the notion of the extended finite state automata or machine. Extensions include the addition of state variables for the storing of state information about the protocol. The state of an automation can change as a result of one of the following events: o Request from an upper network layer for service o Response to the upper layer FIDONEWS 13-45 Page 24 4 Nov 1996 o Request to the lower network layer to perform a service o Response from the lower layer o Interaction with the system and environment in which the protocol is implemented (e.g. timeouts, host operating system aborts, ...) A protocol specification, in a large part, consists of specifying state changes in automata which model protocol entities and in describing the data which they exchange. For historical reasons, the term packet is used in FidoNet to represent a bundle of messages, as opposed to the more common use as a unit of communication, which is known as a block in FidoNet. 4. Data Description A language specific notation was avoided. Please help stamp out environmental dependencies. Only you can prevent PClone market dominance. Don't panic, there are rectangular record layouts too. (* non-terminals *) UpperCaseName - to be defined further on (* literals *) "ABC" - ASCII character string, no termination implied nnH - byte in hexadecimal (* terminals *) someName - 16-bit integer, low order byte first (8080 style) someName[n] - field of n bytes someName[.n] - field of n bits someName(n) - Null terminated string allocated n chars (incl Null) someName{max} - Null terminated string of up to max chars (incl Null) (* punctuation *) a b - one 'a' followed by one 'b' ( a | b ) - either 'a' or 'b', but not both { a } - zero or more 'a's [ b ] - zero or one 'b' (* comment *) - ignored (* predeclared constant *) Null = 00H 5. Finite State Machine Notation FIDONEWS 13-45 Page 25 4 Nov 1996 .-----+----------+-------------------+-------------------------+-----. |State | State | Predicate(s) | Action(s) | Next| |# | Name | | | St | |-----+----------+-------------------------+------------------------- +-----| | fnn*| | | | | `-----+----------+-------------------------+-------------- -----------+-----' State # - Number of this state (e.g. R13). f - FSM initial (Window, Sender, Receiver, ...) nn - state number * - state which represents a lower level protocol which is represented by yet another automation. State Name - Descriptive name of this state. Predicate(s) - Conditions which terminate the state. If predicates are non-exclusive, consider them ordered. Action(s) - Action(s) corresponding to predicate(s) Next State - Subsequent state corresponding to predicate(s) Ideally, there should be a supporting section for each state which should give a prose description of the state, its predicates, actions, etc. So much for ideals. B. Application Layer : the System from the User's View The application layer is outside the domain of a FidoNet standard, as it is the layer that the user's application sees as opposed to what FidoNet sees. In recent months, there has been sufficient confusion and discussion about the format of data at this level to warrant the description of the data structure, the message as it is stored by Fido, SEAdog, and Rover. Perfectly valid FidoNet systems may be implemented whose stored messages differ greatly from this format. 1. Application Layer Data Definition : a Stored Message Stored Message Offset dec hex .-----------------------------------------------. 0 0 | | ~ fromUserName ~ | 36 bytes | +-----------------------+-----------------------+ 36 24 | | FIDONEWS 13-45 Page 26 4 Nov 1996 ~ toUserName ~ | 36 bytes | +-----------------------+-----------------------+ 72 48 | | ~ subject ~ | 72 bytes | +-----------------------+-----------------------+ 144 90 | | ~ DateTime ~ | 20 bytes | +-----------------------+-----------------------+ 164 A4 | timesRead (low order) | timesRead (high order)| +-----------------------+-----------------------+ 166 A6 | destNode (low order) | destNode (high order) | +-----------------------+-----------------------+ 168 A8 | origNode (low order) | origNode (high order) | +-----------------------+-----------------------+ 170 AA | cost (low order) | cost (high order) | +-----------------------+-----------------------+ 172 AC | origNet (low order) | origNet (high order) | +-----------------------+-----------------------+ 174 AE | destNet (low order) | destNet (high order) | +-----------------------+-----------------------+ 176 B0 | destZone (optional) | destZone (optional) | +-----------------------+-----------------------+ 178 B2 | origZone (optional) | origZone (optional) | +-----------------------+-----------------------+ 180 B4 | destPoint(optional) | destPoint(optional) | +-----------------------+-----------------------+ 182 B6 | origPoint(optional) | origPoint(optional) | +-----------------------+-----------------------+ 184 B8 | replyTo (low order) | replyTo (high order) | +-----------------------+-----------------------+ 186 BA | Attribute (low order) | Attribute (high order)| +-----------------------+-----------------------+ 188 BC | nextReply (low order) | nextReply (high order)| +-----------------------+-----------------------+ 190 BE | text | ~ unbounded ~ | null terminated | `-----------------------------------------------' Message = fromUserName(36) (* Null terminated *) toUserName(36) (* Null terminated *) subject(72) (* see FileList below *) DateTime (* message body was last edited *) timesRead (* number of times msg has been read *) destNode (* of message *) origNode (* of message *) cost (* in lowest unit of originator's currency *) origNet (* of message *) destNet (* of message *) destZone (* of message *) FIDONEWS 13-45 Page 27 4 Nov 1996 origZone (* of message *) destPoint (* of message *) origPoint (* of message *) replyTo (* msg to which this replies *) AttributeWord nextReply (* msg which replies to this *) text(unbounded) (* Null terminated *) DateTime = (* a character string 20 characters long *) (* 01 Jan 86 02:34:56 *) DayOfMonth " " Month " " Year " " " " HH ":" MM ":" SS Null DayOfMonth = "01" | "02" | "03" | ... | "31" (* Fido 0 fills *) Month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" Year = "01" | "02" | .. | "85" | "86" | ... | "99" | "00" HH = "00" | .. | "23" MM = "00" | .. | "59" SS = "00" | .. | "59" AttributeWord bit meaning --- -------------------- 0 + Private 1 + s Crash 2 Recd 3 Sent 4 + FileAttached 5 InTransit 6 Orphan 7 KillSent 8 Local 9 s HoldForPickup 10 + unused 11 s FileRequest 12 + s ReturnReceiptRequest 13 + s IsReturnReceipt 14 + s AuditRequest 15 s FileUpdateReq s - need not be recognized, but it's ok + - not zeroed before packeting Bits numbers ascend with arithmetic significance of bit position. Message Text Message text is unbounded and null terminated (note exception below). A 'hard' carriage return, 0DH, marks the end of a paragraph, and must be preserved. FIDONEWS 13-45 Page 28 4 Nov 1996 So called 'soft' carriage returns, 8DH, may mark a previous processor's automatic line wrap, and should be ignored. Beware that they may be followed by linefeeds, or may not. All linefeeds, 0AH, should be ignored. Systems which display message text should wrap long lines to suit their application. If the first character of a physical line (e.g. the first character of the message text, or the character immediately after a hard carriage return (ignoring any linefeeds)) is a ^A (, 01H), then that line is not displayed as it contains control information. The convention for such control lines is: o They begin with ^A o They end at the end of the physical line (i.e. ignore soft s). o They begin with a keyword followed by a colon. o The keywords are uniquely assigned to applications. o They keyword/colon pair is followed by application specific data. Current ^A keyword assignments are: | o TOPT - destination point address o FMPT - origin point address o INTL - used for inter-zone address File Specifications If one or more of FileAttached, FileRequest, or FileUpdateReq are asserted in an AttributeWord, the subject{72} field is interpreted as a list of file specifications which may include wildcards and other system- dependent data. This list is of the form FileList = [ FileSpec { Sep FileSpec } ] Null FileSpec = (* implementation dependent file specification. may not contain Null or any of the characters in Sep. *) Sep = ( " " | "," ) { " " } There are deviations from and additions to these specifications 1 - Fido does not necessarily terminate the message text with a Null, but uses an empty line (0DH 0AH 0DH 0AH). Some Fido utilities use an EOF (1AH). 2 - SEAdog zeros the message cost field when building a message. 4 - SEAdog uses a different format for dates, e.g. DateTime = (* a character string 20 characters long *) FIDONEWS 13-45 Page 29 4 Nov 1996 (* SEAdog format Mon 1 Jan 86 02:34 *) DayOfWk " " DayOfMo " " Month " " Year " " HH ":" MM Null DayOfWk = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun" DayOfMo = " 1" | " 2" | " 3" | ... | "31" (* blank fill *) 2. Application Layer Protocol : Schedules and Events At the application level, FidoNet imposes few protocol requirements. An implementation must automatically originate and receive node-to-node FidoNet connections. Some implementations do this in 'windows' or time slots. Routing of messages will usually be different and customizable for each scheduled window. The ability to send to and receive from any FidoNet listed node during the Zone Mail Hour (eg. 9:00-10:00 UCT in Z1) is considered mandatory. Current implementations assemble all data for outbound connections at the start of a window, and disassemble inbound data at the end of a window. Due to performance considerations on small machines, this is considered a valid optimization. Observe that it somewhat inhibits dynamic routing. C. Presentation Layer : the User from the System's View 1. Presentation Layer Data Definition : the Packed Message To conserve space and eliminate fields which would be meaningless if sent (e.g. timesRead), messages are packed for transmission. As this is a data structure which is actually transferred, its definition is critical to FidoNet. A packed message has a number of fixed length fields followed by four null terminated strings. While most of the string fields in a stored message are fixed length, to conserve space strings are variable length when in a packet. All variable length strings are all Null terminated, including especially the message text. Packed Message Offset dec hex .-----------------------------------------------. 0 0 | 0 | 2 | 0 | 0 | +-----------------------+-----------------------+ 2 2 | origNode (low order) | origNode (high order) | +-----------------------+-----------------------+ FIDONEWS 13-45 Page 30 4 Nov 1996 4 4 | destNode (low order) | destNode (high order) | +-----------------------+-----------------------+ 6 6 | origNet (low order) | origNet (high order) | +-----------------------+-----------------------+ 8 8 | destNet (low order) | destNet (high order) | +-----------------------+-----------------------+ 10 A | Attribute (low order) | Attribute (high order)| +-----------------------+-----------------------+ 12 C | cost (low order) | cost (high order) | +-----------------------+-----------------------+ 14 E | | ~ DateTime ~ | 20 bytes | +-----------------------+-----------------------+ 34 22 | toUserName | ~ max 36 bytes ~ | null terminated | +-----------------------+-----------------------+ | fromUserName | ~ max 36 bytes ~ | null terminated | +-----------------------+-----------------------+ | subject | ~ max 72 bytes ~ | null terminated | +-----------------------+-----------------------+ | text | ~ unbounded ~ | null terminated | `-----------------------------------------------' Due to routing, the origin and destination net and node of a packet are often quite different from those of the messages within it, nor need the origin and destination nets and nodes of the messages within a packet be homogenous. PakdMessage = 02H 00H (* message type, old type-1 obsolete *) origNode (* of message *) destNode (* of message *) origNet (* of message *) destNet (* of message *) AttributeWord cost (* in lowest unit of originator's currency *) DateTime (* message body was last edited *) toUserName{36} (* Null terminated *) fromUserName{36} (* Null terminated *) subject{72} (* Null terminated *) text{unbounded} (* Null terminated *) FIDONEWS 13-45 Page 31 4 Nov 1996 2. Presentation Layer Protocol : a Mail Window .-----+----------+-------------------------+------------------------. |State| State | Predicate(s) | Action(s) | Next| | | # | Name | | | St | | |-----+----------+-------------------------+------------------------- | W0 | WindTop | 1 end of window reached | reset modem to not answr | exit| | | | 2 time remains in window| ensure modem can answer | W1 | |-----+----------+-------------------------+-------- -----------------+-----| | W1 | WindIdle | 1 incoming call | | W2 | | | | 2 receive-only mode | | W0 | | | | 3 send-only mode | | W3 | | | | 4 60-180 secs & no call | | W3 | |-----+----------+-------------------------+--------------- ----------+-----| | W2* | WindRecv | | (receive call R0) | W3 | |-----+----------+-------------------------+--------------- ----------+-----| | W3 | WindCall | 1 select outgoing call | increment try count | W4 | | | | 2 no outgoing calls | | W0 | |-----+----------+-------------------------+--------------- ----------+-----| | W4* | WindSend | | (make call S0) | W5 | |-----+----------+-------------------------+--------------- ----------+-----| | W5 | WindMark | 1 call successful | remove node fr call list| W0 | | | | 2 no connect | remove if try cnt > lim | W0 | | | | 3 call failed | incr conn cnt, remove | W0 | | | | | if con cnt > lim | | `-----+----------+-------------------------+--------------- ----------+-----' The length of the inter-call delay time at W1.4 is not critical. It is important that this not be a constant, so two systems calling each other do not incur infinite busy signals. Sophisticated implementations may vary the inter-call delay depending on number of calls to be made, window width, user specification, etc. D. Session Layer Protocol : Connecting to Another FidoNet Machine A session is a connection between two FidoNet machines. It is currently assumed to be over the DDD telephone network via modems. The calling machine starts out as the sender and the FIDONEWS 13-45 Page 32 4 Nov 1996 called machine as the receiver. The pickup feature is described by the sender and receiver changing roles midway through the session, after the sender has transferred the message packet and any attached files. Due to the lack of security in the pickup protocol (danger of pickup by a fake node), a change in the protocol may be expected in the near future. Once a connection has been established, each system should ensure that the physical connection remains throughout the session. For physical layers implemented through modems, this means monitoring the carrier detect signal, and terminating the session if it is lost. Error detection at the physical layer should be monitored for both sent and received characters. Parity, framing, and other physical errors should be detected. Sender .-----+----------+-------------------------+----------------------- --+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+--------------- ----------+-----| | S0 | SendInit | | dial modem | S1 | |-----+----------+-------------------------+--------------- ----------+-----| | S1 | WaitCxD | 1 carrier detected | delay 1-5 seconds | S2 | | | | 2 busy, etc. | report no connection | exit| | | | 3 voice | report no carrier | exit| | | | 4 carrier not detected | report no connection | exit| | | | within 60 seconds | | | |-----+----------+-------------------------+--------------- ----------+-----| | S2 | WhackCRs | 1 over 30 seconds | report no response | exit| | | | 2 ?? s received | delay 1 sec | S3 | | | | 3 s not received | send | S2 | | | | | delay ??? secs | | |-----+----------+-------------------------+--------------- ----------+-----| | S3 | WaitClear| 1 no input for 0.5 secs | send TSYNCH = AEH | S4 | | | | 2 over 60 seconds | hang up, report garbage | exit| | | | and line not clear | | | |-----+----------+-------------------------+--------------- ----------+-----| | S4* | TSyncChk | 1 'C' or NAK (peeked at)| FIDONEWS 13-45 Page 33 4 Nov 1996 (XMODEM send packet XS1)| S5 | | | | 2 over 2 seconds | eat noise, resend TSYNCH| S4 | | | | 3 over 30 seconds | hang up report not Fido | exit| |-----+----------+-------------------------+---------- ---------------+-----| | S5 | CheckMail| 1 XMODEM successful | (Fido registers success)| S6 | | | | 2 XMODEM fail or timeout| hang up, report mail bad| exit| |-----+----------+-------------------------+------------ -------------+-----| | S6* | SendFiles| | (BATCH send files BS0) | S7 | |-----+----------+-------------------------+--------------- ----------+-----| | S7 | CheckFile| 1 BATCH send successful | | S8 | | | | 2 BATCH send failed | hang up, rept files fail| exit| |-----+----------+-------------------------+----------- --------------+-----| | S8 | TryPickup| 1 wish to pickup | note send ok | R2* | | | | 2 no desire to pickup | delay 5 secs | exit| | | | | hang up, rept send ok | | `-----+----------+-------------------------+------------ -------------+-----' Although the above shows the sender emitting only one TSYNCH, it is recommended that a timeout of 5-20 seconds should initiate another TSYNCH. The receiver should tolerate multiple TSYNCHs. In state S4, the phrase "peeked at" means that the character is not removed from the buffer. Therefore when XS1 is started the proper character for beginning the Xmodem transfer will be detected. Receiver The receiving FSM is given an external timer, the expiration of which will cause termination with a result of 'no calls' (R0.2). .-----+----------+-------------------------+----------------------- --+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+--------------- ----------+-----| | R0 | WaitCxD | 1 carrier detected | | R1 | | | | 2 external timer expires| report no calls | exit| |-----+----------+-------------------------+--------------- ----------+-----| | R1 | WaitBaud | 1 baud rate detected | send signon with s | R2 | FIDONEWS 13-45 Page 34 4 Nov 1996 | | | 2 no detect in ?? secs | hang up, report no baud | exit| |-----+----------+-------------------------+---------- ---------------+-----| | R2 | WaitTsync| 1 TSYNCH received | ignore input not TSYNCH | R3 | | | | 2 60 seconds timeout | hang up, report not Fido| exit| |-----+----------+-------------------------+----------- --------------+-----| | R3* | RecMail | | (XMODEM rec packet XR0) | R4 | |-----+----------+-------------------------+---------- ---------------+-----| | R4 | XRecEnd | 1 XMODEM successful | delay 1 second | R5 | | | | | flush input | | | | | 2 XMODEM failed | hang up, rept mail fail | exit| |-----+----------+-------------------------+---------- ---------------+-----| | R5* | RecFiles | | (BATCH rec files BR0) | R6 | |-----+----------+-------------------------+--------------- ----------+-----| | R6 | ChkFiles | 1 BATCH recv successful | delay 2 secs | R7 | | | | 2 BATCH recv failed | hang up, report bad file| exit| |-----+----------+-------------------------+----------- --------------+-----| | R7 | AllowPkup| 1 have pickup for sender| receiver becomes sender | S3* | | | | 2 nothing to pickup | hang up, rept recv ok | exit| `-----+----------+-------------------------+--------------- ----------+-----' E. Transport Layer : ????? 1. Data Definitions 2. Transport Layer Protocol : Routing FidoNet does not necessarily send a message directly to its destination. To reduce the number of network connections, mail to a subset of the nodelist may be routed to one node for further distribution within that subset. In addition, custom routing is possible. Routing of a message is determined in one of three ways. o If there are files attached, then a message must be sent directly to its destination. o Messages without attached files should be routed through the inbound host of the destination node's subnet as specified by a FidoNet format nodelist. o To prevent overloading of inbound hosts, a system should provide for host routing to be disabled for a target node, or nodes. FIDONEWS 13-45 Page 35 4 Nov 1996 F. Network Layer : the Network's View of the System, Routing and Packets 1. Network Layer Data Definition : the Packet Header The packet contains messages in packed format to be transferred over the net during a connection. As this data structure is transferred, its definition is critical to FidoNet. A packet may contain zero or more packed messages. A packet without messages is often generated as a poll packet. Every packet begins with a packet header. The fields of the packet header are of fixed length. Packet Header Offset dec hex .-----------------------------------------------. 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) | +-----------------------+-----------------------+ 22 16 | destNet (low order) | destNet (high order) | +-----------------------+-----------------------+ 24 18 | prodCode | serialNo | +-----------------------+-----------------------+ 26 1A | | | password (some impls) | | eight bytes | | null padded | | | +-----------------------+-----------------------+ 34 22 | origZone (low) (opt) | origZone (high) (opt) | +-----------------------+-----------------------+ 36 24 | destZone (low) (opt) | destZone (high) (opt) | FIDONEWS 13-45 Page 36 4 Nov 1996 +-----------------------+-----------------------+ 38 26 | fill | ~ 20 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, 0=SEA *) PacketType (* old type-1 packets now obsolete *) origNet (* of packet, not of messages in packet *) destNet (* of packet, not of messages in packet *) prodCode (* 0 for Fido, write to FTSC for others *) serialNo (* binary serial number (otherwise null)*) password (* session password (otherwise null) *) origZone (* zone of pkt sender (otherwise null) *) destZone (* zone of pkt receiver (otherwise null)*) fill[20] PacketType = 02H 00H (* 01H 00H was used by Fido versions before 10 which did not support local nets. The packed message header was also different for those versions *) prodCode = ( 00H (* Fido *) | ... | ??H (* Please apply for new codes *) ) FIDONEWS 13-45 Page 37 4 Nov 1996 The remainder of the packet consists of packed messages. Each packed message begins with a message type word 0200H. A pseudo-message beginning with the word 0000H signifies the end of the packet. 2. Network Layer Data Description : a File with Attributes The BATCH protocol uses the MODEM7 filename and TeLink/XMODEM file transfer protocols to transfer the file with attributes. When a file is transferred via FidoNet, an attempt is made to also pass the operating system's attributes for the file such as length, modification date, etc. FidoNet does this via a special prefix block to the XMODEM file transfer using a protocol known as TeLink. As the TeLink protocol relies on a modification to the XMODEM file transfer protocol, it is documented at the data link layer level. The MODEM7 file name is redundant if there is also a TeLink block, in which case the name may be taken from either or both. FileName as Sent Offset dec hex .-----------------------------------------------. 0 0 | fileName | ~ 8 bytes ~ | left adjusted blank filled | +-----------------------+-----------------------+ 8 8 | fileExt | ~ 3 bytes ~ | left adjusted blank filled | `-----------------------------------------------' 3. Network Layer Protocol : BATCH File Finite State Machines BATCH File Sender .-----+----------+-------------------------+----------------------- --+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+--------------- ----------+-----| | BS0*| MoreFiles| 1 more files to send | (MODEM7 FName send MS0) | BS1 | | | | 2 no more files to send | | BS3 | |-----+----------+-------------------------+--------------- ----------+-----| | BS1 | CheckFNm | 1 MODEM7 Filename ok | (TeLink send file XS0) | BS2 | | | | 2 MODEM7 Filename bad | report name send bad FIDONEWS 13-45 Page 38 4 Nov 1996 | exit| |-----+----------+-------------------------+--------------- ----------+-----| | BS2 | CheckFile| 1 TeLink send ok | | BS0 | | | | 2 TeLink send bad | report file send bad | exit| |-----+----------+-------------------------+--------------- ----------+-----| | BS3 | EndSend | 1 rec NAK for next file | send EOT, report send ok| exit| | | | 2 10 seconds no NAK | send EOT, report no NAK | exit| `-----+----------+-------------------------+----------- --------------+-----' When no files remain, the sender responds to the receiver's NAK with an EOT. The EOT is not ACK/NAKed by the receiver. Filenames must be upper case ASCII. The data link layer uses "u" as a control character. BATCH File Receiver .-----+----------+-------------------------+----------------------- --+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+--------------- ----------+-----| | BR0*| RecvName | | (MODEM7 FName recv MR0) | BR1 | |-----+----------+-------------------------+---------- ---------------+-----| | BR1 | CheckFNm | 1 MODEM7 no more files | report files recd ok | exit| | | | 2 MODEM7 Filename ok | (TeLink recv file XR0) | BR2 | | | | 2 MODEM7 Filename bad | report name recv bad | exit| |-----+----------+-------------------------+--------------- ----------+-----| | BR2 | CheckFile| 1 TeLink recv ok | | BR0 | | | | 2 TeLink recv bad | report file recv bad | exit| `-----+----------+-------------------------+--------------- ----------+-----' G. Data Link Layer : Error-Free Data Transfer 1. Data Link Layer Data Definition : XMODEM/TeLink Blocks XMODEM transfers are in blocks of 128 uninterpreted data bytes preceded by a three byte header and followed by either a one byte checksum or a two byte crc remainder. XMODEM makes no provision for data streams which are not an integral number of blocks long. Therefore, the sender pads streams whose length is not a multiple of 128 bytes with the end-of- file character (^Z for MS-DOS), and use some other means to FIDONEWS 13-45 Page 39 4 Nov 1996 convey the true data length to the receiver (e.g. TeLink file info block). Data blocks contain sequence numbers so the receiver can ensure it has the correct block. Block numbers are sequential unsigned eight bit integers beginning with 01H and wrapping to 00H, except that a TeLink block is given sequence number 00H. For files which are attached to the mail packet, not the mail packet itself, if the sending system is aware of the file attributes as they are known to the operating system, then the first block of the XMODEM transfer may be a special TeLink block to transfer that information. This block differs in that the first byte is a SYN character as opposed to an SOH, and it is always sent checksum as opposed to CRC. Should the receiver be unwilling to handle such information, after two NAKs (or "C"s), the sender skips this special block and goes on to the data itself. XMODEM Data Block (CRC mode) Offset dec hex .-----------------------------------------------. 0 0 | SOH - Start Of Header - 01H | +-----------------------------------------------+ 1 1 | BlockNumber | +-----------------------------------------------+ 2 2 | BlockComplement | +-----------------------------------------------+ 3 3 | 128 bytes of | ~ uninterpreted ~ | data | +-----------------------------------------------+ 131 83 | CRC high order byte | +-----------------------------------------------+ 132 84 | CRC low order byte | `-----------------------------------------------' XMODEM Data Block (Checksum mode) Offset dec hex .-----------------------------------------------. 0 0 | SOH - Start Of Header - 01H | +-----------------------------------------------+ 1 1 | BlockNumber | +-----------------------------------------------+ 2 2 | BlockComplement | +-----------------------------------------------+ 3 3 | 128 bytes of | ~ uninterpreted ~ | data | +-----------------------------------------------+ FIDONEWS 13-45 Page 40 4 Nov 1996 131 83 | Checksum byte | `-----------------------------------------------' TeLink File Descriptor Block Offset dec hex .-----------------------------------------------. 0 0 | SYN - File Info Header - 16H | +-----------------------------------------------+ 1 1 | 00H | +-----------------------------------------------+ data offset 2 2 | FFH | dec hex +-----------------------------------------------+ 3 3 | File Length, least significant byte | 0 0 +-----------------------------------------------+ 4 4 | File Length, second to least significant byte | 1 1 +-----------------------------------------------+ 5 5 | File Length, second to most significant byte | 2 2 +-----------------------------------------------+ 6 6 | File Length, most significant byte | 3 3 +-----------------------------------------------+ 7 7 | Creation Time of File | 4 4 | "DOS Format" | +-----------------------------------------------+ 9 9 | Creation Date of File | 6 6 | "DOS Format" | +-----------------------------------------------+ 11 B | File Name | 8 8 ~ 16 chars ~ | left justified blank filled | +-----------------------------------------------+ 27 1B | 00H | 24 18 +-----------------------------------------------+ 28 1C | Sending Program Name | 25 19 ~ 16 chars ~ | left justified Null filled | +-----------------------------------------------+ 44 2C | 01H (for CRC) or 00H | 41 29 +-----------------------------------------------+ 45 2D | fill | 42 2A ~ 86 bytes ~ | all zero | +-----------------------------------------------+ 132 84 | Checksum byte | `-----------------------------------------------' XMODEMData = XMODEMBlock (* block of data with header and FIDONEWS 13-45 Page 41 4 Nov 1996 trailer *) | TeLinkBlock (* TeLink File Descriptor Block *) | ACK (* acknowledge data received ok *) | NAK (* negative ACK & poll 1st block *) | EOT (* end of xfer, after last block *) | "C" (* 43H *) XMODEMBlock = SOH (* Start of Header, XMODEM Block *) blockNumber[1] (* sequence, i'=mod( i+1, 256 ) *) blockCompl[1] (* one's compl of BlockNumber *) data[128] (* uninterpreted user data block *) (CRC | Checksum) (* error detect/correction code *) TeLinkBlock = SYN (* File Info Header *) 00H (* block no, must be first block *) FFH (* one's complement of block no *) fileLength[4] (* length of data in bytes *) CreationTime[2] (* time file last modified or zero *) CreationDate[2] (* date file last modified or zero *) fileName(16) (* name of file, not vol or dir *) 00H (* header version number *) sendingProg(16) (* name of program on send side *) crcMode[1] (* 01H for CRC 00H for Checksum *) fill[87] (* zeroed *) Checksum (* error detect/correction code *) ACK = 06H (* acknowledge data received ok *) NAK = 15H (* negative ACK & poll 1st block *) SOH = 01H (* start of header, begins block *) SYN = 16H (* start of TeLink file info blk *) EOT = 04H (* end of xfer, after last block *) CRC = crc[2] (* CCITT Cyclic Redundancy Check *) Checksum = checksum[1] (* low 8 bits of sum of data bytes using unsigned 8 bit FIDONEWS 13-45 Page 42 4 Nov 1996 arithmetic *) CreationDate = year[.7] (* 7 bits, years since 1980, 0- 127 *) month[.4] (* 4 bits, month of year, 1-12 *) day[.5] (* 5 bits, day of month, 1-31 *) CreationTime = hour[.5] (* 5 bits, hour of day, 0-23 *) minute[.6] (* 6 bits, minute of hour, 0-60 *) biSeconds[.2] (* 6 bits, seconds/2, 0-29 *) Note that the crcMode is always set to 01H in current implementations as all TeLink/XMODEM implementations use the CRC method. Therefore, it is always set to 01H by the sender, and is ignored by the receiver. 2. Data Link Layer Protocol : XMODEM/TeLink Finite State Machines The protocol is receiver driven, the receiver polling the sender for each block. If the receiver polls for the first block using a "C" (43H) as the poll character, it would prefer to have the CRC-CCITT polynomial remainder error detection code at the end of each block as opposed to a one byte unsigned checksum. The sender will respond to the "C" poll iff it can comply. If the sender chooses checksum as opposed to CRC, it waits for the receiver to poll with NAK (15H). Should the checksum method be preferable to the receiver, it polls with NAK rather than "C". The sender returns an EOT instead of a data block when no data remain. Neither the sender nor the receiver should send the block or ACK/NAK response while there is data being received. They should wait for the line to settle, and possibly time out. It is suggested that one's input buffer be cleared immediately after sending block or ACK/NAK response, before waiting for the response from the other end. This clears any line garbage which occurred during transmit. XMODEM/TeLink Sender .-----+----------+-------------------------+----------------------- --+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+--------------- ----------+-----| | XS0 | WaitTeLnk| 1 over 40-60 seconds | report sender timeout | exit| | | | 2 over 2 tries | note TeLink block FIDONEWS 13-45 Page 43 4 Nov 1996 failed| XS1 | | | | 3 NAK or "C" received | send TeLink, incr tries | XS0 | | | | 4 ACK received | TeLink ok, set crc/cksm | XS2 | |-----+----------+-------------------------+------ -------------------+-----| | XS1 | WaitStart| 1 over 40-60 seconds | report sender timeout | exit| | | | 2 over 20 tries | report send failed | exit| | | | 3 NAK received | set checksum mode | XS2 | | | | 4 "C" recd, I can crc | set crc mode | XS2 | | | | 5 "C" recd, I can't crc | | XS1 | |-----+----------+-------------------------+--------------- ----------+-----| | XS2 | SendBlock| 1 more data available | send next data block | XS3 | | | | | as checksum or crc | | | | | 2 last block has gone | send EOT | XS4 | |-----+----------+-------------------------+--------------- ----------+-----| | XS3 | WaitACK | 1 10 retries or 1 minute| report send failed | exit| | | | 2 ACK received | | XS2 | | | | 3 NAK (or C if 1st blk) | resend last block | XS3 | |-----+----------+-------------------------+--------------- ----------+-----| | XS4 | WaitEnd | 1 10 retries or 1 minute| report send failed | exit| | | | 2 ACK received | report send successful | exit| | | | 3 NAK received | resend EOT | XS4 | `-----+----------+-------------------------+--------------- ----------+-----' XMODEM/TeLink Receiver .-----+----------+-------------------------+----------------------- --+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+--------------- ----------+-----| | XR0 | RecStart | 1 prefer crc mode | Send "C" | XR1 | | | | 2 want checksum mode | send NAK | XR1 | |-----+----------+-------------------------+--------------- ----------+-----| | XR1 | WaitFirst| 1 10 retries or 1 minute| report receive failure | exit| | | | 2 > 3 retries or 30 secs| set want checksum mode FIDONEWS 13-45 Page 44 4 Nov 1996 | XR0 | | | | 3 EOT received | delay < sec, purge input| exit| | | | | send ACK, report no file| | | | | 4 TeLink block recd | send ACK, set crc/cksm | XR2 | | | | 5 data block recd | send ACK, set crc/cksm | XR2 | | | | 6 bad block or 2-10 secs| incr retry count | XR0 | |-----+----------+-------------------------+--------------- ----------+-----| | XR2 | WaitBlock| 1 10 retries or 1 minute| report receive failure | exit| | | | 2 EOT received | send ACK, report recd ok| exit| | | | | send ACK, report recd ok| | | | | 3 data block received | send ACK | XR2 | | | | 4 bad block or 2-10 secs| send NAK, incr retry cnt| XR2 | `-----+----------+-------------------------+------------ -------------+-----' A number of checks should be made to ensure a valid data block has been received. o The physical layer should have encountered no errors, e.g. parity, framing, etc. o The length of the block should not be less than expected. o If the blocks sequence number does not match the complement, then respond with a NAK and attempt to read the block again. o If the block's sequence number is one previous (remember wrap around) to that of the expected block, respond with an ACK and read again. o If the sequence number fits neither of the above criteria, and is yet not the expected sequence number, abort the receive. o The checksum or CRC should be correct. 3. Data Link Layer Protocol : MODEM7 Filename Finite State Machines MODEM7 Filename Sender .-----+----------+-------------------------+----------------------- --+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | FIDONEWS 13-45 Page 45 4 Nov 1996 | St | |-----+----------+-------------------------+--------------- ----------+-----| | MS0 | WaitNak | 1 20 retries or 1 minute| filename send failed | exit| | | | 2 NAK received | send ACK & 1st ch of fn | MS1 | | | (note 1) | 3 C received | return fn skipped | exit| |-----+----------+-------------------------+--------------- ----------+-----| | MS1 | WaitChAck| 1 ACK rcd, fname done | send SUB = 1AH | MS2 | | | | 2 ACK rcd, fname ~done | send next ch of fname | MS1 | | | | 3 other char or 1 sec | send "u", incr retry cnt| MS0 | |-----+----------+-------------------------+------------ -------------+-----| | MS2 | WaitCksm | 1 cksum recd and ok | send ACK, report fn ok | exit| | | | 2 cksum recd but bad | send "u", incr retry cnt| MS0 | | | | 3 no cksum in 1 sec | send "u", incr retry cnt| MS0 | `-----+----------+-------------------------+------------ -------------+-----' MODEM7 Filename Receiver .-----+----------+-------------------------+----------------------- --+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+--------------- ----------+-----| | MR0 | SendNak | 1 20 tries or 1 minute | report filename failure | exit| | | | 2 | send NAK, incr try cnt | MR1 | |-----+----------+-------------------------+--------------- ----------+-----| | MR1 | WaitAck | 1 rcd ACK | | MR2 | | | | 2 rcd EOT | report no files remain | exit| | | | 3 5 secs & no ACK/EOT | | MR0 | |-----+----------+-------------------------+--------------- ----------+-----| | MR2 | WaitChar | 1 recd EOT (can happen?)| report no files remain | exit| | | | 2 recd SUB | send checksum byte | MR3 | | | | 3 recd "u" | | MR0 | | | | 4 recd char of name | send ACK | MR2 | | | | 5 no char in 1 second | | MR0 | |-----+----------+-------------------------+--------------- ----------+-----| | MR3 | WaitOkCk | 1 recd ACK within 1 sec | report recd filename ok | exit| FIDONEWS 13-45 Page 46 4 Nov 1996 | | | 2 recd "u" or other char| | MR0 | `-----+----------+-------------------------+--------------- ----------+-----' SUB is the ASCII character ^Z or 1AH. The checksum is the unsigned low order eight bits of the sum of the characters in the transferred filename including the SUB. Although one second timeouts are used successfully by Fido and SEAdog, some fear that this is too small a timeout for some satellite and packet network links. Note 1 - MS0.3 is a common addition to accommodate a common noncompliance. Support of MS0.3 is optional for a compliant mailer. This hack also requires modification of a number of state tables, see FSC-0011. H. Physical Layer : the Actual Connection of Two FidoNet Systems Will one of the more hardware-oriented comm types give me some idea of what's needed here? Can we leave it open enough to allow implementation over a non-dial net? Thanks. I. Revisions since FTS-0001 89 Oct 25 (rev 13) o packet header: optional serialNo, password, and orig/dest zone o stored message to/from zone/point info added as option per Fido-12 and Dutchie o XR1 and XR2 changes per FSC-0011 o reference to FSC-0011 for the MODEM7-avoidance hack, MS0.3 o dropped enumeration of product codes o S4 modification from FSC-0011 o Nodelist and EID reference appropriate documents o various cosmetics 90 July 1-5 (rev 14) o spelling errors caught by Ray Gardner o references to the now dead IFNA elided o offset at end of Packed Message was 10 as opposed to 20 bytes o Packed Message and Packet Header corrections by Roland Gautschi o Offsets in TeLink header caught by Rick Moore 90 August 30 (rev 15) o corrected offsets in packet header 95 September 30 (rev 16) o TOPT corrected o contact info changed J. Acknowledgements Ben Baker, Thom Henderson, Tom Jennings, Ken Kaplan, and Gee Wong suggested, informed, reviewed, and encouraged. Tom and Thom gave me all the basics, and even allowed me to look at FIDONEWS 13-45 Page 47 4 Nov 1996 actual code. Bob Hartman was foolish enough to implement the specification, and was generous with useful feedback. Ray Gardner caught my spelling errors , and Roland Gautschi and Rick Moore found offset and length errors. My employer, Pacific Systems Group was kind enough to donate my time to research and to write this document. Fido and FidoNet are registered trademarks of Tom Jennings. SEAdog is a trademark of System Enhancement Associates. K. Bibliography Documentation for the protocols and data formats are scattered. Some are unattributed, some even untitled. Anonymous, changes to MODEM to implement CRC option XMDM-CRC.TXT Baker, Ken and Moore, Rick, Nodelist Definition, currently FTS- 0005 Christensen, Ward, "MODEM Protocol Overview" of 1 January 82 XMODEM.TXT Hartman, Bob, "Some thoughts that I had on FSC001", FSC-0011 Henderson, Thom, "SEAdog Electronic Mail System Version 3" of April 86 International Standards Organization, "Data Processing - Open Systems Interconnection - Basic Reference Model" ISO/DIS 7498 April 82 Jennings, Tom, "FidoNet Electronic Mail Protocol" 8 February 85 FIDOMAIL.DOC Jennings, Tom, "Fido's Internal Structures" of 13 September 85 STRUCT.TXT aka STRUCT.APX Jennings, Tom, "Extending XMODEM/MODEM File Transfer Protocol to support DOS" 20 September 83 FILEXFER.DOC Jordan, Larry, "XMODEM File Transfer Protocol" XMDM-LJ.TXT Rudin, H and West, C, "Protocol Specification, Testing, and Verification, III" Proceedings of the IFIP WG 6.1 Third International Workshop on Protocol Specification, Testing, and Verification, Rueschlikon Switzerland 31 May - 2 June 1983. Tanenbaum, Andrew, "Computer Networks" Prentice Hall 1981 Messages generated by Fido 11w, SEAdog 3.8, and QMail 1.01 ----------------------------------------------------------------- FIDONEWS 13-45 Page 48 4 Nov 1996 ================================================================= COORDINATORS CORNER ================================================================= Nodelist-statistics as seen from Zone-2 for day 306 By Ward Dossche, 2:292/854 ZC/2 +----+------+------------+------------+------------+------------+--+ |Zone|Nl-278|Nodelist-285|Nodelist-292|Nodelist-299|Nodelist-306|%%| +----+------+------------+------------+------------+------------+--+ | 1 | 11826|11666 -160 |11666 0 |11555 -111 |11332 -223 |37| | 2 | 16394|16341 -53 |16356 15 |16324 -32 |16307 -17 |54| | 3 | 951| 950 -1 | 956 6 | 954 -2 | 954 0 | 3| | 4 | 629| 610 -19 | 620 10 | 620 0 | 624 4 | 2| | 5 | 100| 97 -3 | 97 0 | 97 0 | 95 -2 | 0| | 6 | 1020| 1022 2 | 1020 -2 | 1020 0 | 1007 -13 | 3| +----+------+------------+------------+------------+------------+--+ | 30920|30686 -234 |30715 29 |30570 -145 |30319 -251 | +------+------------+------------+------------+------------+ ----------------------------------------------------------------- FIDONEWS 13-45 Page 49 4 Nov 1996 ================================================================= NET HUMOR ================================================================= From: "Mike Riddle" To: "Baker, Christopher" Date: Fri, 01 Nov 96 11:24:17 -0500 Reply-To: "Mike Riddle" Subject: Re: Conmputer people... On Fri, 1 Nov 1996 09:39:52 -0600 (CST), Terry Begley, Information Technology Coordinator wrote: Date: Fri, 1 Nov 1996 09:12:54 EST From: Alex Demenschonok To: WINNT-L@eva.dc.LSOFT.COM Subject: Re: smtp/pop3/dns server for WNT On 1 Nov 96 at 8:35, Michael A. Mandel wrote: > A normal person being what? A non-computer systems expert? I'm not > sure if that means we're better than "normal persons", but if it is, > hey that's o.k. too! hi, i think he means following :-) .... Computer experts consider themselves well dressed if their socks match. Computer experts buy their spouses a set of matched screwdrivers for their birthday. Computer experts wear moustaches or beards for "efficiency". Not because they're lazy. Computer experts have a non-technical vocabulary of 800 words. Computer experts think a "biting wit" is their fox terrier. Computer experts repair their own cameras, telephones, televisions, watches, and automatic transmissions. Computer experts say "It's 70 degrees Fahrenheit, 25 degrees Celsius, and 298 degrees Kelvin" and all you say is "Isn't it a nice day" Computer experts give you the feeling you're having a conversation with a dial tone or busy signal. Computer experts wear badges so they don't forget who they are. Sometimes a note is attached saying "Don't offer me a ride today. I drove my own car". Computer experts' politics run towards acquiring a parking space with FIDONEWS 13-45 Page 50 4 Nov 1996 their name on it and an office with a window. Computer experts know the "ABC's of Infrared" from A to B. Computer experts rotate their tires for laughs. Computer experts' briefcases contain a Phillips screwdriver, a copy of "C/C++", and a half of a peanut butter sandwich. Computer experts don't find the above at all funny. Cheers ! ----- Terry Begley, Information Technology Coordinator Creighton University, College of Business Administration 2500 California Plaza Omaha, NE 68178 USA, Earth tbegley@creighton.edu 402.280.2619 http://eden.creighton.edu Member of the NonSequitur society. Our motto: "We don't have regular meetings, but isn't blue a nice color?" ----------------------------------------------------------------- FIDONEWS 13-45 Page 51 4 Nov 1996 ================================================================= NOTICES ================================================================= Future History 5 Nov 1996 Election day, U.S.A. 5 Nov 1996 Guy Fawkes Day, England. 1 Dec 1996 Twelfth Anniversary of FidoNews Volume 1, Issue 1. 12 Dec 1996 Constitution Day, Russia 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-45 Page 52 4 Nov 1996 ================================================================= FIDONET SOFTWARE LISTING ================================================================= Latest Greatest Software Versions by Peter E. Popovich, 1:363/264 Still catching up from last week's crash. I should be up-to-date by next week's issue. Phased out this week: QNX Software Phase-out highlights: This week: Kitten 1.01 Software Deadline for info: 15 Nov 1996. Last week: Atari ST/TT Software Deadline for info: 8 Nov 1996. -=- Snip -=- Submission form for the Latest Greatest Software Versions column OS Platform : Software package name : Version : Function(s) - BBS, Mailer, Tosser, etc. : Freeware / Shareware / Commercial? : Author / Support staff contact name : Author / Support staff contact node : Magic name (at the above-listed node) : Please include a sentence describing what the package does. Please send updates and suggestions to: Peter Popovich, 1:363/264 -=- Snip -=- MS-DOS: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP ALLFIX 4.33 T S Harald Harms 2:281/415 ALLFIX Announcer 1.1 O S Peter Karlsson 2:206/221 ANNOUNCE BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX CheckPnt 0.5 beta O F Michiel van der Vlist 2:500/9 CHECKPNT FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES FrontDoor 2.12 M S JoHo 2:201/330 FD FrontDoor 2.20c M C JoHo 2:201/330 FDINFO GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO Imail 1.75 T S Michael McCabe 1:297/11 IMAIL ImCrypt 1.04 O F Michiel van der Vlist 2:500/9 IMCRYPT InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB FIDONEWS 13-45 Page 53 4 Nov 1996 IPNet 1.11 O S Michele Stewart 1:369/21 IPNET Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386 MakePl 1.8 N F Michiel van der Vlist 2:500/9 MAKEPL Marena 1.1 beta O F Michiel van der Vlist 2:500/9 MARENA Maximus 3.01 B P Tech 1:249/106 MAX McMail 1.0g5 M S Michael McCabe 1:1/148 MCMAIL MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP MsgEd 4.00 O G Paul Edwards 3:711/934 MSGED Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS O/T-Track 2.63a O S Peter Hampf 2:241/1090 OT PcMerge 2.7 N F Michiel van der Vlist 2:500/9 PCMERGE PlatinumXpress 1.1 M C Gary Petersen 1:290/111 PX11TD.ZIP RAR 2.00 C S Ron Dwight 2:220/22 RAR RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA Silver Xpress Door 5.4 O S Gary Petersen 1:290/111 FILES Reader 4.3 O S Gary Petersen 1:290/111 SXR43.ZIP Squish 1.11 T P Tech 1:249/106 SQUISH StealTag UK 1.c... O F Fred Schenk 2:284/412 STEAL_UK StealTag NL 1.c... O F Fred Schenk 2:284/412 STEAL_NL T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK TriBBS 10.0 B S Patrick Driscoll 1:372/19 TRIBBS TriDog 10.0 M S Patrick Driscoll 1:372/19 TRIDOG TriToss 10.0 T S Patrick Driscoll 1:372/19 TRITOSS WWIV 4.24a B S Craig Dooley 1:376/126 WWIV XRobot 3.01 O S JoHo 2:201/330 XRDOS OS/2: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX FleetStreet 1.18 O S Michael Hohner 2:2490/2520 FLEET GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO ImCrypt 1.04 O F Michiel van der Vlist 2:500/9 IMCRYPT Maximus 3.01 B P Tech 1:249/106 MAXP MsgEd 4.00 O G Paul Edwards 3:711/934 MSGED PcMerge 2.3 N F Michiel van der Vlist 2:500/9 PCMERGE RAR 2.00 C S Ron Dwight 2:220/22 RAR2 Squish 1.11 T P Tech 1:249/106 SQUISHP T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2 Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK XRobot 3.01 O S JoHo 2:201/330 XROS2 Windows (16-bit apps): Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL FIDONEWS 13-45 Page 54 4 Nov 1996 Windows (32-bit apps): Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL Maximus 3.01 B P Tech 1:249/106 MAXN PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO T-Mail 2.599I M S Ron Dwight 2:220/22 TMAILNT Unix: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- ifmail 2.8f M G Eugene Crosser 2:293/2219 IFMAIL ifmail-tx 2.8f-tx7.7 M G Pablo Saratxaga 2:293/2219 IFMAILTX MsgEd 4.00 O G Paul Edwards 3:711/934 MSGED Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK Amiga: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK MsgEd 4.00 O G Paul Edwards 3:711/934 MSGED Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK Function: B-BBS, M-Mailer, N-Nodelist, G-Gateway, T-Tosser, C-Compression, O-Other. Note: Multifunction will be listed by the first match. Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial, X-Crippleware, D-Demoware, G-Free w/ Source Old info from: 01/27/92 --------------------------------------------------------------------- MS-DOS Systems -------------- BBS Software NodeList Utilities Other Utilities Name Version Name Version Name Version -------------------- -------------------- -------------------- Kitten 1.01 EditNL 4.00 MailBase 4.11a@ Lynx 1.30 FDND 1.10 MSG 4.5* Merlin 1.39n MakeNL 2.31 MsgLnk 1.0c Oracomm 5.M.6P@ Parselst 1.33 MsgMstr 2.03a Oracomm Plus 6.E@ Prune 1.40 MsgNum 4.16d PCBoard 14.5a SysNL 3.14 MSGTOSS 1.3 Phoenix 1.07* XlatList 2.90 Netsex 2.00b ProBoard 1.20* XlaxNode/Diff 2.53 OFFLINE 1.35 QuickBBS 2.75 Oliver 1.0a RBBS 17.3b Other Utilities OSIRIS CBIS 3.02 RemoteAccess 1.11* Name Version PKInsert 7.10 SimplexBBS 1.05 -------------------- PolyXarc 2.1a SLBBS 2.15C* 2DAPoint 1.50* QM 1.00a Socrates 1.11 4Dog/4DMatrix 1.18 QSort 4.04 SuperBBS 1.12* ARCAsim 2.31 RAD Plus 2.11 FIDONEWS 13-45 Page 55 4 Nov 1996 SuperComm 0.99 ARCmail 3.00* Raid 1.00 TAG 2.5g Areafix 1.20 RBBSMail 18.0 TBBS 2.1 ConfMail 4.00 ScanToss 1.28 TComm/TCommNet 3.4 Crossnet 1.5 ScMail 1.00 Telegard 2.7* DOMAIN 1.42 ScEdit 1.12 TPBoard 6.1 DEMM 1.06 Sirius 1.0x WildCat! 3.02* DGMM 1.06 SLMail 2.15C XBBS 1.77 DOMAIN 1.42 StarLink 1.01 EEngine 0.32 TagMail 2.41 Network Mailers EMM 2.11* TCOMMail 2.2 Name Version EZPoint 2.1 Telemail 1.5* -------------------- FGroup 1.00 TGroup 1.13 BinkleyTerm 2.50 FidoPCB 1.0s@ TIRES 3.11 D'Bridge 1.30 FNPGate 2.70 TMail 1.21 Dreamer 1.06 GateWorks 3.06e TosScan 1.00 Dutchie 2.90c GMail 2.05 UFGATE 1.03 Milqtoast 1.00 GMD 3.10 VPurge 4.09e PreNM 1.48 GMM 1.21 WEdit 2.0@ SEAdog 4.60 GoldEd 2.31p WildMail 2.00 SEAmail 1.01 GROUP 2.23 WMail 2.2 TIMS 1.0(mod8) GUS 1.40 WNode 2.1 Harvey's Robot 4.10 XRS 4.99 Compression HeadEdit 1.18 XST 2.3e Utilities HLIST 1.09 YUPPIE! 2.00 Name Version ISIS 5.12@ ZmailH 1.25 -------------------- Lola 1.01d ZSX 2.40 ARC 7.12 Mosaic 1.00b ARJ 2.20 LHA 2.13 PAK 2.51 PKPak 3.61 PKZip 1.10 OS/2 Systems ------------ BBS Software Other Utilities(A-M Other Utilities(N-Z) Name Version Name Version Name Version -------------------- -------------------- -------------------- Kitten 1.01 ARC 7.12 oMMM 1.52 SimplexBBS 1.04.02+ ARC2 6.01 Omail 3.1 ConfMail 4.00 Parselst 1.33 EchoStat 6.0 PKZip 1.02 Network Mailers EZPoint 2.1 PMSnoop 1.30 Name Version FGroup 1.00 PolyXOS2 2.1a -------------------- GROUP 2.23 QSort 2.1 BinkleyTerm 2.50 LH2 2.11 Raid 1.0 BinkleyTerm(S) 2.50 MSG 4.2 Remapper 1.2 BinkleyTerm/2-MT MsgLink 1.0c Tick 2.0 1.40.02 MsgNum 4.16d VPurge 4.09e SEAmail 1.01 Xenix/Unix 386 -------------- FIDONEWS 13-45 Page 56 4 Nov 1996 BBS Software Network Mailers Other Utilities Name Version Name Version Name Version -------------------- -------------------- -------------------- ARC 5.21 C-LHARC 1.00 |Contact: Willy Paine 1:343/15,| MSGLINK 1.01 |or Eddy van Loo 2:285/406 | oMMM 1.42 Omail 1.00 ParseLst 1.32 Unzip 3.10 VPurge 4.08 Zoo 2.01 Macintosh --------- BBS Software Network Mailers Other Software Name Version Name Version Name Version -------------------- -------------------- -------------------- FBBS 0.91 Copernicus 1.0 ArcMac 1.3 Hermes 1.6.1 Tabby 2.2 AreaFix 1.6 Mansion 7.15 Compact Pro 1.30 Precision Sys. 0.95b EventMeister 1.0 Red Ryder Host 2.1 Export 3.21 Telefinder Host Import 3.2 2.12T10 LHARC 0.41 MacArd 0.04 Mantissa 3.21 Point System Mehitable 2.0 Software OriginatorII 2.0 Name Version PreStamp 3.2 -------------------- StuffIt Classic 1.6 Copernicus 1.00 SunDial 3.2 CounterPoint 1.09 TExport 1.92 MacWoof 1.1 TimeStamp 1.6 TImport 1.92 Tset 1.3 TSort 1.0 UNZIP 1.02c Zenith 1.5 Zip Extract 0.10 Amiga ----- BBS Software Network Mailers Other Software Name Version Name Version Name Version -------------------- -------------------- -------------------- 4D-BBS 1.65 BinkleyTerm 1.00 Areafix 1.48 DLG Pro. 0.96b TrapDoor 1.80 AReceipt 1.5 Falcon CBCS 1.00 WelMat 0.44 ChameleonEdit 0.11 Starnet 1.0q@ ConfMail 1.12 TransAmiga 1.07 ElectricHerald 1.66 XenoLink 1.0 Compression FFRS 1.0@ FIDONEWS 13-45 Page 57 4 Nov 1996 Utilities FileMgr 2.08 Name Version Fozzle 1.0@ NodeList Utilities -------------------- Login 0.18 Name Version AmigArc 0.23 MessageFilter 1.52 -------------------- booz 1.01 Message View 1.12 ParseLst 1.66 LHARC 1.30 oMMM 1.50 Skyparse 2.30 LhA 1.10 PolyXAmy 2.02 TrapList 1.40 LZ 1.92 RMB 1.30 PkAX 1.00 Roof 46.15 UnZip 4.1 RoboWriter 1.02 Zippy (Unzip) 1.25 Rsh 4.07a Zoo 2.01 Tick 0.75 TrapToss 1.20 |Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02 Atari ST/TT ----------- BBS Software Network Mailers Other Utilities Name Version Name Version Name Version -------------------- -------------------- -------------------- FIDOdoor/ST 2.5.1 BinkleyTerm 2.40n9 ApplyList 1.00@ FiFo 2.1v The Box 1.95* Burep 1.1 LED ST 1.00 ComScan 1.04 QuickBBS/ST 1.06* ConfMail 4.10 NodeList Utilities Echoscan 1.10 Name Version FDrenum 2.5.2 Compression -------------------- FastPack 1.20 Utilities ParseList 1.30 Import 1.14 Name Version EchoFix 1.20 oMMM 1.40 -------------------- sTICK/Hatch 5.50 Pack 1.00 ARC 6.02 Trenum 0.10 LHARC 2.01i PackConvert STZip 1.1* UnJARST 2.00 WhatArc 2.02 Tandy Color Computer 3 (OS-9 Level II) -------------------------------------- BBS Software Compression Utility Other Utilities Name Version Name Version Name Version -------------------- -------------------- -------------------- RiBBS 2.02+ Ar 1.3 Ascan 1.2 DeArc 5.12 AutoFRL 2.0 OS9Arc 1.0 Bundle 2.2 UnZip 3.10 CKARC 1.1 UnLZH 3.0 EchoCheck 1.01 FReq 2.5a LookNode 2.00 ParseLST PReq 2.2 RList 1.03 FIDONEWS 13-45 Page 58 4 Nov 1996 RTick 2.00 UnBundle 1.4 UnSeen 1.1 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Key to old info: + - Netmail Capable (Doesn't Require Additional Mailer Software) * - Recently Updated Version @ - New Addition -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Please send updates and suggestions to: Peter Popovich, 1:363/264 ----------------------------------------------------------------- FIDONEWS 13-45 Page 59 4 Nov 1996 ================================================================= FIDONEWS PUBLIC-KEY ================================================================= [this must be copied out to a file starting at column 1 or it won't process under PGP as a valid public-key] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 Comment: Clear-signing is Electronic Digital Authenticity! -----END PGP PUBLIC KEY BLOCK----- Pending a formal decision about including 'encrypted' material inside FidoNews from the Zone Coordinator Council, the guts of the FidoNews public-key have been removed from this listing. File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone 1 ZMH at 1200-9600+ HST/V32B. This section will contain only this disclaimer and instructions until a ZCC decision is forwarded to the Editor. Sorry for any inconvenience. ----------------------------------------------------------------- FIDONEWS 13-45 Page 60 4 Nov 1996 ================================================================= FIDONEWS INFORMATION ================================================================= ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ------- Editor: Christopher Baker Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello, Tim Pozar, Tom Jennings, Sylvia Maxwell, Donald Tees "FidoNews Editor" FidoNet 1:1/23 BBS 1-904-409-7040, 300/1200/2400/14400/V.32bis/HST(ds) more addresses: Christopher Baker -- 1:18/14, cbaker84@digital.net cbak.rights@opus.global.org (Postal Service mailing address) FidoNews Editor P.O. Box 471 Edgewater, FL 32132-0471 U.S.A. voice: 1-904-409-3040 [1400-2100 ET only, please] [1800-0100 UTC/GMT] ------------------------------------------------------ FidoNews is published weekly by and for the members of the FIDONET INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation of individual articles contributed by their authors or their authorized agents. The contribution of articles to this compilation does not diminish the rights of the authors. OPINIONS EXPRESSED in these articles ARE THOSE OF THE AUTHORS and not necessarily those of FidoNews. Authors retain copyright on individual works; otherwise FidoNews is Copyright 1996 Christopher Baker. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact the original authors, or the Editor. =*=*=*=*=*=*=*=*= OBTAINING COPIES: The most recent issue of FidoNews in electronic form may be obtained from the FidoNews Editor via manual download or file-request, or from various sites in the FidoNet and Internet. PRINTED COPIES may be obtained by sending SASE to the above postal address. File-request FIDONEWS for the current Issue. File-request FNEWS for the current month in one archive. Or file-request specific back Issue filenames in distribution format [FNEWSDnn.LZH] for a FIDONEWS 13-45 Page 61 4 Nov 1996 particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP where mmm = three letter month [JAN - DEC] and y = last digit of the current year [6], i.e., FNWSMAY6.ZIP for all the Issues from May 96. Annual volumes are available as FNEWSn.ZIP where n = the Volume number 1 - 12 for 1984 - 1995, respectively. Annual Volume archives range in size from 48K to 1.2M. INTERNET USERS: FidoNews is available via: http://www.fidonet.org/fidonews.htm ftp://ftp.fidonet.org/pub/fidonet/fidonews/ ftp://ftp.aminet.org/pub/aminet/comm/fido/ You can read the current FidoNews Issue in HTML format at: http://www.geocities.com/athens/6894/ STAR SOURCE for ALL Past Issues via FTP and file-request - Available for FReq from 1:396/1 or by anonymous FTP from: ftp://ftp.sstar.com/fidonet/fnews/ Each yearly archive also contains a listing of the Table-of-Contents for that year's issues. The total set is currently about 11 Megs. =*=*=*= The current week's FidoNews and the FidoNews public-key are now also available almost immediately after publication on the Editor's new homepage on the World Wide Web at: http://ddi.digital.net/~cbaker84/fidonews.html There are also links there to jim barchuk's HTML FidoNews source and to John Souvestre's FTP site for the archives. There is also an email link for sending in an article as message text. Drop on over. =*=*=*=*=*=*=*=*= A PGP generated public-key is available for the FidoNews Editor from 1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18. It is also posted twice a month into the PKEY_DROP Echo available on the Zone 1 Echomail Backbone. *=*=*=*=* Anyone interested in getting a copy of the INTERNET GATEWAY FAQ may file-request GISFAQ.ZIP from 1:133/411.0, or send an internet message to fidofaq@gisatl.fidonet.org. No message or text or subject is necessary. The address is a keyword that will trigger the automated response. People wishing to send inquiries directly to David Deitch should now mail to fidonet@gisatl.fidonet.org rather than the previously listed address. FIDONEWS 13-45 Page 62 4 Nov 1996 *=*=*=*=* SUBMISSIONS: You are encouraged to submit articles for publication in FidoNews. Article submission requirements are contained in the file ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable from 1:1/23 [1:18/14] as file "ARTSPEC.DOC". ALL Zone Coordinators also have copies of ARTSPEC.DOC. Please read it. "Fido", "FidoNet" and the dog-with-diskette are U.S. registered trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141, and are used with permission. "Disagreement is actually necessary, or we'd all have to get in fights or something to amuse ourselves and create the requisite chaos." -Tom Jennings -30- -----------------------------------------------------------------