3488 lines
161 KiB
Plaintext
3488 lines
161 KiB
Plaintext
|
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 <stdio.h>
|
|||
|
|
#include <time.h>
|
|||
|
|
#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 <time.h> 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 <stdio.h>
|
|||
|
|
#include <dir.h>
|
|||
|
|
#include <string.h>
|
|||
|
|
#include <stdlib.h>
|
|||
|
|
#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
|
|||
|
|
(<control-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
|
|||
|
|
<cr>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 <pt no> - destination point address
|
|||
|
|
o FMPT <pt no> - origin point address
|
|||
|
|
o INTL <dest z:n/n> <orig z:n/n> - 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
|
|||
|
|
<cr> | exit|
|
|||
|
|
| | | 2 ?? <cr>s received | delay 1 sec
|
|||
|
|
| S3 |
|
|||
|
|
| | | 3 <cr>s not received | send <cr> <sp> <cr>
|
|||
|
|
<sp>| 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 <cr>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 <blush>, 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" <mriddle@novia.net>
|
|||
|
|
To: "Baker, Christopher" <cbaker84@digital.net (Christopher Baker)>
|
|||
|
|
Date: Fri, 01 Nov 96 11:24:17 -0500
|
|||
|
|
Reply-To: "Mike Riddle" <mriddle@novia.net>
|
|||
|
|
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 <alexd@WARD-ASSOCIATES.COM>
|
|||
|
|
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-
|
|||
|
|
|
|||
|
|
|
|||
|
|
-----------------------------------------------------------------
|
|||
|
|
|
|||
|
|
|