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=>
[email protected] |
+----------------------------------------------------------------------+
| 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,
[email protected]
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,
[email protected],
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,
[email protected]
This is in response to a Fidonews article submitted by Rob A Shinn
(
[email protected]).
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 ,
[email protected]]
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
[email protected]
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:
[email protected]
+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:
[email protected]
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
[email protected]
| 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" <
[email protected]>
To: "Baker, Christopher" <
[email protected] (Christopher Baker)>
Date: Fri, 01 Nov 96 11:24:17 -0500
Reply-To: "Mike Riddle" <
[email protected]>
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 <
[email protected]>
To:
[email protected]
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
[email protected] 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,
[email protected]
[email protected]
(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
[email protected]. 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
[email protected] 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-
-----------------------------------------------------------------
