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-
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|