2580 lines
121 KiB
Plaintext
2580 lines
121 KiB
Plaintext
F I D O N E W S -- Volume 14, Number 6 10 February 1997
|
||
+----------------------------+-----------------------------------------+
|
||
| The newsletter of the | ISSN 1198-4589 Published by: |
|
||
| FidoNet community | "FidoNews" |
|
||
| _ | 1-904-409-7040 [1:1/23] |
|
||
| / \ | |
|
||
| /|oo \ | |
|
||
| (_| /_) | |
|
||
| _`@/_ \ _ | |
|
||
| | | \ \\ | Editor: |
|
||
| | (*) | \ )) | Christopher Baker 1:18/14 |
|
||
| |__U__| / \// | |
|
||
| _//|| _\ / | |
|
||
| (_/(_|(____/ | |
|
||
| (jm) | Newspapers should have no friends. |
|
||
| | -- JOSEPH PULITZER |
|
||
+----------------------------+-----------------------------------------+
|
||
| Submission address: FidoNews Editor 1:1/23 |
|
||
+----------------------------------------------------------------------+
|
||
| MORE addresses: |
|
||
| |
|
||
| submissions=> cbaker84@digital.net |
|
||
+----------------------------------------------------------------------+
|
||
| For information, copyrights, article submissions, |
|
||
| obtaining copies of FidoNews or the internet gateway FAQ |
|
||
| please refer to the end of this file. |
|
||
+----------------------------------------------------------------------+
|
||
|
||
|
||
WHERE WERE YOU ON THIS DAY IN HISTORY?
|
||
|
||
|
||
Table of Contents
|
||
1. EDITORIAL ................................................ 1
|
||
Flacking the hack? WebRing is back! ...................... 1
|
||
2. GUEST EDITORIAL .......................................... 2
|
||
Almost a New Beginning! .................................. 2
|
||
3. ARTICLES ................................................. 6
|
||
Zone 2 nodelist flags .................................... 6
|
||
A reply to "Fidonews, The "lard ass" of newsletters" ..... 12
|
||
A simple rebuttal ........................................ 13
|
||
4. GETTING TECHNICAL ........................................ 16
|
||
FSC-0034 - Gateways to and from FidoNet .................. 16
|
||
FSC-0035 - Transparent Gateways to and from FidoNet ...... 22
|
||
FSC-0036 - Group Mail Specifications ..................... 24
|
||
5. COORDINATORS CORNER ...................................... 30
|
||
Nodelist-statistics as seen from Zone-2 for day 038 ...... 30
|
||
6. NET HUMOR ................................................ 31
|
||
Why did the chicken cross the road? ...................... 31
|
||
7. NOTICES .................................................. 35
|
||
Future History ........................................... 35
|
||
8. FIDONET SOFTWARE LISTING ................................. 37
|
||
Latest Greatest Software Versions ........................ 37
|
||
9. FIDONEWS PUBLIC-KEY ...................................... 44
|
||
FidoNews PGP public-key listing .......................... 44
|
||
10. FIDONET BY INTERNET ..................................... 45
|
||
11. FIDONEWS INFORMATION .................................... 47
|
||
FIDONEWS 14-06 Page 1 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
EDITORIAL
|
||
=================================================================
|
||
|
||
|
||
Some people believe that disagreement is personal. I've never
|
||
understood that but I do acknowledge the trait exists in some folks.
|
||
|
||
There isn't anything personal in my observations from FidoNews 1405
|
||
regarding the substance of Gary Gilmore's 'lard ass' article in that
|
||
Issue. His opinion was aired without fail and without editing. If it
|
||
were personal, here, would it have been published? His article and my
|
||
response are part of the public record. If he finds that unfair,
|
||
that's his problem. Isn't it? The readers can decide between the views
|
||
and send in their own articles.
|
||
|
||
While he was railing against the size of FidoNews, I never mentioned
|
||
his own contribution to the size of the Nodelist with 5 separate
|
||
entries for the same telephone number. Now, that might have been
|
||
considered personal, too, but it would just have been a fact like the
|
||
other points I made. [grin]
|
||
|
||
Facts are not personal. FidoNews IS for communicating and he is doing
|
||
it again in this Issue. More power to him! He is completely incorrect
|
||
about it being personal at this end. Could he be projecting? Nah. We
|
||
disagree. No big deal. No insults - thinly or thickly veiled. I do get
|
||
the last word in a sense but that, too, is transitory until the next
|
||
Issue comes out. Them's the breaks in the real world.
|
||
|
||
I'd like to remind everyone that there is an official FidoNews Echo
|
||
for discussion of FidoNews ops and articles. It is available on the
|
||
Zone 1 Backbone as FIDONEWS and also gets around to other Zones last I
|
||
heard. There you can get some nearly real-time responses rather than
|
||
this 1-2 week lag in the published FidoNews. It has no size
|
||
constraints, either.
|
||
|
||
Meanwhile, the motto in the banner sez it all. [chuckle]
|
||
|
||
In other news, there is a Guest Editorial in this Issue. It was
|
||
received via the U.S. Mail from a former FidoNet Sysop who still
|
||
follows the doings of FidoNet but has an ongoing problem with local
|
||
Coordinators and does not have a Node number at present. It speaks for
|
||
itself. Any responses will be received by the author when he reads the
|
||
FidoNews containing them. It's a LONG one by Editorial standards. I
|
||
hope that doesn't cause any apoplexy out there. We publish what we
|
||
get the way we get it.
|
||
|
||
The WebRing [www.webring.org] is finally back on the new server and
|
||
everyone who has been sending me mail asking about not being able to
|
||
get an answer may now proceed to sign up their FidoNet-related web
|
||
pages again. There are currently 5 sites connected to the ring and
|
||
it's ready for the rest of you. [See 1402 for details.]
|
||
|
||
C.B.
|
||
|
||
-----------------------------------------------------------------
|
||
FIDONEWS 14-06 Page 2 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
GUEST EDITORIAL
|
||
=================================================================
|
||
|
||
|
||
Almost A New Beginning!
|
||
by: V.H.(Clay) Tannacore
|
||
|
||
On June the 5th, 1989, "A New Beginning" should have begun. It
|
||
didn't! Why? What went wrong? Why didn't this "New Beginning"
|
||
resolve the dilemma it was designed to? Last, but not least, Why
|
||
hasn't there been a New, New Beginning? Some of these answers may
|
||
never be resolved. Some are discussed by members of the origination
|
||
in question. Some . . . Well, no one wants to address them, leastwise
|
||
not in any open forum. Especially, not where the dreaded "C-Monsters"
|
||
could overhear them.
|
||
|
||
What am I babbling about? Come on folks, you know! FidoNet and The
|
||
Policy 4 Document. Who are the "C-Monsters?" None other then those
|
||
big, bad Regional Coordinators, Network Coordinators, Zone
|
||
Coordinators, and assuredly that (now missing) International
|
||
Coordinator. Those who inhabit the upper echelons of FidoNet. The
|
||
same "C" structure that for reasons only familiar to themselves, keep
|
||
this prehistoric epitaph alive, and in force. This opprobrious
|
||
document that system operators (SysOps) around the world are told to
|
||
operate by. This uncomplicated/complicated instrument with its
|
||
"guidance" pertaining to the operation of FidoNet, and all FidoNets
|
||
subordinate followers. This same instrument which leaves relatively
|
||
everything up for grabs, with one exception. The one exclusion being
|
||
how the "C" structure (aka-C-Monsters) is; 1) appointed 2) elected
|
||
3) to perform their duties 4) to delegate authority 5) to
|
||
(attempt) operate his/her Net, Region, Zone etc. etc. The "guidance"
|
||
given in the Policy 4 document to individual Network Coordinators,
|
||
Regional Coordinators, and Zone Coordinators, with very few exceptions
|
||
is so utterly vague and inadequate it may as well be nonexistent. But
|
||
I'm getting a little ahead of myself, here. Allow me to continue with
|
||
(my opinion of) what is wrong with the present day FidoNet policies
|
||
and operations.
|
||
|
||
Continuing right along, and in the same otiose manner. Let us examine
|
||
the duties of the Regional Coordinator as per the Policy 4 document.
|
||
In Section 1.2.4 (Region and Regional Coordinators) of this
|
||
superannuated document, there is a total of 102 words. The first 41
|
||
words explain *what* a Regional Coordinator is. The next 53 words
|
||
(and I'm being generous here) detail (grimace) the duties of the
|
||
Regional Coordinator(s). Following this VERY lengthy in depth job
|
||
description are another 8 words. These words inform all that the RC
|
||
is "appointed" by the Zone Coordinator. Now, according to Policy 4,
|
||
Section 1.2.4, The Regional Coordinator has one (and only one) duty to
|
||
perform, and that is, and I quote; "maintains the list of independent
|
||
nodes in the region and accepts nodelists from the Network
|
||
Coordinators in the region. These are compiled to create a regional
|
||
nodelist, which is then sent to the Zone Coordinator." Unquote!
|
||
WOW!! Doesn't that sound like a grueling job description to you? Of
|
||
course we all know that what is described in the Policy 4 document is
|
||
but a fraction of what an RC is expected to do, and on a daily basis,
|
||
FIDONEWS 14-06 Page 3 10 Feb 1997
|
||
|
||
|
||
at that. Why then does not this (Policy 4) document explain just what
|
||
is expected of the RC, and how this is to be accomplished? Sure, give
|
||
as much leeway to the person as possible, but by all means "guide"
|
||
him/her in accepted procedures so to avoid a multitude of different
|
||
methods of operations from network to network. In one word
|
||
"STANDARDIZE" FidoNet, so as to insure a harmonious environment.
|
||
|
||
As I have pointed out above. There are *no* real formal instructions
|
||
to assist anyone in comprehending just what is expected of them,
|
||
except to inform them that a *nodelist* must be compiled. HELLO!! I
|
||
bet you didn't know it, but by far the greatest magnitude of the
|
||
SysOps within the FidoNet organization already knew that... Perhaps
|
||
back in 1988 and 1989 (when this hideous document was formulated) the
|
||
composers of Policy 4 felt that the education level of brother members
|
||
were substandard, or something. I don't know, personally. All I can
|
||
remember of that time period is the contemptible power struggle that
|
||
was prevalent within FidoNet. Not to say that the *power hungry* are
|
||
not still a part of this great organization (FidoNet) but to some
|
||
degree have been restrained in achievement of their goals. Which I
|
||
consider a *PLUS* for this confederation of ours.
|
||
|
||
Now that you have endured all my maunder, and haven't as yet called
|
||
for my lynching. I assume one of two things; 1) you may think I have
|
||
something here, or 2) you are in the process of trying to contact
|
||
"Doctor Jack" to see if he makes house calls in South Carolina. Rest
|
||
easy, what Dr. Jack can't do. The Veterans Administration (VA)
|
||
Medical Center (aka-Hospital) will. However, before that time
|
||
arrives, or before some technical computer type figures out how to
|
||
send a nuclear fission apparatus via NetMail. Let me pass on a few
|
||
(of my) suggestions I have that may possibly be plausible ideas for
|
||
the betterment of FidoNet, and everyone involved.
|
||
|
||
First, and foremost, we (meaning you SysOps, and members of FidoNet)
|
||
need desperately to assemble a team of members, who can recast
|
||
(rewrite) the Policy 4 Document, in order to bring it up to present
|
||
day standards, taking into consideration the technology at our
|
||
disposal.
|
||
|
||
Second, and almost as significant, clear cut directions and procedures
|
||
*must* be established within the New Policy 4 (or whatever it is
|
||
called) document. Guide lines must be set for Regional
|
||
Coordinators(Network Coordinators are addressed in a forthcoming
|
||
summary) in order for the orderly operation (day to day) of FidoNet in
|
||
every area of the globe where FidoNet is active.
|
||
|
||
Third, (and here a lot of discretion must be employed) Regional
|
||
Coordinators must be made aware that the *users* (without who FidoNet
|
||
is doomed) must have a way of asserting his/her opinions, as well as
|
||
having a way of voicing their grievances directly to the RC, without
|
||
fear of retribution from a local Network Coordinator.
|
||
|
||
Fourth, (again discretion and even sophistication must be stressed)
|
||
the Regional Coordinators must *oversee* (without over-overseeing)and
|
||
supervise their Network Coordinators (bearing in mind the voluntary
|
||
nature of the FidoNet NC) so that a well organized, and smooth flowing
|
||
Net is the end result.
|
||
FIDONEWS 14-06 Page 4 10 Feb 1997
|
||
|
||
|
||
Fifth suggestion (and a pet peeve of mine) is for the Regional
|
||
Coordinator(s) to adopt an intelligent formatting scheme for EchoMail
|
||
messages. Presently no such system is in effect, and the EchoMail
|
||
message bases are in total tumult, with very few exceptions. Text
|
||
lines are *quoted* by the dozens, even *quoted text* is *quoted* by
|
||
the (mis)user leaving a message that started out at 2Kb of text, with
|
||
the robust size of a Shareware Program (just a tiny bit of
|
||
misrepresentation, here) ready for use on a PC. Even the blank lines
|
||
of text are being *quoted* adding to the size of the message. Why
|
||
individual SysOps haven't taken steps to stop this misuse, I'll never
|
||
know. This practice does nothing but cost money, time, and space, not
|
||
to mention the offensive looking messages echoed over 300 or 400
|
||
different systems throughout the FidoNet areas.
|
||
|
||
Sixth (getting tired yet?) suggestion is a simple one. As every SysOp
|
||
in FidoNet knows, The Internet has lured many, many users from their
|
||
local bulletin boards. The Internet with all its modernistic lingo,
|
||
with enticing graphics, E-Mail, and Faxing capability etc. etc. Its
|
||
world wide (WEB) accessibility, its . . . Hey! . .wait on darn minute.
|
||
Isn't this just what FidoNet was supposed to be? Isn't this *just*
|
||
what FidoNet *is*??? Oh, maybe not all the goodies like graphics, and
|
||
Faxing, etc, but still a great place to communicate, and for free(?).
|
||
|
||
Seventh, and last suggestion for this conclave, okay? The *free*
|
||
assertion above isn't entirely accurate, anymore. There seems to be a
|
||
growing fascination with *Pay For Use* bulletin boards. I suppose
|
||
this is the SysOp way of entering into competition with The Internet.
|
||
But, in reality all that is being accomplished is degradation of
|
||
FidoNet along with the principles and ideals it was founded on. How
|
||
can anyone expect a user to understand that he/she has to *donate*,
|
||
*help support*, or *become a member* of a bulletin board, in order to
|
||
read/write mail or upload/download a file. Gee, isn't this just what
|
||
he/she has heard about The Internet? He/She was under the impression
|
||
that a local bulletin board was there as a *hobby* and was free of
|
||
*service charges*. He/She thought *hobby* was "something a person
|
||
likes to do in his/her spare time," just like Mr. Webster explains it
|
||
in his dictionary. I know administering to a bulletin board (BBS)
|
||
isn't cheap, not by a long shot, but it is a *hobby*, and should be
|
||
operated that way. I started running my first BBS, on an Atari 800,
|
||
in 1978, so trust me when I say *I know about operating costs* first
|
||
hand. It wasn't until 1984 that I got into the IBM and FidoNet
|
||
business, and even then money was considered a collectors item, to me.
|
||
Granted, after your initial costs, the rest was kind of inexpensive,
|
||
unless you wanted a *BIG* 40Meg Hard Drive, with a price tag of
|
||
$400-500.00. But at no time did I, or anyone else in the Net (with
|
||
the exception of the then NC) ever even think about charging a user a
|
||
fee. No one except the *software pirates* who kept copyrighted
|
||
software available for download on their system, for their *paying*
|
||
members. Hmmm! Could that be the reason so many systems operate on a
|
||
*Pay Per Use* basis?
|
||
|
||
As promised, no more *suggestions* or *criticisms*. I'll let a
|
||
sleeping (puppy) dog lie, for the time being. However, I hope what I
|
||
have written will incite others to do the same. Voices *have* to be
|
||
raised if anything is to be done, and rest assured, something has to
|
||
be done. FidoNet is in danger of a slow death, unless suitable action
|
||
FIDONEWS 14-06 Page 5 10 Feb 1997
|
||
|
||
|
||
is instituted, and extremely soon. The people who are really involved
|
||
with FidoNet, and who genuinely care about its existence in the
|
||
future will stand up and let their viewpoints be known. This has to
|
||
be a combined effort if reconstruction is to take place.
|
||
|
||
If by chance this article is published in FidoNet and you find it
|
||
creditable. I implore you to let the editor (Christopher Baker
|
||
1:18/14) know. Voice your own opinions and suggestions pertaining to
|
||
the inadequacies of the Policy 4 Document. If you think *making
|
||
waves* is frowned upon within the FidoNet structure, you have been
|
||
misinformed. On the off chance your reflection is correct, then more
|
||
then ever *CHANGE* is a necessity, and PDQ.
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-06 Page 6 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
ARTICLES
|
||
=================================================================
|
||
|
||
|
||
Zone 2 nodelist flags
|
||
Frank Ellermann, 2:240/5815.1
|
||
|
||
|
||
This article informs about known differences of FidoNet zone 2
|
||
nodelist flags from FTS-0005.003. The ultimate sources for these
|
||
informations are the current zone 2 nodelist epilog and the setup
|
||
for flag corrections at Z2C, but it may be difficult to get these
|
||
sources for readers in other zones.
|
||
|
||
|
||
FTS-0005 flags
|
||
--------------
|
||
The following flags are used as specified in FTS-0005.003:
|
||
|
||
CM Node accepts mail 24 hours a day
|
||
MO Node does not accept human callers
|
||
LO Node accepts calls only from valid listed node
|
||
numbers in the current FidoNet nodelist
|
||
|
||
V21 ITU-T V21 300 bps full duplex
|
||
V22 ITU-T V22 1200 bps full duplex
|
||
|
||
In zone 2 a value of 1200 in the former "baud rate" field implies
|
||
V22. Today only two nodes not supporting at least V22bis or ISDN
|
||
still exist in the zone 2 segment, therefore the flags V21 and V22
|
||
are obsolescent. Both flags should be dropped from FTS-0005.
|
||
|
||
V29 ITU-T V29 9600 bps half duplex
|
||
V33 ITU-T V33
|
||
|
||
V33 cannot be used in connecting Fido nodes over public dial-up
|
||
lines and is most probably a historical error in FTS-0005. This
|
||
flag should be removed from FTS-0005 a.s.a.p. A similar argument
|
||
is applicable on V29, and few nodes flagging V29 today all support
|
||
at least V32. The next version of FTS-0005 should drop V29.
|
||
|
||
V32 ITU-T V32 9600 bps full duplex
|
||
-> V32B ITU-T V32bis 14400 bps full duplex (implies V32)
|
||
V34 ITU-T V34 28800 bps full duplex
|
||
|
||
FTS-0005 specifies V32b and V42b (capital V and small b), current
|
||
nodelist practice in FidoNet shows all combinations of small and
|
||
capital letters for flags. This was no problem before FSC-0062
|
||
introduced case-sensitive flags. In zone 2 all old flags except
|
||
from FSC-0062 flags are upper case, and a NODEDIFF changing this
|
||
convention would be annoying. The best solution is to stick to
|
||
the current practice and treat all old flags as case-insensitive.
|
||
|
||
H96 Hayes V9600
|
||
HST USR Courier HST up to 9600 (implies MNP)
|
||
FIDONEWS 14-06 Page 7 10 Feb 1997
|
||
|
||
|
||
H14 USR Courier HST up to 14400 (implies HST)
|
||
-> H16 USR Courier HST up to 16800 (implies H14 and V42B)
|
||
MAX Microcom AX/96xx series
|
||
PEP Packet Ensemble Protocol
|
||
CSP Compucom Speedmodem
|
||
-> ZYX Zyxel series 16800 bps (implies V32B and V42B)
|
||
-> V32T V.32 Terbo 19200 bps (implies V32B)
|
||
VFC V.Fast Class 28800 bps
|
||
|
||
If a flag directly or indirectly implies other flags, then these
|
||
other flags are not shown in a nodelist entry, because this would
|
||
be redundant. Unfortunately the rules for redundancies in zone 2
|
||
and FTS-0005 are different. Zone 2 continued to avoid redundancy
|
||
with most "new" flags, but FTS-0005.003 specified no redundancies
|
||
for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this
|
||
context are flags approved by FidoNet International Coordinators
|
||
since 1989, when FTS-0005.TXT, the predecesssor of FTS-0005.003,
|
||
was published.
|
||
|
||
For details see the chapter "implications" below, for now only
|
||
note, that in zone 2 H16 implies V42B, ZYX implies V32B and V42B,
|
||
and V32T implies V32B.
|
||
|
||
Zone 1 and zone 2 have introduced a user flag Z19 approved by the
|
||
corresponding Zone Coordinator. User flags are discussed later,
|
||
for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
|
||
while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag
|
||
for all Zyxel protocol speeds.
|
||
|
||
Today there is only one node in FidoNet still flagging MAX, this
|
||
flag is obsolete and should be dropped from FTS-0005. The flags
|
||
HST, H14, and CSP should be marked as obsolescent.
|
||
|
||
MNP Microcom Networking Protocol error correction
|
||
V42 ITU-T LAP-M error correction w/fallback to MNP 1-4
|
||
-> V42B ITU-T LAP-M error correction w/fallback to MNP 1-5
|
||
|
||
As mentioned above FTS-0005 specifies V42b (capital V, small b).
|
||
In zone 2 all case-insensitive flags are listed in upper case.
|
||
|
||
The next version of FTS-0005 will probably adopt the better V42B
|
||
and MNP definitions of the zone 3 nodelist epilog. FTS-0005.003
|
||
specifies an implication of V42 by V42B, but the exact meaning of
|
||
the flag MNP is unclear. Most probably this flag was meant to
|
||
indicate support of MNP 1-4, and in this sense V42B implies MNP.
|
||
|
||
In zone 2 MNP is considered as redundant, if V42B is flagged or
|
||
implied by other flags like H16, ZYX, or Z19.
|
||
|
||
MN No compression supported
|
||
|
||
XA Bark and WaZOO file/update requests
|
||
XB Bark file/update requests, WaZOO file requests
|
||
XC Bark file requests, WaZOO file/update requests
|
||
XP Bark file/update requests
|
||
XR Bark and WaZOO file requests
|
||
FIDONEWS 14-06 Page 8 10 Feb 1997
|
||
|
||
|
||
XW WaZOO file requests
|
||
XX WaZOO file/update requests
|
||
|
||
These flags are equivalent in FTS-0005 and in the zone 2 segment.
|
||
|
||
Gx..x Gateway to domain 'x..x'
|
||
|
||
Valid values for this flag are assigned by the Fido International
|
||
Coordinator, FTS-0005.003 explicitly mentions GUUCP. In zone 2
|
||
only GUUCP gateways are flagged.
|
||
|
||
#01 Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A
|
||
#02 Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A
|
||
-> #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
|
||
#09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
|
||
#18 Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A
|
||
#20 Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A
|
||
|
||
The variants !01, !02, !08, !09, !18, and !20 indicate missing
|
||
Bell 212A support. In zone 2 #02 or !02 would be obviously
|
||
redundant.
|
||
|
||
Today less than five 1200 modems (V22 or Bell 212A) are listed.
|
||
A future version of FTS-0005 should drop !mn variants together
|
||
with V21 and V22 flags.
|
||
|
||
Further most non-CM systems flagging #mn or !mn today probably
|
||
want to show additional online times instead of additional mail
|
||
hours. As soon as FSC-0062 flags have been approved by the IC
|
||
or adopted as FTS by the FTSC, the following version of FTS-0005
|
||
should mark #mn as obsolescent and recommend the more flexible
|
||
FSC-0062 flags (see below).
|
||
|
||
|
||
User flags
|
||
----------
|
||
An example for one of several problems in zone 2 with user flags:
|
||
|
||
...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC
|
||
|
||
These flags indicate a modern Zyxel ISDN-modem and two additional
|
||
user flags ENC and NEC. This possible user flags string contains
|
||
34 characters, but at most 32 characters are allowed in FTS-0005.
|
||
|
||
...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC
|
||
|
||
During the period for the replacement of old by new ISDN flags
|
||
(several months !) many nodes listed both old and new flags for
|
||
maximal compatibility, and no problems with nodelist compilers
|
||
or mailers caused by too long user flags strings were reported.
|
||
|
||
Therefore the length limit in FTS-0005 is probably unnecessary
|
||
and at least inconsequent: Other nodelist fields like the system
|
||
name are unlimited, so why only restrict the user flags string ?
|
||
To help developpers an upper limit of e.g. 255 characters for a
|
||
nodelist line and 63 characters for fields 3 to 6 would be more
|
||
FIDONEWS 14-06 Page 9 10 Feb 1997
|
||
|
||
|
||
useful.
|
||
|
||
The next problem with user flag strings as specified in FTS-0005
|
||
is their introduction by the letter U with no comma following:
|
||
|
||
Nodelist compilers could parse ...,UISDN,USR in user flags ISDN
|
||
and USR. But USR cannot be approved as "real" flag, because the
|
||
combination ...,USR,UISDN would then be parsed in SR and UISDN.
|
||
|
||
Other side effects of the FTS-0005 specification are additional
|
||
difficulties in finding flags. Almost all flags are separated
|
||
by a comma, only the first user flag can be an exception to this
|
||
simple rule. If the order of user flags has no meaning, then...
|
||
|
||
...,UV120L,V120H
|
||
...,UV120H,V120L
|
||
|
||
... are equivalent. A "simple" solution of this problem could be
|
||
to treat UV120L as synonym for V120L, and UV120H as synonym for
|
||
V120H. Similar problems show up, if user flags are counted, etc.
|
||
|
||
Obviously a nodelist compiler looking for user flags has always
|
||
to consider the case "user flag separated by comma". In zone 2
|
||
this idea was simply extended to the first user flag:
|
||
|
||
All flags are separated by commas. Flags not yet approved by the
|
||
International Coordinator or the FTSC (i.e. user flags only used
|
||
experimentally or locally) are separated by a new pseudo flag U.
|
||
|
||
-> U pseudo flag to the left of at least one user flag
|
||
|
||
All flags following this pseudo flag U are user flags, all flags
|
||
before this pseudo flag are "real" flags specified in FTS-0005 or
|
||
approved by the International Coordinator.
|
||
|
||
Because this definition should be compatible with any reasonable
|
||
software implementation based on FTS-0005.003, and simplifies the
|
||
handling of user flags significantly, a future FTS-0005 version
|
||
will hopefully adopt it.
|
||
|
||
|
||
Approved zone 2 user flags
|
||
--------------------------
|
||
In zone 2 user flags have to be approved by the Zone Coordinator.
|
||
Currently the following zone 2 user flags exist:
|
||
|
||
-> V110L ITU-T V.110 19k2 async 'Low' (former ISDNA)
|
||
-> V110H ITU-T V.110 38k4 async 'High' (former ISDNB)
|
||
-> V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
|
||
-> V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
|
||
-> X75 ITU-T X.75 SLP (single link procedure),
|
||
64kbit/s B channel; layer 2 max. framesize N1 = 2048,
|
||
window size W = 2, frame numbering modulo 8;
|
||
layer 3 transparent (no packet layer)
|
||
-> ISDN Other configuration, used only if none of above fits
|
||
|
||
FIDONEWS 14-06 Page 10 10 Feb 1997
|
||
|
||
|
||
These ISDN flags follow the specification in FSC-0091.
|
||
|
||
-> Tyz Online time flags as specified in FSC-0062
|
||
|
||
The flag Tyz is used by non-CM nodes online not only during ZMH,
|
||
y is a letter indicating the start and z a letter indicating the
|
||
end of the online period as defined below (times in UTC):
|
||
|
||
A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,
|
||
D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,
|
||
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,
|
||
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,
|
||
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
|
||
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
|
||
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,
|
||
V 21:00, v 21:30, W 20:00, w 20:30, X 23:00, x 23:30.
|
||
|
||
For example TuB shows an online period from 20:30 until 1:00 UTC.
|
||
|
||
-> Z19 Zyxel series 19200 bps (implies ZYX)
|
||
|
||
-> K12 Systems offering all educational K12-conferences
|
||
-> ENC The node accepts inbound encrypted mail
|
||
|
||
-> NC Network Coordinator (only if the NC is not the host)
|
||
-> NEC Net Echomail Coordinator (at most one per net)
|
||
-> REC Region Echomail Coordinator (at most one per region)
|
||
-> ZEC Zone Echomail Coordinator (at most one per zone)
|
||
|
||
Redundant AKAs used to indicate echomail coordination in zone 2
|
||
are no longer permitted. One *EC flag is valid for all AKAs of
|
||
a given sysop.
|
||
|
||
|
||
Flag implications
|
||
-----------------
|
||
Flag implications directly or indirectly specified in FTS-0005:
|
||
|
||
HST => MNP
|
||
H14 => MNP HST
|
||
H16 => MNP HST H14
|
||
V42b => V42 (MNP ?)
|
||
V32b => V32
|
||
|
||
Flag implications specified in the zone 2 nodelist epilog:
|
||
|
||
HST => MNP
|
||
H14 => HST MNP
|
||
-> H16 => V42 MNP V42B H14 HST
|
||
-> V42B => V42 MNP
|
||
-> ZYX => V42 MNP V42B V32B
|
||
-> Z19 => V42 MNP V42B V32B ZYX
|
||
V32B => V32
|
||
-> V32T => V32 V32B
|
||
|
||
-> V110L => ISDN
|
||
FIDONEWS 14-06 Page 11 10 Feb 1997
|
||
|
||
|
||
-> V110H => ISDN
|
||
-> V120L => ISDN
|
||
-> V120H => ISDN
|
||
-> X75 => ISDN
|
||
|
||
The latter ISDN flag redundancies are a consequence of FSC-0091.
|
||
Maybe one of the following implications could be added in zone 2:
|
||
|
||
VFC => V32 V32B
|
||
VFC => V32 V32B MNP V42 V42B
|
||
|
||
Flag implications (i.e. not listing redundant flags) have several
|
||
advantages: Some old nodelist tools are unable to handle too long
|
||
lines. Old flags like HST, MNP, V42, or V32 vanish automatically,
|
||
if they are implied by H16, V42B, V32B, or better. Redundancies
|
||
defined globally for the whole nodelist help to avoid flag errors.
|
||
|
||
|
||
"Baud rate" field
|
||
-----------------
|
||
The former "baud rate" field 7 in the nodelist as specified in
|
||
FTS-0005 is nearly useless today: Except from a few remaining
|
||
1200 and 2400 nodes almost all nodelist entries show either 9600
|
||
for all modem protocols better than V22bis or 300 for ISDN only
|
||
nodes. No more V21 or Bell 103 modems are listed today.
|
||
|
||
Obscure "baud rate" values 19200 and 38400 specified in FTS-0005
|
||
have not been used in the FidoNet nodelist. So all a reasonable
|
||
nodelist compiler can do today, is treat 300 as indicator for
|
||
ISDN only, and treat unknown or missing values in field 7 like
|
||
9600.
|
||
|
||
A new meaning for field 7 as speed field could be really useful.
|
||
An example is ZYX, if we would have 16800, 19200, 28800, and 33600
|
||
as speed values, then their combination with ZYX is all we need
|
||
technically, Z19 would be unnecessary. Another example is HST,
|
||
flags H14 and H16 are unnecessary, if HST is combined with 9600,
|
||
14400, 16800, 28800, or 33600. Variants of PEP could be shown in
|
||
the speed field without new flags. "Enhanced V32.terbo" could be
|
||
shown by 21600.
|
||
|
||
Most important: V34 may have the famous bug not allowing connects
|
||
from new "V34+", unless the caller disabled symbol rate 3429. If
|
||
"V34+" is indicated by speed 33600, then an appropriate setup for
|
||
all kinds of V34 connects is possible.
|
||
|
||
A future version of FTS-0005 hopefully allows the following speed
|
||
values in field 7:
|
||
|
||
300 reserved for ISDN only (for historical reasons)
|
||
1200 V22 or Bell 212A (obsolete)
|
||
2400 implies V22bis
|
||
9600 default, used with V32, HST, H96, PEP, CSP
|
||
12000 rare variant of V32
|
||
14400 used with V32b or HST (obsoleting H14)
|
||
16800 used with ZYX or HST (obsoleting H16)
|
||
FIDONEWS 14-06 Page 12 10 Feb 1997
|
||
|
||
|
||
19200 used with V32T or ZYX (obsoleting Z19)
|
||
21600 rare variant of V32T (no "H21" needed)
|
||
28800 used with VFC or V34
|
||
33600 used with V34 (no V34+ or V34b needed)
|
||
57600 used with "X2" clients
|
||
|
||
The following values should be specified in FTS-0005, because they
|
||
are already used in nodelists of other FTNs:
|
||
|
||
empty no value, useful for Pvt nodes or in point lists
|
||
19200 used with V110L, V32T, or ZYX (obsoleting Z19)
|
||
38400 used with V110H
|
||
57600 used with V120L or "X2"
|
||
64000 used with V120H, X75, or other ISDN equipment
|
||
|
||
Allowing more than 12 speed values or allowing ISDN speeds could
|
||
break old software. Therefore the transition could be done in two
|
||
steps, first add all non-ISDN speeds (ISDN only shown as 300).
|
||
|
||
Later remove 300 (ISDN only) and 1200 (obsolete) replacing 300 by
|
||
19200, 38400, 57600, or 64000.
|
||
|
||
|
||
Thanks to...
|
||
------------
|
||
Ben Baker St. Louis nodelist format
|
||
Rick Moore FTS-0005.TXT
|
||
David Nugent FTS-0005.003 and NLTOOLS
|
||
Jonny Bergdahl ERRFLAGS 2.6
|
||
Ward Dossche Zone 2 nodelist epilog
|
||
Arjen Lentz FSC-0091.001
|
||
David J. Thomas FSC-0062.003
|
||
Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV
|
||
Jim Barchuk LNDL 2.7
|
||
Marius Ellen FASTV7 2.03j (but I still prefer 1.45b ;-)
|
||
Jan Vermeulen, Jan Ceuleers, Ian Smith, and many others...
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|
||
A reply to "Fidonews, The "lard ass" of newsletters"
|
||
|
||
By Tony Dunlap, 1:2220/30
|
||
|
||
I was reading the paper the other day and noticed in the want ads a
|
||
Maytag wringer washer for sale for $35.00. There was also an article
|
||
with "Your Twelve Favorite Recipes Using Yogurt" (Not that I'd ever
|
||
eat anything with a name that sounds like something that had already
|
||
been eaten (then disposed of)). Then of course there were the funnies
|
||
(most of which weren't), and the bridge column. I am not interested
|
||
in any of these things, but I at least glance at them (mainly in hope
|
||
of gaining a glimmer of understanding of the deranged minds of people
|
||
who would be interested in such things <g>).
|
||
|
||
The point I am trying to make is that Fidonews is for all members of
|
||
FIDONEWS 14-06 Page 13 10 Feb 1997
|
||
|
||
|
||
Fidonet, not just the majority, and if a article is found useful by
|
||
just one member, it belongs there.
|
||
|
||
As for it's size, come on! All of last year's Fnews in their
|
||
distrubuted format (LZH and ZIP) will fit on one high density floppy
|
||
(Try to store a year's worth of newspapers in that space!)
|
||
|
||
By the way, just for fun I called about the wringer washer...
|
||
It's gone.
|
||
|
||
---
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|
||
Ooh, ow! You wound me!
|
||
by Gary Gilmore, 1:2410/400
|
||
|
||
|
||
Well, it seems that it's ok to write something -for- Fidonews, just
|
||
as long as you don't -talk- about Fidonews. <sigh> I thought the
|
||
"editorial" about my article was a little out of line, but thought
|
||
"what the hell, I'll respond". The Fidonews editor's comments are
|
||
quoted...
|
||
|
||
cb> He doesn't say how long he's been around but only refers to
|
||
cb> the output of Tees, the previous Editor as example of FidoNews
|
||
cb> size past.
|
||
|
||
Gee, I didn't know that mattered. I guess it's part of a Fido
|
||
"elite-ism" of "my board is older than yours, so you're not as good
|
||
as me", which I've always found silly. Heck, I've seen BBS systems
|
||
that have been up for a month that have floored me, and I've seen
|
||
very old BBS systems that were total garbage, so what's the
|
||
difference? For what it's worth, my BBS has been in constant
|
||
operation since January 9th, 1988. I've been in Fidonet since 1990.
|
||
(Somewhere around the summer of that year, if I recall right. My
|
||
system was even a Computer Shopper Magazine "BBS Of The Month" for
|
||
May of 1991.. not that it means a whole lot in the big picture.
|
||
|
||
Now, does any of that make my comments more or less valid? <shrug>
|
||
I don't think so. We're Fidonet sysops, this is Fidonews, and that
|
||
means this is the place where we can comment. ...and our comments
|
||
shouldn't be cast aside with editorials trying to make them seem less
|
||
valid than the next persons.
|
||
|
||
cb> Since Tees didn't bother to actively edit FidoNews many times,
|
||
cb> it's hardly surprising many of his Issues were miniscule or
|
||
cb> Editorial only phosphor padding.
|
||
|
||
Oh geez... now it's "slag the old editor" time. I find it humorous
|
||
that the term "phosphor padding" is used here, when this past issue
|
||
contains yet more FTSC bulletins to puff up the S'nooze. Ah well...
|
||
|
||
cb> FidoNews has been all sizes the past 13 years from 5K to 157K.
|
||
|
||
FIDONEWS 14-06 Page 14 10 Feb 1997
|
||
|
||
|
||
But I do think the content has varied wildly. Sometimes great stuff,
|
||
sometimes nothing but dreck. I know the contributors have the burden
|
||
of making Fidonews what it is, but I still don't think intentionally
|
||
puffing it up makes it better.
|
||
|
||
cb> Nobody has to read it; part or all of it.
|
||
|
||
Very true, and perhaps the more dry it gets, the less it's read.
|
||
I can't count the times I've said "Did you read <article name> in
|
||
Fidonews?" to some fellow sysops, and they almost always say "Ah, I
|
||
never read that thing". Too bad. I do. All the time.
|
||
|
||
cb> The History and Standards series is part of what FidoNet is and
|
||
|
||
Sure is! I don't think it needs to be completely reprinted though,
|
||
since it's already available elsewhere. Those that really care to
|
||
read it will go get it. Those that don't are (to quote myself)
|
||
"furiously hitting the page down key" to avoid it, so what's the use?
|
||
Got me.
|
||
|
||
cb> going to keep going this way. There are FIVE FSCs in this Issue.
|
||
cb> There are only sixty or so more to go. [grin]
|
||
|
||
Thanks for the warning! I guess it'll be safe to read Fidonews again
|
||
sometime after the next 13 issues if one wants to avoid them. <laugh>
|
||
|
||
cb> The software list is also an important part of the FidoNews
|
||
cb> mission and we all are indebted to Peter Popovich for the
|
||
cb> Herculean labors he
|
||
|
||
Umm, I do believe that I gave credit -and- thanks to Peter. What I
|
||
-did- say is that Peter should be given a little break, and only have
|
||
to have a listing ready monthly. That's all is really needed, since
|
||
software isn't going to change that fast, and if "Brand X" drops
|
||
support this week, waiting for a notice 3 weeks from now won't kill
|
||
anyone. (And it'll give Peter more time to get good follow up
|
||
information on these packages.)
|
||
|
||
cb> the Echomail weenies flee FidoNet
|
||
|
||
Echomail weenies? Hmmm.. I don't know what's wrong with echomail,
|
||
but you seem to not like those that use it, judging by how many times
|
||
you use this phrase in your editorial.
|
||
|
||
cb> for the apparently greener pastures of Internet mailing lists,
|
||
|
||
Funny this is here, since you're promoting a mailing list version of
|
||
Fidonews. Imagine! <laugh> Indeed, there's more -Internet- promoting
|
||
of Fidonews (in the Fidonews) than there is of promoting how to get
|
||
it via Fidonet.
|
||
|
||
cb> Those who can't, get jobs as critics. I'm doing and teaching.
|
||
|
||
Those that can't take criticism shouldn't be editors, I guess.
|
||
Sorry to see you take it so personally, and feel the need to turn to
|
||
thinly veiled insults in order to rebut what I've said, Chris.
|
||
FIDONEWS 14-06 Page 15 10 Feb 1997
|
||
|
||
|
||
Oh well. C'est la vie.
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-06 Page 16 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
GETTING TECHNICAL
|
||
=================================================================
|
||
|
||
|
||
[This is part of the continuing series of FidoNet Standards and
|
||
Proposals being published as part of the FidoNet History project. The
|
||
individual docs have been reformatted to 70 columns as required.] Ed.
|
||
|
||
|
||
Document: FSC-0034
|
||
Version: 002
|
||
Date: 30-Aug-90
|
||
|
||
Gateways to and from FidoNet <tm>
|
||
Technical, Administrative, and Policy Considerations
|
||
FSC-0034
|
||
|
||
Randy Bush 30 August 1990
|
||
|
||
Status of this document:
|
||
|
||
This FSC contains information of value to the general FidoNet(r)
|
||
community. Distribution of this document is subject to the
|
||
restrictions listed in the copyright paragraph below.
|
||
|
||
Fido and FidoNet are registered marks of Tom Jennings and Fido
|
||
Software.
|
||
|
||
Copyright 1989-90, Randy Bush. All rights reserved. A right to
|
||
distribute only without modification and only at no charge is granted.
|
||
Under no circumstance 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.
|
||
|
||
What is a Gateway to/from FidoNet?
|
||
---- -- - ------- ------- --------
|
||
|
||
A gateway is a collection of software and procedures whereby net mail
|
||
and/or echomail may be transferred between FidoNet and another
|
||
computer communications network. Gateways are bi-directional, as folk
|
||
always want to reply to others' mail.
|
||
|
||
Gateways exist now.
|
||
|
||
o There are a number of software packages for gating between uucp-
|
||
based systems and FidoNet, the most well-known beingthe UFGATE
|
||
shareware package. These packages gate both netmail and echomail,
|
||
and are often used to provide FidoNet access to/from Internet via
|
||
the uucp network. These tend to go through much effort to make
|
||
FidoNet look as much like Internet as possible. As of this
|
||
writing, about 25 uucp gateways are scattered around FidoNet.
|
||
|
||
o Rhodes University has developed a complete system between a Cyber-
|
||
based NOS network and FidoNet. This system handles both net mail
|
||
FIDONEWS 14-06 Page 17 10 Feb 1997
|
||
|
||
|
||
and echomail, and is also strongly based on the Internet
|
||
standards, and almost views FidoNet as a transport mechanism to
|
||
get to/from Internet. It is used to gate a fairly localized
|
||
cluster of mainframes to FidoNet at a single point, and has made
|
||
special arrangements for further routing and forwarding of mail.
|
||
|
||
o WWIVnet has developed gating software based on the ForDog package
|
||
for the MS-DOS-based WWIV systems, and some other package for the
|
||
Mac-based Tabby systems. The MS-DOS system uses Binkley or
|
||
another FidoNet mailer handles the protocol transfers to make the
|
||
WWIV system look like a FidoNet system to other FidoNet nodes.
|
||
WWIVnet gates are said to be scattered around the US and Canada.
|
||
|
||
o A number of FidoNet-based systems have been developed for various
|
||
flavors of UN*X. These vary from encapsulated Fido-worlds within
|
||
UN*X (i.e not true gates at all), to FidoNet front ends for UN*X
|
||
mail systems.
|
||
|
||
o RBBS-net seems to have developed gateway software for the MS-DOS-
|
||
based BBS network, but I do not know enough to characterize it.
|
||
|
||
All of these gateway systems can and are being run in a safe and
|
||
cooperative fashion, and are providing a nice cross-cultural exchange
|
||
with benefits for both sides of the gates.
|
||
|
||
At this time, there are also other nets which, because they are based
|
||
on technology similar to FidoNet, are dumping mail onto and taking
|
||
mail off of FidoNet willy nilly, with little thought to the technical,
|
||
administrative, or social consequences. Often, this is done with good
|
||
intentions, not realizing they are providing a disservice to both
|
||
nets.
|
||
|
||
What are the Characteristics of a Good Gateway?
|
||
---- --- --- --------------- -- - ---- --------
|
||
|
||
Like good contracts, good gateways should be fair to both sides.
|
||
There is the need to preserve both the technical and sociopolitical
|
||
integrity of all parties to the transaction.
|
||
|
||
Technically, both networks will have specifications and requirements
|
||
for transfer protocols, message and echomail formats, control data
|
||
files, etc. Beyond the borders of the gateway software, each universe
|
||
should be completely and safely maintained.
|
||
|
||
o Messages and echomail should completely conform in format and
|
||
content to the technical specifications of each side of the
|
||
gateway.
|
||
|
||
o Addressing of messages and echomail should completely conform to
|
||
that of the network in or through which the messages are traveling
|
||
or resident at all times.
|
||
|
||
o A normal user should be able to enter new messages destined for
|
||
the other side of the gate and to reply to gated mail with
|
||
relative ease.
|
||
|
||
FIDONEWS 14-06 Page 18 10 Feb 1997
|
||
|
||
|
||
o If FidoNet uses a network A as an intermediate to get to/from a
|
||
network B, or if network C uses FidoNet to get to/from network D,
|
||
then the inter-net transitions should be auditable, but local
|
||
customs and technalia of the intermediate network may not need
|
||
always be enforced. Socially, the customs and fashions of each
|
||
network should be maintained in that network.
|
||
|
||
o There must be administrative liaison and control between the two
|
||
networks so agreements may be made and enforced and disputes may
|
||
be adjudicated.
|
||
|
||
o If the networks being gated overlap geographically, then systems
|
||
should not have to pay significant costs to move mail between the
|
||
two networks when it is between two nodes that are in the same
|
||
general locale.
|
||
|
||
o Gating is not simple, technically or administratively. Unless
|
||
each net anticipates significant use of the gateways, and the
|
||
anticipated gain is seen as greater than the anticipated pain,
|
||
then one side or the other may reasonably decline to do the
|
||
necessary work.
|
||
|
||
What Technical Standards Exist?
|
||
---- --------- --------- ------
|
||
|
||
Before we develop new specifications, social protocols, and standards,
|
||
we should see what exists already.
|
||
|
||
o FidoNet Technical Standards exist already for the data formats and
|
||
the communication protocols for net mail and echomail. All
|
||
conforming gateway systems mentioned above conform to these
|
||
standards. These are named FSC-nnnn, or more recently FTS-nnnn.
|
||
|
||
o The SRI-NIC has published standards for message formats and
|
||
communication protocols that are used between a significant number
|
||
of networks that already gate to each other. These are often
|
||
referred to as the Internet standards and named RFCnnnn or
|
||
IDEAnnnn.
|
||
|
||
o The ISO and CCITT have standards for message formats and
|
||
communication protocols which are used between a significant
|
||
number of systems. These
|
||
are based on X.nnn specifications, eg. X.400.
|
||
|
||
Other standards undoubtedly exist and should be investigated by anyone
|
||
desiring to build a gateway system.
|
||
|
||
The game of 'my standard is better than yours' has been played for
|
||
decades with no conclusion other then demonstrating the stupidity of
|
||
war. What matters is that each net's standards are maintained within
|
||
that net.
|
||
|
||
What Administrative Standards Exist?
|
||
---- -------------- --------- ------
|
||
|
||
Most networks have formed administrative procedures and guidelines
|
||
FIDONEWS 14-06 Page 19 10 Feb 1997
|
||
|
||
|
||
which regulate if and how other networks may gate to/from them.
|
||
|
||
The most notable exception is the uucp/Usenet which, having no
|
||
formalized administrative rules for anything else, imposes none on
|
||
gateways. Before we recoil in horror, note that uucp/Usenet is three
|
||
to four times the size of FidoNet, is over twice FidoNet's age, and
|
||
has a significantly better signal-to-noise ratio.
|
||
|
||
The SRI-NIC provides a procedure for registering Internet domains. A
|
||
domain is somewhat like what we are considering a network. This
|
||
Internet registration procedure ensures that the network has
|
||
|
||
o administrative responsibility and control, and
|
||
o at least two registered sites which provide address mapping for
|
||
the netowrk being gated.
|
||
|
||
FidoNet is a registered domain of Internet. Our domain is called
|
||
fidonet.org. The administrative responsibility is the FidoNet IC's.
|
||
The registered 'nameservers' are at lynx.cs.orst.edu and
|
||
k9.cs.orst.edu, both at Oregon State University, though this is
|
||
bending the two nameserver policy a bit.
|
||
|
||
DECNET, ARPANET, ... all have applicable standards, but, as they are
|
||
strictly limited to formal commercial relationships, they are of
|
||
little interest here.
|
||
|
||
What Administrative Policies are Needed by FidoNet?
|
||
---- -------------- -------- --- ------ -- --------
|
||
|
||
What does FidoNet really need to state in terms of administrative
|
||
requirements on a network wishing to gate to/from FidoNet?
|
||
|
||
FidoNet needs a means of ensuring that a formal relationship exists
|
||
which may be used to negotiate technical standards between the two
|
||
nets, internet adjudication of disagreements both technical and
|
||
social, and enforcement of decisions. Similarly, the other network
|
||
will likely want such assurances as well. Therefore an agreement
|
||
should be reached stating:
|
||
|
||
o who is administratively responsible,
|
||
|
||
o who is technically responsible,
|
||
|
||
o what technical and administrative documentation exists, and
|
||
|
||
o both parties will abide by eachother's rules when in the other's
|
||
house, and
|
||
|
||
o how grievances are to be stated and adjudicated.
|
||
|
||
In addition, it will be advisable for FidoNet to place some
|
||
requirements on a network wishing to form official gateways. Some of
|
||
these requirements and their motivations are:
|
||
|
||
o If the other network geographically overlaps a significant portion
|
||
of FidoNet, then the other net should be of sufficient size that
|
||
FIDONEWS 14-06 Page 20 10 Feb 1997
|
||
|
||
|
||
gateways can likely be recruited in most areas where the nets
|
||
overlap. Thus, systems should not have to pay significant costs
|
||
to move mail between two nets that happen to be in the same
|
||
locale.
|
||
|
||
o If the other network geographically overlaps a significant portion
|
||
of FidoNet, then there should, at a minimum, be gateways in each
|
||
FidoNet zone where they overlap.
|
||
|
||
o If the other network geographically overlaps more than one zone of
|
||
FidoNet, then that net should have its own gateways between the
|
||
zones, and not use FidoNet to move the burden of interzone PTT
|
||
costs.
|
||
|
||
o If the other network geographically overlaps a significant number
|
||
of the regions in a FidoNet zone, then there should, at a minimum,
|
||
be gateways in each FidoNet region where they overlap.
|
||
|
||
o If the other network is geographically localized, then special
|
||
arrangements may be made whereby there traffic is gated to/from
|
||
FidoNet at one or more places by special arrangement as if the
|
||
other network were a FidoNet node or local network (in the intra-
|
||
FidoNet sense) itself.
|
||
|
||
o Gating of net mail, i.e. user-to-user messages, must be
|
||
implemented and easily used. Gating of Echomail is optional.
|
||
|
||
o Mail must be bi-directional. If someone in the other net can send
|
||
mail to a node/user on FidoNet, then that FidoNet node/user must
|
||
be able to reply.
|
||
|
||
o If echomail is gated, then, unless special circumstances are
|
||
recognized by the responsible administrators, it must be gated bi-
|
||
directionally.
|
||
|
||
o If a conference is moderated (in the Usenet sense, similar to
|
||
Dutchie's Conference Mail's moderation or GroupMail) on one
|
||
network, then it should be moderated on all other networks, or at
|
||
least the gateway into the network where it is moderated should
|
||
ensure that correct moderation is done by forwarding or whatever
|
||
is appropriate.
|
||
|
||
For inter-net gateway systems in the process of formation, it is
|
||
assumed that some of the above requirements may be waived during a
|
||
startup period at the discretion of the administrative bodies.
|
||
|
||
Observe that if FidoNet were to try to take a shortcut which has been
|
||
suggested and simply require Intetnet registration of gating networks,
|
||
then, of the current networks gating to FidoNet correctly (see above),
|
||
only the Rhodes system could conform technically. Eg. the uucp gating
|
||
packages gate to uucp which has no administrative center and is not
|
||
registered with Internet. To require Internet registration would
|
||
further neither the goals of Internet, nets wishing to gate to
|
||
FidoNet, nor FidoNet itself.
|
||
|
||
What Technical Requirements should FidoNet Place on Gating Systems?
|
||
FIDONEWS 14-06 Page 21 10 Feb 1997
|
||
|
||
|
||
---- --------- ------------ ------ ------- ----- -- ------ --------
|
||
|
||
Each network will have its own specifications for communication
|
||
protocols, data formats, message conventions, addressing, etc. Though
|
||
more generally used standards are to be preferred, what really matters
|
||
is that each net be self-consistent and integritous and that gateway
|
||
systems maintain that integrity.
|
||
|
||
From the FidoNet perspective, the following attributes of a gateway
|
||
system seem to be mandatory.
|
||
|
||
o Conformance to FidoNet message format as specified in current
|
||
FidoNet technical standards (eg. currently FSC-0001) must be
|
||
maintained while messages are within FidoNet.
|
||
|
||
o Information to assist message comprehension and processing by
|
||
gateway systems and/or other networks may be contained within the
|
||
message body, either hidden behind ^A lines or not. If such
|
||
information is needed, then conformance to current Internet
|
||
standards (eg. currently RFC822) is recommended.
|
||
|
||
o The FidoNet message header must contain valid FidoNet addresses at
|
||
all times the message is on FidoNet. Valid FidoNet addresses are
|
||
addresses of specific FidoNet nodes in the current FidoNet
|
||
nodelist.
|
||
|
||
o The source and/or destination address in the other net should be
|
||
embedded in the text body of the FidoNet message, either hidden
|
||
behind ^A lines or not. Conformance to current Internet standards
|
||
is recommended where appropriate, but addressing conventions in
|
||
the other net may preclude this.
|
||
|
||
o A message must contain sufficient information that the originating
|
||
system and user may be easily determined.
|
||
|
||
o A FidoNet sysop and/or normal FidoNet BBS user should be able to
|
||
enter messages destined for users in the other network and reply
|
||
to gated mail using current FidoNet software.
|
||
|
||
o If echomail is gated, then the echo messages should conform to all
|
||
current FidoNet standards for echomail. For example, currently an
|
||
echomail message should:
|
||
|
||
- have a correct tear line
|
||
- have an origin line of the proper format with a FidoNet origin
|
||
of the gating FidoNet node
|
||
- have seenbys of only FidoNet nodes
|
||
- have a path line that goes back at least to the gating node
|
||
|
||
o If echomail is gated, then an echomail message must contain
|
||
sufficient information that the system and user of origin may be
|
||
trivially determined, whatever net may have originated it.
|
||
|
||
o The origin of gated echomail should be determinable in a regular
|
||
way sufficient that the gating software can provide easy
|
||
construction of private net mail replies to echomail messages
|
||
FIDONEWS 14-06 Page 22 10 Feb 1997
|
||
|
||
|
||
which would return to the echo messages's originator through the
|
||
appropriate gateway, which may or may not be different than the
|
||
gateway through which the echo message came. It is acknowledged
|
||
that this may require hand editing on the part of the user
|
||
composing the reply.
|
||
|
||
o If echomail is gated, and the other net has no equivalent, it may
|
||
use net mail and/or net mail mailing lists. Messages coming into
|
||
FidoNet from this type of net mail or mailing list should properly
|
||
gate into the appropriate echomail conference, and replies should
|
||
work correctly as well.
|
||
|
||
Conclusion
|
||
----------
|
||
|
||
It is hoped that, given a philosophy and guidelines such as those
|
||
outlined in this paper, FidoNet will continue to expand its links to
|
||
other networks to the benefit of FidoNet and networking in general.
|
||
|
||
It is hoped that this paper will be of some help to those constructing
|
||
gateways to/from FidoNet, and to the administrators of FidoNet and
|
||
other nets who are considering gating to/from FidoNet.
|
||
|
||
This paper, the purported facts contained, and the philosophy espoused
|
||
are the sole responsibility of the author, and are quite likely
|
||
technically incorrect and are undoubtedly morally bankrupt. Should
|
||
you have constructive correction or criticism, please contact:
|
||
|
||
Randy Bush
|
||
FidoNet: 1:105/6 1:105/42
|
||
Internet: randy@psg.com randy@m2xenix.uucp
|
||
uucp: { uunet, qiclab, bucket }!m2xenix!randy
|
||
|
||
----------
|
||
FidoNet is a trademark of Tom Jennings and Fido Software, to whom we
|
||
all owe much thanks for the origin and spirit of FidoNet.
|
||
DECNET is a trademark of Digital Equipment Corporation.
|
||
MS-DOS is a trademark of Microsoft Corporation.
|
||
|
||
-30-
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|
||
FSC-0035
|
||
|
||
Transparent Gateways to and from FidoNet <tm>
|
||
Technical Considerations
|
||
FSC-0035
|
||
|
||
Michael Shiels 22 June 89
|
||
|
||
Copyright 1989, Michael Shiels. All rights reserved. The right to
|
||
distribute for non-commercial use is granted to the FidoNet Technical
|
||
Standards Committee, provided that no fee is charged. This may be
|
||
posted on FidoNet electronic BBSs which charge no fee for accessing
|
||
FIDONEWS 14-06 Page 23 10 Feb 1997
|
||
|
||
|
||
this document. Any and all other reproduction or excerpting requires
|
||
the explicit written consent of the author.
|
||
|
||
Gateways
|
||
--------
|
||
|
||
Gatewaying between Fidonet and other networks seems to be the latest
|
||
feature which hopefully brings more benefits to the users of each
|
||
network. But there are some real problems with gatewaying and doing
|
||
"transparent" replies. This proposal should allow for almost totally
|
||
transparent gateways but requires the co-operation of BBS software
|
||
writers to support this following protocol.
|
||
|
||
Incoming Messages
|
||
-----------------
|
||
|
||
When a message is entered into fidonet from another network it will be
|
||
entering through one machine (say 1/2). The userid on the other
|
||
network may not match very will with the 2 word 36 character userid on
|
||
Fidonet. So the following is done to store away the proper userid of
|
||
the sender.
|
||
|
||
Two (2) lines are added to the message (usually at the top of the text
|
||
portion hidden by the infamous ^A KLUDGE).
|
||
|
||
^AREPLYADDR .....\r
|
||
|
||
which signifies the FULL userid of the person on the other network.
|
||
The first 36 characters or the full userid if less than 36 characters
|
||
long, are stored in the FROM field of the message header. When
|
||
replies are done they use a second line of the following form.
|
||
|
||
^REPLYTO zone:net/node firstname lastname
|
||
|
||
which is used to signify the "userid" which mail destined to this
|
||
other network must be sent to and on which machine that userids
|
||
resides. Replies are sent to this zone:net/node and userid with the
|
||
first line of the message being changed into 'TO: ....' where .... is
|
||
the FULL userid from the ^AREPLYADDR line.
|
||
|
||
Should you have constructive correction or criticism, please contact:
|
||
|
||
Michael Shiels
|
||
FidoNet: 1:250/410 michael.shiels@masnet.fidonet.org
|
||
uucp: ?!tmsoft!masnet!michael.shiels
|
||
Internet: michael.shiels@masnet.uucp
|
||
|
||
----------
|
||
FidoNet is a trademark of Tom Jennings and Fido Software, to whom we
|
||
all owe much thanks for the origin and spirit of FidoNet.
|
||
|
||
-30-
|
||
|
||
|
||
|
||
|
||
FIDONEWS 14-06 Page 24 10 Feb 1997
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|
||
FSC-0036
|
||
|
||
GROUP MAIL SPECIFICATIONS
|
||
by Dale W. Lovell
|
||
7:41/34@alternet
|
||
1:157/504@fidonet
|
||
|
||
Group Message Files
|
||
|
||
A Group Message File is a file which contains messages for a
|
||
particular group conference. The file is named as follows:
|
||
|
||
<id>.xxx
|
||
|
||
Where:
|
||
<id> is the GroupMail ID name
|
||
xxx is the minute of the month that the last packet was added
|
||
to the file in base 36 (0..9,A..Z). The following
|
||
extensions are NOT used ARC, BAT, COM, DOC, EXE, PKT,
|
||
TXT. If a packet is created would normally have this name,
|
||
the minute is "bumped up" one to avoid using these names.
|
||
(This is also the extension used by ARCmail).
|
||
|
||
Each file can contain several packets of messages. Packets should be
|
||
in the Fido type 2 packet. The packets start off with a packet
|
||
header. Messages follow the packet header. Each message starts
|
||
off with an abbreviated packetized message header. Following the
|
||
header are several variable length fields. The structures is as
|
||
follows:
|
||
|
||
struct pkthdrs { /* packet header structure */
|
||
int ph_onode; /* Originating node number */
|
||
int ph_dnode; /* Destination node number */
|
||
int ph_yr,ph_mo,ph_dy; /* Date packet was assembled */
|
||
int ph_hr,ph_mn,ph_sec; /* Time packet was assembled */
|
||
int ph_rate; /* packet baud rate */
|
||
int ph_ver; /* packet version */
|
||
int ph_onet; /* Originating net */
|
||
int ph_dnet; /* destination net */
|
||
int ph_rsvd[17]; /* Reserved for possible future use
|
||
*/ };
|
||
|
||
struct pktmsgs { /* packetized message headers */
|
||
int pm_ver; /* message version */
|
||
int pm_onode; /* Originating node */
|
||
int pm_dnode; /* Destination node */
|
||
int pm_onet; /* Originating net */
|
||
int pm_dnet; /* Destination net */
|
||
int pm_attr; /* Message attributes */
|
||
int pm_cost; /* message cost in cents */
|
||
};
|
||
|
||
The variable length data that follows is:
|
||
FIDONEWS 14-06 Page 25 10 Feb 1997
|
||
|
||
|
||
Field Description Maximum length (in characters)
|
||
Date 20
|
||
To whom 36
|
||
Who From 36
|
||
Subject 72
|
||
Message text 8192
|
||
|
||
The packet is finished when in place of the packetized message header
|
||
there are two null characters.
|
||
|
||
Message Attributes
|
||
|
||
Message headers contain an integer field holding "message
|
||
attributes." These are bit values that select various properties of
|
||
the message. They are defined as follows:
|
||
|
||
#define MSGPRIVATE 0x0001 /* Private message */
|
||
#define MSGCRASH 0x0002 /* Crash priority message */
|
||
#define MSGREAD 0x0004 /* Read by addressee */
|
||
#define MSGSENT 0x0008 /* Sent okay */
|
||
#define MSGFILE 0x0010 /* file attached */
|
||
#define MSGFWD 0x0020 /* being forwarded */
|
||
#define MSGORPHAN 0x0040 /* Unknown destination */
|
||
#define MSGKILL 0x0080 /* Kill after mailing */
|
||
#define MSGLOCAL 0x0100 /* True if message entered here */
|
||
#define MSGHOLD 0x0200 /* true if hold for pickup */
|
||
#define MSGX2 0x0400 /* reserved -- sent */
|
||
#define MSGFREQ 0x0800 /* Requesting a file */
|
||
#define MSGRREQ 0x1000 /* Return Receipt requested */
|
||
#define MSGRRCT 0x2000 /* Return Receipt */
|
||
#define MSGAREQ 0x4000 /* Request audit trail */
|
||
#define MSGUREQ 0x8000 /* Requesting a file update */
|
||
|
||
The following attribute bits are included in the packetized message
|
||
header.
|
||
|
||
MSGPRIVATE MSGFILE MSGCRASH MSGX2 MSGRREQ
|
||
MSGRRCT MSGAREQ
|
||
|
||
All other attributes are masked off and are not sent to other systems.
|
||
|
||
Packet files names are as follows:
|
||
|
||
ddhhmmss.PKT
|
||
|
||
Where:
|
||
dd is the day of the month the packet was created
|
||
hh is the hour (24 hour clock) the packet was created
|
||
mm is the minute the packet was created
|
||
ss is the second the packet was created
|
||
|
||
For example if a GroupMail file in the conference SAMPLE is created
|
||
on the 22nd of a month at 08:15 the Groupmail name would be
|
||
SAMPLE.NPR.
|
||
|
||
21 full days 8.25 hours
|
||
FIDONEWS 14-06 Page 26 10 Feb 1997
|
||
|
||
|
||
x 1440 minutes per day x 60 minutes per hour
|
||
------- ---------
|
||
30240 minutes 495 minutes
|
||
+ 495 minutes in today
|
||
-------
|
||
30735 minutes into the month Convert to base 36: NPR
|
||
|
||
Note that at most there are 44640 minutes in a month and this naming
|
||
scheme has the capability to handle up to 46656 file names. The
|
||
remaining names (2015 files or an average of 65 files per day) may be
|
||
used for distributing other files in a conference (anything over YG0,
|
||
hint if it starts with Z it makes it easy to identify, still leaves
|
||
1296 different files or average of 41 files per day).
|
||
|
||
Disk Directories
|
||
|
||
GroupMail uses two special directories for distributing it's
|
||
files. The first of these directories contains what I will be
|
||
calling a group date file and any unprocessed, inbound group files.
|
||
The Group Date File is a zero length file in the format:
|
||
|
||
<id>.!
|
||
|
||
Where:
|
||
<id> is the Group conference name
|
||
|
||
When new files are update requested, the mailer should only obtain
|
||
those files whose time/date stamps are later than this file's
|
||
time/date stamp (or any unprocessed group files with a later time/date
|
||
stamp).
|
||
|
||
This directory will be referred to as the Group Inbound Directory.
|
||
|
||
If a system is holding any conferences for others to update
|
||
request, it will need another directory. This directory holds all
|
||
processed Group Mail Files. These files can be held for up to 31
|
||
days. After a file whose conference is being held for others is
|
||
processed, it should be moved to this directory. This move MUST
|
||
leave the time/date stamp as it was. If a system deviates this for
|
||
ANY reason WOE unto they who wrote the Group Mail processor. This
|
||
directory will be referred to as the Group Holding Directory.
|
||
|
||
Message files
|
||
|
||
In theory (and almost always in practice) you can store the
|
||
processed messages in any format you desire. New messages must be
|
||
put into your network mail area as a message your mailer can handle
|
||
and send properly to other Fido compatible bulletin board
|
||
systems/mailers. The structure of a Fido message is as follows:
|
||
|
||
struct msghdrs { /* Message header structure */
|
||
char m_from[36]; /* Who from */
|
||
char m_to[36]; /* to whom */
|
||
char m_subj[72]; /* subject of message */
|
||
char m_date[20]; /* Date of message */
|
||
int m_times; /* Number of times read */
|
||
FIDONEWS 14-06 Page 27 10 Feb 1997
|
||
|
||
|
||
int m_dnode; /* Destination node */
|
||
int m_onode; /* Originating node */
|
||
int m_cost; /* Cost of message in cents */
|
||
int m_onet; /* Originating net */
|
||
int m_dnet; /* Destination net */
|
||
int m_caca; /* extra space */
|
||
int unsigned m_rep; /* Thread to previous */
|
||
int m_attr; /* Message attributes */
|
||
int m_up; /* Thread to next */
|
||
};
|
||
|
||
The header is followed by the text of the message. This text is stored
|
||
as a string of characters ending with a null. The text may or may
|
||
not contain carriage returns, each of which may or may not be
|
||
followed by a linefeed. Any of these carriage returns may be "soft."
|
||
If the high order bit (0x80) of the carriage return is set, then it
|
||
is a soft return. Line feeds and soft returns should be ignored.
|
||
|
||
More on the actual messages later on.
|
||
|
||
Processing inbound messages
|
||
|
||
For conferences where you are NOT the top star
|
||
|
||
Unprocessed Group Message Files are in the Group Inbound
|
||
Directory. A processor should go through all Group Message Files
|
||
which are conferences that the system actually caries (as opposed
|
||
to just passing through for other systems). The file's name
|
||
should be used to determine for which conference these messages
|
||
are destined. While most processors have the first line of text
|
||
read as ^AAREA:<id> (no spaces), this is meant for compatibility
|
||
to those systems which do not yet have GROUP capabilities. In short,
|
||
YOU CAN NOT DEPEND ON IT BEING THERE, so USE THE FILENAME. The
|
||
packets should be extracted from the archived message file, put into
|
||
your message base. The packet files should then be deleted.
|
||
Messages put into your message base from these Group Message Files
|
||
should be marked in some way so that they are not processed as
|
||
newly entered messages. SEA's GROUP utility uses the message sent
|
||
flag for this purpose and we recommend the use of the same flag
|
||
wherever possible.
|
||
|
||
After all Group Message Files have been processed, the Group Date
|
||
Files should have their time/date stamp changed to that of the most
|
||
recent file processed. Any Group Message Files for conferences
|
||
being held for other systems should be moved to the Group Holding
|
||
Directory so other systems can request these files. When the Group
|
||
Message File is moved, the time/date stamp on the file MUST NOT be
|
||
changed. Group Message Files for conferences not being held for
|
||
others should be deleted.
|
||
|
||
It is also desirable at this time to delete any Group Message Files
|
||
which are over one month old, or whatever period of time less than
|
||
one month the system operator of that board desires.
|
||
|
||
For conferences where you ARE the top star
|
||
|
||
FIDONEWS 14-06 Page 28 10 Feb 1997
|
||
|
||
|
||
You should check for any new netmail messages whose ^AAREA:<id>
|
||
line is "your" conference ID. These messages should be imported into
|
||
your message base with the message sent flag (or your own
|
||
equivalent) turned OFF. At such a time as you "PACK" new Group
|
||
Message Files you should turn the sent flag ON.
|
||
|
||
Processing new outbound messages
|
||
|
||
For conferences where you ARE NOT the top star
|
||
|
||
Your group processor should scan through all group conferences
|
||
on the system and locate any messages which have been entered.
|
||
These messages should be prepared to be sent out via network mail.
|
||
The first line of the network mail message should read:
|
||
|
||
^AAREA:<id>
|
||
|
||
Where:
|
||
<id> is the Group conference name
|
||
|
||
There should be no spaces in this area, although your processor
|
||
should be tolerant of any spaces if they are present.
|
||
|
||
The message should be "from" your address and addressed to your upward
|
||
link in the conference. In addition the message should be
|
||
marked to be deleted/killed after being sent.
|
||
|
||
You should also check to see if any messages in your netmail area
|
||
from other systems are for a GroupMail conference (either one you
|
||
carry, or pass on to other systems). Any of these messages should be
|
||
readdressed to your upward link in the conference. Under no
|
||
circumstances should you change the from fields, they should contain
|
||
the address of the person who entered the message into the
|
||
conference.
|
||
|
||
For conferences where you ARE the top star
|
||
|
||
Messages should be "copied" from your message base into a properly
|
||
named Group Message File. This Group Message File must have a
|
||
correct time/date stamp and be in your Group Holding Directory.
|
||
Once a message has been copied into a Group Message File, it is
|
||
necessary to mark it so the same message is not placed into another
|
||
Group Message File. SEA's GROUP uses the message sent flag for this
|
||
purpose and we recommend the use of the same flag whenever
|
||
possible.
|
||
|
||
I think that's it. Everything else is handled by your mailer. In
|
||
order to get new Group Mail messages, you do a file update request
|
||
of the GROUP conference name (<id>.*) with the update pointing to
|
||
your Group Inbound Directory. Your mailer will then get any new
|
||
Group Message Files from your upward link in the conference. As new
|
||
Group Message Files are processed, those who are obtaining their
|
||
conferences from you will perform file update requests from your Group
|
||
Holding Directory.
|
||
|
||
-30-
|
||
FIDONEWS 14-06 Page 29 10 Feb 1997
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-06 Page 30 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
COORDINATORS CORNER
|
||
=================================================================
|
||
|
||
|
||
Nodelist-statistics as seen from Zone-2 for day 038
|
||
By Ward Dossche, 2:292/854
|
||
ZC/2
|
||
|
||
+----+------+------------+------------+------------+------------+--+
|
||
|Zone|Nl-010|Nodelist-017|Nodelist-024|Nodelist-031|Nodelist-038|%%|
|
||
+----+------+------------+------------+------------+------------+--+
|
||
| 1 | 10370|10177 -193 |10063 -114 | 9877 -186 | 9729 -148 |34|
|
||
| 2 | 15979|15936 -43 |15938 2 |16078 140 |16067 -11 |57|
|
||
| 3 | 868| 865 -3 | 863 -2 | 863 0 | 863 0 | 3|
|
||
| 4 | 554| 553 -1 | 558 5 | 550 -8 | 549 -1 | 2|
|
||
| 5 | 93| 93 0 | 93 0 | 87 -6 | 87 0 | 0|
|
||
| 6 | 1073| 1073 0 | 1072 -1 | 1072 0 | 1072 0 | 4|
|
||
+----+------+------------+------------+------------+------------+--+
|
||
| 28937|28697 -240 |28587 -110 |28527 -60 |28367 -160 |
|
||
+------+------------+------------+------------+------------+
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-06 Page 31 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
NET HUMOR
|
||
=================================================================
|
||
|
||
|
||
From: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
|
||
To: "Baker, Christopher" <cbaker84@digital.net (Christopher Baker)>,
|
||
Date: Thu, 30 Jan 97 17:10:22 -0600
|
||
Reply-To: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
|
||
Subject: From another list....
|
||
|
||
Famous answers to : "Why did the chicken cross the road?"
|
||
-----------------------------------------------------
|
||
|
||
Plato:
|
||
For the greater good.
|
||
|
||
Karl Marx:
|
||
It was a historical inevitability.
|
||
|
||
Thomas de Torquemada:
|
||
Give me ten minutes with the chicken and I'll find out.
|
||
|
||
Timothy Leary:
|
||
Because that's the only kind of trip the Establishment would
|
||
let it take.
|
||
|
||
Douglas Adams:
|
||
Forty-two.
|
||
|
||
Nietzsche:
|
||
Because if you gaze too long across the Road, the Road gazes
|
||
also across you.
|
||
|
||
Oliver North:
|
||
National Security was at stake.
|
||
|
||
Carl Jung:
|
||
The confluence of events in the cultural gestalt necessitated
|
||
that individual chickens cross roads at this historical
|
||
juncture, and therefore synchronicitously brought such
|
||
occurrences into being.
|
||
|
||
Jean-Paul Sartre:
|
||
In order to act in good faith and be true to itself, the
|
||
chicken found it necessary to cross the road.
|
||
|
||
Ludwig Wittgenstein:
|
||
The possibility of "crossing" was encoded into the objects
|
||
"chicken" and "road," and circumstances came into being which
|
||
caused the actualization of this potential occurrence.
|
||
|
||
Albert Einstein:
|
||
Whether the chicken crossed the road or the road crossed the
|
||
chicken depends upon your frame of reference.
|
||
|
||
FIDONEWS 14-06 Page 32 10 Feb 1997
|
||
|
||
|
||
Aristotle:
|
||
To actualize its potential.
|
||
|
||
Buddha:
|
||
If you ask this question, you deny your own chicken-nature.
|
||
|
||
Salvador Dali:
|
||
The Fish.
|
||
|
||
Darwin:
|
||
It was the logical next step after coming down from the trees.
|
||
|
||
Emily Dickinson:
|
||
Because it could not stop for death.
|
||
|
||
Epicurus:
|
||
For fun.
|
||
|
||
Ralph Waldo Emerson:
|
||
It didn't cross the road; it transcended it.
|
||
|
||
Johann Friedrich von Goethe:
|
||
The eternal hen-principle made it do it.
|
||
|
||
Ernest Hemingway:
|
||
To die. In the rain.
|
||
|
||
Werner Heisenberg:
|
||
We are not sure which side of the road the chicken was on, but
|
||
it was moving very fast.
|
||
|
||
David Hume:
|
||
Out of custom and habit.
|
||
|
||
Saddam Hussein:
|
||
This was an unprovoked act of rebellion and we were quite
|
||
justified in dropping 50 tons of nerve gas on it.
|
||
|
||
Jack Nicholson:
|
||
'cause it (censored) wanted to. That's the (censored) reason.
|
||
|
||
Pyrrho the Skeptic:
|
||
What road?
|
||
|
||
Ronald Reagan:
|
||
I forget.
|
||
|
||
John Sununu:
|
||
The Air Force was only too happy to provide the transportation,
|
||
so quite understandably the chicken availed himself of the
|
||
opportunity.
|
||
|
||
The Sphinx:
|
||
You tell me.
|
||
|
||
Sappho:
|
||
FIDONEWS 14-06 Page 33 10 Feb 1997
|
||
|
||
|
||
Due to the loveliness of the hen on the other side, more fair
|
||
than all of Hellas' fine armies.
|
||
|
||
Henry David Thoreau:
|
||
To live deliberately ... and suck all the marrow out of life.
|
||
|
||
Mark Twain:
|
||
The news of its crossing has been greatly exaggerated.
|
||
|
||
Stephen Jay Gould:
|
||
It is possible that there is a sociobiological explanation for
|
||
it, but we have been deluged in recent years with
|
||
sociobiological stories despite the fact that we have little
|
||
direct evidence about the genetics of behavior, and we do not
|
||
know how to obtain it for the specific behaviors that figure
|
||
most prominently in sociobiological speculation.
|
||
|
||
Joseph Stalin:
|
||
I don't care. Catch it. Crack its eggs to make my omelette.
|
||
|
||
Captain James T. Kirk:
|
||
To boldly go where no chicken has gone before.
|
||
|
||
Machiavelli:
|
||
So that its subjects will view it with admiration, as a chicken
|
||
which has the daring and courage to boldly cross the road, but
|
||
also with fear, for whom among them has the strength to contend
|
||
with such a paragon of avian virtue? In such a manner is the
|
||
princely chicken's dominion maintained.
|
||
|
||
Hippocrates:
|
||
Because of an excess of pleghm in its pancreas.
|
||
|
||
Peter Hutton:
|
||
Because it was cheaper for the company on the other side of
|
||
the road.
|
||
|
||
Patrick Beauvillard:
|
||
Sheeken? What Sheeken?
|
||
|
||
Sacha Mateescu:
|
||
A chicken resource of that particular skillset was needed on
|
||
the other side of the road.
|
||
|
||
Andersen Consultant:
|
||
Deregulation of the chicken's side of the road was threatening
|
||
its dominant market position. The chicken was faced with
|
||
significant challenges to create and develop the competencies
|
||
required for the newly competitive market. Andersen
|
||
Consulting, in a partnering relationship with the client,
|
||
helped the chicken by rethinking its physical distribution
|
||
strategy and implementation processes. Using the Poultry
|
||
Integration Model (PIM) Andersen helped the chicken use its
|
||
skills, methodologies, knowledge capital and experiences to
|
||
align the chicken's people, processes and technology in support
|
||
of its overall strategy within a Program Management framework.
|
||
FIDONEWS 14-06 Page 34 10 Feb 1997
|
||
|
||
|
||
Andersen Consulting convened a diverse cross-spectrum of road
|
||
analysts and best chickens along with Andersen consultants with
|
||
deep skills in the transportation industry to engage in a
|
||
two-day itinerary of meetings in order to leverage their
|
||
personal knowledge capital, both tacit and explicit, and to
|
||
enable them to synergize with each other in order to achieve
|
||
the implicit goals of delivering and successfully architecting
|
||
and implementing an enterprise-wide value framework across the
|
||
continuum of poultry cross-median processes. The meeting was
|
||
held in a park like setting enabling and creating an impactful
|
||
environment which was strategically based, industry-focused,
|
||
and built upon a consistent, clear, and unified market message
|
||
and aligned with the chicken's mission, vision, and core
|
||
values. This was conducive towards the creation of a total
|
||
business integration solution. Andersen Consulting helped the
|
||
chicken change to become more successful.
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-06 Page 35 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
NOTICES
|
||
=================================================================
|
||
|
||
Future History
|
||
|
||
16 Feb 1997
|
||
Eleventh Anniversary of invention of Echomail by Jeff Rush.
|
||
|
||
29 Feb 1997
|
||
Nothing will happen on this day.
|
||
|
||
17 May 1997
|
||
Independence Day, Norway.
|
||
|
||
25 May 1997
|
||
Independence Day, Argentina.
|
||
|
||
6 Jun 1997
|
||
National Commemoration Day, Sweden.
|
||
|
||
11 Jun 1997
|
||
Independence Day, Russia.
|
||
|
||
1 Jul 1997
|
||
Canada Day - Happy Birthday Canada.
|
||
|
||
13 Oct 1997
|
||
Thanksgiving Day, Canada.
|
||
|
||
1 Dec 1997
|
||
World AIDS Day.
|
||
|
||
10 Dec 1997
|
||
Nobel Day, Sweden.
|
||
|
||
12 Jan 1998
|
||
HAL 9000 is one year old today.
|
||
|
||
22 May 1998
|
||
Expo '98 World Exposition in Lisbon (Portugal) opens.
|
||
|
||
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.
|
||
|
||
1 Jan 2000
|
||
The 20th Century, C.E., is still taking place thru 31 Dec.
|
||
|
||
15 Sep 2000
|
||
Sydney (Australia) Summer Olympiad opens.
|
||
|
||
1 Jan 2001
|
||
FIDONEWS 14-06 Page 36 10 Feb 1997
|
||
|
||
|
||
This is the actual start of the new millennium, C.E.
|
||
|
||
-- If YOU have something which you would like to see in this
|
||
Future History, please send a note to the FidoNews Editor.
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-06 Page 37 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
FIDONET SOFTWARE LISTING
|
||
=================================================================
|
||
|
||
|
||
Latest Greatest Software Versions
|
||
by Peter E. Popovich, 1:363/264
|
||
|
||
Things over here have been chaotic, so I haven't been able to
|
||
reply to my e-mails. I'll be catching up this coming week.
|
||
|
||
Phased out this week: WildCat! 3.02 and XBBS 1.77
|
||
|
||
Phase-out highlights:
|
||
This week: "Tandy Color Computer 3 (OS-9 Level II)" Section
|
||
Deadline for info: 21 Feb 1997.
|
||
Last week: "Xenix/Unix 386 -- Other Utilities" Section
|
||
Deadline for info: 14 Feb 1997.
|
||
|
||
-=- 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.40 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
|
||
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
|
||
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP
|
||
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_DOS
|
||
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
|
||
CheckPnt 1.0 O G Michiel van der Vlist
|
||
2:500/9 CHECKPNT
|
||
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FASTECHO
|
||
FastEcho/16 1.45a T S Tobias Burchhardt 2:2448/400 FE16
|
||
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
|
||
FIDONEWS 14-06 Page 38 10 Feb 1997
|
||
|
||
|
||
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
|
||
GoldED 2.50 O S Len Morgan 1:203/730 GED
|
||
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
|
||
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
|
||
Imail 1.75 T S Michael McCabe 1:1/121 IMAIL
|
||
ImCrypt 1.04 O G Michiel van der Vlist
|
||
2:500/9 IMCRYPT
|
||
InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL
|
||
InfoMail/386 1.20 O F Damian Walker 2:2502/666 INFO386
|
||
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
|
||
IPNet 1.11 O S Michele Stewart 1:369/21 IPNET
|
||
JD's CBV 1.4 O S John Dailey 1:363/277 CBV
|
||
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
|
||
JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H
|
||
JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G
|
||
MakePl 1.9 N G Michiel van der Vlist
|
||
2:500/9 MAKEPL
|
||
Marena 1.1 beta O G Michiel van der Vlist
|
||
2:500/9 MARENA
|
||
Maximus 3.01 B P Tech 1:249/106 MAX
|
||
McMail 1.0 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 G Michiel van der Vlist
|
||
2:500/9 PCMERGE
|
||
PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.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.4 O S Gary Petersen 1:290/111 SXR44.ZIP
|
||
Spitfire 3.51 B S Mike Weaver 1:3670/3 SPITFIRE
|
||
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
|
||
WaterGate 0.92 G S Robert Szarka 1:320/42 WTRGATE
|
||
WWIV 4.24a B S Craig Dooley 1:376/126 WWIV
|
||
WWIVTOSS 1.30 T S Craig Dooley 1:376/126 WWIVTOSS
|
||
xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL
|
||
XRobot 3.01 O S JoHo 2:201/330 XRDOS
|
||
|
||
OS/2:
|
||
Program Name Version F C Contact Name Node Magic Name
|
||
----------------------------------------------------------------------
|
||
ALLFIX/2 1.10 T S Harald Harms 2:281/415 AFIXOS2
|
||
FIDONEWS 14-06 Page 39 10 Feb 1997
|
||
|
||
|
||
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
|
||
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
|
||
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP
|
||
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2
|
||
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
|
||
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2
|
||
FleetStreet 1.18 O S Michael Hohner 2:2490/2520 FLEET
|
||
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
|
||
GoldED 2.50 O S Len Morgan 1:203/730 GEO
|
||
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
|
||
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
|
||
ImCrypt 1.04 O G 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 G 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
|
||
FrontDoor APX 1.10 P S Mats Wallin 2:201/329 FDAPXW
|
||
|
||
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
|
||
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
|
||
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BW32_260.ZIP
|
||
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
|
||
GoldED 2.50 O S Len Morgan 1:203/730 GEO
|
||
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
|
||
Maximus 3.01 B P Tech 1:249/106 MAXN
|
||
Msged/NT 4.00 O G Andrew Clarke 3:635/728 MSGNT400.ZIP
|
||
PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO
|
||
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAILNT
|
||
WinFOSSIL/95 1.12 r4 F S Bryan Woodruff 1:343/294 WNFOSSIL.ZIP
|
||
WinFOSSIL/NT 1.0 beta F S Bryan Woodruff 1:343/294 NTFOSSIL.ZIP
|
||
|
||
Unix:
|
||
Program Name Version F C Contact Name Node Magic Name
|
||
----------------------------------------------------------------------
|
||
ifmail 2.8g M G Eugene Crosser 2:293/2219 IFMAIL
|
||
ifmail-tx ...tx7.8 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
|
||
----------------------------------------------------------------------
|
||
FIDONEWS 14-06 Page 40 10 Feb 1997
|
||
|
||
|
||
CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL
|
||
CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK
|
||
DLG Pro BBOS 1.15 B C Holly Sullivan 1:202/720 DLGDEMO
|
||
GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS
|
||
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
|
||
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
|
||
|
||
Atari:
|
||
Program Name Version F C Contact Name Node Magic Name
|
||
----------------------------------------------------------------------
|
||
BinkleyTerm/ST 3.18pl1 M F Bill Scull 1:363/112 BINKLEY
|
||
|
||
Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
|
||
C-Compression, F-Fossil, 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 Other Utilities Other Utilities
|
||
-------------- Name Version Name Version
|
||
-------------------- --------------------
|
||
Network Mailers 2DAPoint 1.50* Netsex 2.00b
|
||
Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35
|
||
-------------------- ARCAsim 2.31 Oliver 1.0a
|
||
D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02
|
||
Dreamer 1.06 Areafix 1.20 PKInsert 7.10
|
||
Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a
|
||
Milqtoast 1.00 Crossnet 1.5 QM 1.00a
|
||
PreNM 1.48 DOMAIN 1.42 QSort 4.04
|
||
SEAdog 4.60 DEMM 1.06 RAD Plus 2.11
|
||
SEAmail 1.01 DGMM 1.06 Raid 1.00
|
||
TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0
|
||
EEngine 0.32 ScanToss 1.28
|
||
Compression EMM 2.11* ScMail 1.00
|
||
Utilities EZPoint 2.1 ScEdit 1.12
|
||
Name Version FGroup 1.00 Sirius 1.0x
|
||
-------------------- FidoPCB 1.0s@ SLMail 2.15C
|
||
ARC 7.12 FNPGate 2.70 StarLink 1.01
|
||
ARJ 2.20 GateWorks 3.06e TagMail 2.41
|
||
LHA 2.13 GMail 2.05 TCOMMail 2.2
|
||
PAK 2.51 GMD 3.10 Telemail 1.5*
|
||
PKPak 3.61 GMM 1.21 TGroup 1.13
|
||
PKZip 1.10 GROUP 2.23 TIRES 3.11
|
||
GUS 1.40 TMail 1.21
|
||
NodeList Utilities Harvey's Robot 4.10 TosScan 1.00
|
||
Name Version HeadEdit 1.18 UFGATE 1.03
|
||
-------------------- HLIST 1.09 VPurge 4.09e
|
||
EditNL 4.00 ISIS 5.12@ WEdit 2.0@
|
||
FDND 1.10 Lola 1.01d WildMail 2.00
|
||
MakeNL 2.31 Mosaic 1.00b WMail 2.2
|
||
Parselst 1.33 MailBase 4.11a@ WNode 2.1
|
||
Prune 1.40 MSG 4.5* XRS 4.99
|
||
FIDONEWS 14-06 Page 41 10 Feb 1997
|
||
|
||
|
||
SysNL 3.14 MsgLnk 1.0c XST 2.3e
|
||
XlatList 2.90 MsgMstr 2.03a YUPPIE! 2.00
|
||
XlaxNode/Diff 2.53 MsgNum 4.16d ZmailH 1.25
|
||
MSGTOSS 1.3 ZSX 2.40
|
||
|
||
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|
||
|
||
OS/2 Systems
|
||
------------
|
||
Other Utilities Other Utilities
|
||
BBS Software Name Version Name Version
|
||
Name Version -------------------- --------------------
|
||
-------------------- ARC 7.12 oMMM 1.52
|
||
Kitten 1.01 ARC2 6.01 Omail 3.1
|
||
SimplexBBS 1.04.02+ 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(S) 2.50 LH2 2.11 Raid 1.0
|
||
BinkleyTerm/2-MT MSG 4.2 Remapper 1.2
|
||
1.40.02 MsgLink 1.0c Tick 2.0
|
||
SEAmail 1.01 MsgNum 4.16d VPurge 4.09e
|
||
|
||
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|
||
|
||
Xenix/Unix 386 Other Utilities
|
||
-------------- Name Version
|
||
--------------------
|
||
BBS Software Network Mailers ARC 5.21
|
||
Name Version Name Version C-LHARC 1.00
|
||
-------------------- -------------------- MSGLINK 1.01
|
||
oMMM 1.42
|
||
Omail 1.00
|
||
|Contact: Willy Paine 1:343/15,| ParseLst 1.32
|
||
|or Eddy van Loo 2:285/406 | Unzip 3.10
|
||
VPurge 4.08
|
||
Zoo 2.01
|
||
|
||
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|
||
|
||
BBS Software Macintosh Other Software
|
||
Name Version --------- Name Version
|
||
-------------------- --------------------
|
||
FBBS 0.91 Network Mailers MacArd 0.04
|
||
Hermes 1.6.1 Name Version Mantissa 3.21
|
||
Mansion 7.15 -------------------- Mehitable 2.0
|
||
Precision Sys. 0.95b Copernicus 1.0 OriginatorII 2.0
|
||
Red Ryder Host 2.1 Tabby 2.2 PreStamp 3.2
|
||
Telefinder Host StuffIt Classic 1.6
|
||
2.12T10 Other Software SunDial 3.2
|
||
Name Version TExport 1.92
|
||
-------------------- TimeStamp 1.6
|
||
Point System ArcMac 1.3 TImport 1.92
|
||
Software AreaFix 1.6 Tset 1.3
|
||
Name Version Compact Pro 1.30 TSort 1.0
|
||
FIDONEWS 14-06 Page 42 10 Feb 1997
|
||
|
||
|
||
-------------------- EventMeister 1.0 UNZIP 1.02c
|
||
Copernicus 1.00 Export 3.21 Zenith 1.5
|
||
CounterPoint 1.09 Import 3.2 Zip Extract 0.10
|
||
MacWoof 1.1 LHARC 0.41
|
||
|
||
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|
||
|
||
Amiga Network Mailers Other Software
|
||
----- Name Version Name Version
|
||
-------------------- --------------------
|
||
BBS Software BinkleyTerm 1.00 Areafix 1.48
|
||
Name Version TrapDoor 1.80 AReceipt 1.5
|
||
-------------------- WelMat 0.44 ChameleonEdit 0.11
|
||
4D-BBS 1.65 ConfMail 1.12
|
||
Falcon CBCS 1.00 ElectricHerald 1.66
|
||
Starnet 1.0q@ Compression FFRS 1.0@
|
||
TransAmiga 1.07 Utilities FileMgr 2.08
|
||
XenoLink 1.0 Name Version Fozzle 1.0@
|
||
-------------------- Login 0.18
|
||
AmigArc 0.23 MessageFilter 1.52
|
||
NodeList Utilities booz 1.01 Message View 1.12
|
||
Name Version LHARC 1.30 oMMM 1.50
|
||
-------------------- LhA 1.10 PolyXAmy 2.02
|
||
ParseLst 1.66 LZ 1.92 RMB 1.30
|
||
Skyparse 2.30 PkAX 1.00 Roof 46.15
|
||
TrapList 1.40 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
|
||
|
||
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|
||
|
||
BBS Software Atari ST/TT
|
||
Name Version -----------
|
||
--------------------
|
||
FIDOdoor/ST 2.5.1 Network Mailers Other Utilities
|
||
FiFo 2.1v Name Version Name Version
|
||
LED ST 1.00 -------------------- --------------------
|
||
QuickBBS/ST 1.06* The Box 1.95* ApplyList 1.00@
|
||
Burep 1.1
|
||
Compression ComScan 1.04
|
||
Utilities NodeList Utilities ConfMail 4.10
|
||
Name Version Name Version Echoscan 1.10
|
||
-------------------- -------------------- FDrenum 2.5.2
|
||
ARC 6.02 ParseList 1.30 FastPack 1.20
|
||
LHARC 2.01i EchoFix 1.20 Import 1.14
|
||
PackConvert sTICK/Hatch 5.50 oMMM 1.40
|
||
STZip 1.1* Pack 1.00
|
||
UnJARST 2.00 Trenum 0.10
|
||
WhatArc 2.02
|
||
|
||
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|
||
|
||
Tandy Color Computer 3 (OS-9 Level II) Other Utilities
|
||
-------------------------------------- Name Version
|
||
FIDONEWS 14-06 Page 43 10 Feb 1997
|
||
|
||
|
||
--------------------
|
||
BBS Software Compression Utility Ascan 1.2
|
||
Name Version Name Version AutoFRL 2.0
|
||
-------------------- -------------------- Bundle 2.2
|
||
RiBBS 2.02+ Ar 1.3 CKARC 1.1
|
||
DeArc 5.12 EchoCheck 1.01
|
||
OS9Arc 1.0 FReq 2.5a
|
||
UnZip 3.10 LookNode 2.00
|
||
UnLZH 3.0 ParseLST
|
||
PReq 2.2
|
||
RList 1.03
|
||
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 14-06 Page 44 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
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!
|
||
|
||
mQCNAzINVLcAAAEEAM5dZN6t6j5Yc0kl7qegVFfiBeVoteuhDg4ay8h43u38Q4kO
|
||
eJ9Mm7J89wXFb9vgouBVb4biIN6bTWCwcXTbGhBe5OIceLvluuxuEKsaIs/UwXNe
|
||
Ogx5azIPhRfC7MJDe41Z8tMEBuHY/NE88cuxQ8yXWO126IRttavu6L/U5BwRAAUR
|
||
tCRGaWRvTmV3cyBFZGl0b3IgPDE6MS8yM0BmaWRvbmV0Lm9yZz6JAJUDBRAyGwFS
|
||
JZMgw7eCKz0BAZl0A/9xrfhpsEOqGiPfjy2qd9dv6tvSVPPVFu+Wy1lGTHYtuTtg
|
||
FIN3fQ47AM3XzqHxWRWvp/xZYgR6sRICL7UFx94ShYBQc7CyqBBZKA0IvIWqXP/g
|
||
c4Br+gQJR6CLiQK7TUyjUbqNbs6QAxuNUi4xFQM+O2Gene5/iTjHFmmSDj2C9YkB
|
||
FQMFEDIOmHDTQ6/52IG1SQEBQ78H/Rz/mleIrtZwFIOhzy3JH4Z6FUTfZuM9nPcs
|
||
1ZLjZCPptHvY7wEYJWGr03lPPJ6tj1VBXwTrWJTf/hOLsoi00GKV8t1thjqGDo23
|
||
O91/bSQ+Vn0vBQ2vOEJys8ftxdoLJAyI5YLzHVT+RsMTQLIXVuPyrNcKs1vC2ql+
|
||
UDHpU1R+9cG9JUEHpGI6z0DPnQ74SKbQH3fiVBpHhYx4BmvcBC4gWQzKMkDWFiq3
|
||
8AssIZ7b9lWl3OBgQ4UM1OIDKoJyjRewIdKyl7zboKSt6Qu8LrcsXO3kb81YshOW
|
||
ZpSS3QDIqfZC4+EElnB15l4RcVwnPHBaQY0FxUr4Vl4UWM36jbuJAJUDBRAyDpgY
|
||
q+7ov9TkHBEBAQGoA/sFfN07IFQcir456tJfBfB9R5Z6e6UKmexaFhWOsLHqbCq6
|
||
3FGXDLeivNn6NTz81QeqLIHglTuM3NP1mu8sw215klAG8G3M1NA2xLw7Eqhspze2
|
||
raGvNeEwxl8e+PY9aZwBj4UWU+CmIm6QNiP0MtvR7QYDIKn5mZCDc3CLmr942IkB
|
||
FQMFEDIOh0O8AhTPqRipPQEB4EYH/1gkDmdHL6lbEkFuQLrylF+weBl0XQ+kv7ER
|
||
vWXYrvIrkppxtc4VAge6CXXEbOGJnvkFHgyNZzO9Q9O64QsmZvjip+4lhDLeNrdH
|
||
X9DizS4YKXxkSKr9Yltmn2/AlBCx6jwcDIfkqy/P1tNWcikxZZMd6KryK0Wsres9
|
||
Ik12OmVmJjQSxb5bS6Q8aYUbV3qwosGXTqy+BzYh/UYAX/XJIWa5kxFVSPKFSZ+5
|
||
toiSzANd9SpHPEogGvQDHJlJ23lmsMx/6uHsR1LTsQ8su8zIk92XyqePJTjlMx2j
|
||
D7KJWNR7Zzu4QHCXBkga5W8l2FfPk7D3+o7bXTLRuR1yTYGdNoiJAJUCBRAyDhwt
|
||
SlKLwP4OFW0BAdaMA/9rcWQlSq44K9JuJ7fZUgt9fwxGreTud9fC8DvlbUW79+CA
|
||
AHLTLLagcEF1OKsWzVBWcA2JEAp+TUTqktRN0oD8vnaw3uNJd1G5KK59hw0WR8x1
|
||
v4ivypbSjiq95Y3gBunb7WjpyiFRWDlm0PrKrWHtbWzjnpPIpetln1UuqsSfbokB
|
||
FQIFEDIOG9C3N61ZQ4Dr/QEBIzMH/1VxxztmBPBszbjZLDO8Svcax9Ng8IcWpcDy
|
||
WqHCAA2Hoe5VtMD0v6w31ZgVqTPIvCark2Y/aTR1GofiuN9NUqbVV534AgAYLzYk
|
||
DMT1swsPvqDTpOYgQl6PCGh6A5JGAbWJfKkX9XCUHJAAmiTsEVRNnjOgL+p6qjoh
|
||
EfIG8CGehghWSRKl5eGeDAtbXupZKNjFI1t2XV+ks0RFQ/RPuTH7pF7pk7WO6Cyg
|
||
+Dk2ZMgua0HRL1fXvHKb5Xzr3MVgsbAl5gP8ooIiD9MI/x5Irh3oo58VyoEZNBs/
|
||
Kz+drGFDPljcS6fdiVCFtYIzMrshY6YsfLi0aB8fwOvFtxgBqli0J0NocmlzdG9w
|
||
aGVyIEJha2VyIDwxOjE4LzE0QGZpZG9uZXQub3JnPrQoQ2hyaXN0b3BoZXIgQmFr
|
||
ZXIgPGNiYWtlcjg0QGRpZ2l0YWwubmV0Pg==
|
||
=61OQ
|
||
-----END PGP PUBLIC KEY BLOCK-----
|
||
|
||
|
||
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. The FidoNews key is also available on
|
||
the FidoNews homepage listed in the Masthead information.
|
||
|
||
-----------------------------------------------------------------
|
||
FIDONEWS 14-06 Page 45 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
FIDONET BY INTERNET
|
||
=================================================================
|
||
|
||
This is a list of all FidoNet-related sites reported to the Editor as
|
||
of this appearance.
|
||
|
||
============
|
||
|
||
FidoNet:
|
||
|
||
Homepage http://www.fidonet.org
|
||
FidoNews http://ddi.digital.net/~cbaker84/fidonews.html
|
||
HTML FNews http://www.geocities.com/Athens/6894/
|
||
WWW sources http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
|
||
FTSC page http://www2.blaze.net.au/ftsc.html
|
||
Echomail http://www.portal.ca/~awalker/index.html
|
||
WebRing http://ddi.digital.net/~cbaker84/fnetring.html
|
||
|
||
============
|
||
|
||
Zone 1: http://www.z1.fidonet.org
|
||
|
||
Region 10:
|
||
http://www.psnw.com/~net205/region10.html
|
||
http://www.dharmanet.org/BDO/net125.html
|
||
|
||
Region 15:
|
||
http://www.smrtsys.com/region15/
|
||
|
||
Region 17:
|
||
http://www.portal.ca/~awalker/region17.htm
|
||
|
||
Region 18:
|
||
http://www.citicom.com/fido.html
|
||
|
||
Region 19:
|
||
http://ccove.n-link.com/
|
||
|
||
============
|
||
|
||
Zone 2: http://www.z2.fidonet.org
|
||
ZEC2 http://fidoftp.paralex.co.uk/zec.htm
|
||
|
||
Region 29: http://www.rtfm.be/fidonet/ (in French)
|
||
Region 36: http://www.geocities.com/SiliconValley/7207/
|
||
|
||
============
|
||
|
||
Zone 3: http://www.z3.fidonet.org
|
||
|
||
============
|
||
|
||
Zone 4:
|
||
|
||
============
|
||
FIDONEWS 14-06 Page 46 10 Feb 1997
|
||
|
||
|
||
Zone 5:
|
||
|
||
============
|
||
|
||
Zone 6: http://www.z6.fidonet.org
|
||
|
||
============
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-06 Page 47 10 Feb 1997
|
||
|
||
|
||
=================================================================
|
||
FIDONEWS INFORMATION
|
||
=================================================================
|
||
|
||
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------
|
||
|
||
Editor: Christopher Baker
|
||
|
||
Editors Emeritii: Thom Henderson, Dale Lovell,
|
||
Vince Perriello, Tim Pozar,
|
||
Tom Jennings, Sylvia Maxwell,
|
||
Donald Tees
|
||
|
||
"FidoNews Editor"
|
||
FidoNet 1:1/23
|
||
BBS 1-904-409-7040, 300/1200/2400/14400/V.32bis/HST(ds)
|
||
|
||
more addresses:
|
||
Christopher Baker -- 1:18/14, cbaker84@digital.net
|
||
cbaker84@aol.com
|
||
cbaker84@msn.com
|
||
cbak.rights@opus.global.org
|
||
|
||
(Postal Service mailing address)
|
||
FidoNews Editor
|
||
P.O. Box 471
|
||
Edgewater, FL 32132-0471
|
||
U.S.A.
|
||
|
||
|
||
voice: 1-904-409-3040 [1400-2100 ET only, please]
|
||
[1800-0100 UTC/GMT]
|
||
|
||
------------------------------------------------------
|
||
|
||
FidoNews is published weekly by and for the members of the FIDONET
|
||
INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation
|
||
of individual articles contributed by their authors or their
|
||
authorized agents. The contribution of articles to this compilation
|
||
does not diminish the rights of the authors. OPINIONS EXPRESSED in
|
||
these articles ARE THOSE OF THE AUTHORS and not necessarily those of
|
||
FidoNews.
|
||
|
||
Authors retain copyright on individual works; otherwise FidoNews is
|
||
Copyright 1996 Christopher Baker. All rights reserved. Duplication
|
||
and/or distribution permitted for noncommercial purposes only. For
|
||
use in other circumstances, please contact the original authors, or
|
||
the Editor.
|
||
|
||
=*=*=*=*=*=*=*=*=
|
||
|
||
OBTAINING COPIES: The most recent issue of FidoNews in electronic
|
||
form may be obtained from the FidoNews Editor via manual download or
|
||
file-request, or from various sites in the FidoNet and Internet.
|
||
PRINTED COPIES may be obtained by sending SASE to the above postal
|
||
address. File-request FIDONEWS for the current Issue. File-request
|
||
FIDONEWS 14-06 Page 48 10 Feb 1997
|
||
|
||
|
||
FNEWS for the current month in one archive. Or file-request specific
|
||
back Issue filenames in distribution format [FNEWSDnn.LZH] for a
|
||
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 may obtain an email subscription to FidoNews by sending email to:
|
||
|
||
jbarchuk@worldnet.att.net
|
||
|
||
with a Subject line of: subscribe fnews-edist
|
||
|
||
and no message in the message body. To remove your name from the email
|
||
distribution use a Subject line of: unsubscribe fnews-edist with no
|
||
message to the same address above.
|
||
|
||
*=*=*
|
||
|
||
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.
|
||
|
||
=*=*=*=*=*=*=*=*=
|
||
FIDONEWS 14-06 Page 49 10 Feb 1997
|
||
|
||
|
||
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.
|
||
|
||
*=*=*=*=*
|
||
|
||
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-
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|