1135 lines
52 KiB
Plaintext
1135 lines
52 KiB
Plaintext
Volume 7, Number 46 12 November 1990
|
||
+---------------------------------------------------------------+
|
||
| _ |
|
||
| / \ |
|
||
| /|oo \ |
|
||
| - FidoNews - (_| /_) |
|
||
| _`@/_ \ _ |
|
||
| FidoNet (r) | | \ \\ |
|
||
| International BBS Network | (*) | \ )) |
|
||
| Newsletter ______ |__U__| / \// |
|
||
| / FIDO \ _//|| _\ / |
|
||
| (________) (_/(_|(____/ |
|
||
| (jm) |
|
||
+---------------------------------------------------------------+
|
||
Editor in Chief: Vince Perriello
|
||
Editors Emeritii: Thom Henderson, Dale Lovell
|
||
Chief Procrastinator Emeritus: Tom Jennings
|
||
|
||
Copyright 1990, Fido Software. All rights reserved. Duplication
|
||
and/or distribution permitted for noncommercial purposes only.
|
||
For use in other circumstances, please contact Fido Software.
|
||
|
||
FidoNews is published weekly by and for the Members of the
|
||
FidoNet (r) International Amateur Electronic Mail System. It is
|
||
a compilation of individual articles contributed by their authors
|
||
or authorized agents of the authors. The contribution of
|
||
articles to this compilation does not diminish the rights of the
|
||
authors.
|
||
|
||
You are encouraged to submit articles for publication in
|
||
FidoNews. Article submission standards are contained in the file
|
||
ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous
|
||
Mail system, available for network mail 24 hours a day.
|
||
|
||
Fido and FidoNet are registered trademarks of Tom Jennings of
|
||
Fido Software, Box 77731, San Francisco CA 94107, USA and are
|
||
used with permission.
|
||
|
||
Opinions expressed in FidoNews articles are those of the authors
|
||
and are not necessarily those of the Editor or of Fido Software.
|
||
Most articles are unsolicited. Our policy is to publish every
|
||
responsible submission received.
|
||
|
||
|
||
Table of Contents
|
||
1. ARTICLES ................................................. 1
|
||
Ask A Coordinator ........................................ 1
|
||
GATEWAY POLICY??? Hunh?? What?? .......................... 3
|
||
LDS_PRIVATE Echo Now Available ........................... 5
|
||
SGANet - Student Government Global Mail Network .......... 6
|
||
NewStyle Packets ......................................... 8
|
||
Why Not? (Because it is too simple?) ..................... 15
|
||
2. COLUMNS .................................................. 17
|
||
A View from the Bridge ................................... 17
|
||
3. LATEST VERSIONS .......................................... 18
|
||
And more!
|
||
FidoNews 7-46 Page 1 12 Nov 1990
|
||
|
||
|
||
=================================================================
|
||
ARTICLES
|
||
=================================================================
|
||
|
||
Paul Knupke, Jr.
|
||
Fidonet 1:3603/110.9
|
||
Eggnet 99:9010/35
|
||
|
||
Ask A Coordinator
|
||
|
||
Recently a new participant in the SYSOP echo said "I thought
|
||
this echo was for civil discussions between sysops." SYSOP and
|
||
CIVIL are oxymoron. Where is a sysop to go when they want to
|
||
get real answers and have discussions where they won't be
|
||
attacked for their personal opinions? I thought about this for
|
||
a while and came to the conclusion that SYSOP is a lost cause
|
||
and the only thing to do is start a brand new echo where flames
|
||
and personal attacks will not be tolerated.
|
||
|
||
Ask A Coordinator, ASK_A_C, is an echo devoted to sysops and
|
||
users who want to ask questions and carry on friendly
|
||
conversation. Topics include: Policy (current and proposed),
|
||
echomail, software, how the network operates, and many more
|
||
topics.
|
||
|
||
ASK_A_C is open to everyone who is willing to converse in a
|
||
friendly manner. The only people who are not welcome are those
|
||
who flame and attack others (there is an echo for those people
|
||
already.)
|
||
|
||
I invite all Coordinators to participate in this open
|
||
discussion forum. I am working to move this echo to backbone as
|
||
soon as possible. All current and former *C's and *EC's are
|
||
invited to join me in this ground breaking of this echo devoted
|
||
to open the channel of discussion between the coordinator
|
||
structure and the grunt sysops and their users.
|
||
|
||
It is the coordinators who keep our network together but it is
|
||
the grunt sysops and their users who benefit from their
|
||
contributions.
|
||
|
||
Distribution is being worked on but initially it will be
|
||
available from 1:3603/110 (MO, HST/V42, N3603/R18 echomail hub)
|
||
in Clearwater, Florida and soon after 151/1003 (R18EC).
|
||
|
||
Contact Neil Lauritsen (1:3603/110) for a link into ASK_A_C.
|
||
|
||
Paul Knupke, Jr.
|
||
Moderator - ASK_A_C
|
||
|
||
|
||
FidoNews 7-46 Page 2 12 Nov 1990
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
FidoNews 7-46 Page 3 12 Nov 1990
|
||
|
||
|
||
Jim Deputy
|
||
Moderator Kinknet Echoes
|
||
Zone Coordinator Adult Links Network
|
||
EggNet Supreme Court Chief Justice
|
||
1:103/158, 99:99/105, 69:69/0
|
||
|
||
Gateway Policy...
|
||
|
||
Well, to be honest, it looks like I probably ought to quit read-
|
||
ing FidosNews again, and wait for the announcements in the Node-
|
||
list, where they are supposed to be posted. It would probably
|
||
result in my blood-pressure staying down much better. Especially
|
||
since they aren't being made there anymore. Sorry for the long
|
||
lead in at the top, but I am speaking on this subject matter on
|
||
much more than one level.
|
||
|
||
I've just read Matt Whelan's version of the New GATEWAY LAW that
|
||
the **C's have decided to inflict us with. It's nice to see that
|
||
FidoNet doesn't want to tell the other networks how to operate.
|
||
Now would
|
||
|
||
SOMEONE PLEASE TELL THAT TO FIDONET!!!!!
|
||
|
||
I'm beginning to think that maybe folks like Jack Decker, Jason
|
||
Steck, The ROUSTER, and a few of the other so-called rabble
|
||
rousers aren't all that far off base. I am beginning to feel that
|
||
the SS-Elite are moving in on us along with BIG BROTHER!
|
||
|
||
First off, what's this contract crap at the end of the Gateway
|
||
policy? Come on! If you aren't telling other networks how to
|
||
operate, what the heck do you call it? This is supposed to be a
|
||
hobby not a business.
|
||
|
||
Second, the article immediately following Matt's GATEWAY POLICY,
|
||
by Tony Davis quite calmly announces that "1:1/100@FIDONET will
|
||
accept and deliver domain addressed network netmail to the do-
|
||
mains of:
|
||
|
||
Fidonet
|
||
Alternet
|
||
Eggnet
|
||
Rbbsnet
|
||
Network
|
||
Kinknet"
|
||
|
||
I find this very interesting. Who died and elected either Tony
|
||
Davis or Matt Whelan GOD? I believe I have to claim that I am
|
||
KinkNet. Or at least I have the right to that claim. After all, I
|
||
started the KinkNet echoes over two years ago, and am the modera-
|
||
tor of the echo conferences tied together under that banner.
|
||
|
||
FidoNews 7-46 Page 4 12 Nov 1990
|
||
|
||
|
||
KinkNet is not a DOMAIN! KinkNet is nothing more than a group of
|
||
Echoes. KinkNet operates in the DOMAIN of Adult Links (Zone 69) of
|
||
which I am also the Zone Coordinator.
|
||
IT DOES NOT OPERATE WITHIN THE DOMAIN OF FIDONET!!!
|
||
|
||
As the moderator of the KinkNet echoes, I have entered into no
|
||
agreement authorizing such a gateway. As the Zone Coordinator of
|
||
Adult Links, likewise I have authorized no such gateway, nor has
|
||
it even been discussed with me. I have further not discussed or
|
||
agreed to Adult Links or KinkNet DOMAIN titles with anyone. I am
|
||
glad to see that FidoNet has not made any decisions for KINKNET
|
||
or Adult Links!
|
||
|
||
Hence, EFFECTIVE IMMEDIATELY 1:1/100@FIDONET is not authorized to
|
||
gate any traffic into either KINKNET or Adult Links, until such
|
||
time as an agreement is reached.
|
||
|
||
Be it further known, KINKNET is not a DOMAIN! And the word KINK-
|
||
NET may not be used as a DOMAIN tag.
|
||
|
||
Speaking as the EggNet Supreme Court Chief Justice, I am not
|
||
aware of any such agreement existing in EggNet either. Should one
|
||
have been reached there would be an applicable 99/1 address.
|
||
There is no such address in the current Egglist. Nor has an
|
||
announcement been made by the EggNet Inter Network Liaison of
|
||
such an agreement. Further, in EggNet in particular, after look-
|
||
ing over the contents of the Gateway Policy, EggNet as a whole
|
||
would have to vote as to whether or not such an agreement could
|
||
be put in place for inter-network operation. No such election is
|
||
currently scheduled.
|
||
|
||
Mr. Davis doesn't have either an Adult Links (required by A_LINKS
|
||
policy) or EggNet Address. And Mr. Davis in the past has ex-
|
||
hibited strong ANTI-Other Network ideals. (Circa FidoCon '89).
|
||
|
||
Now, someone PLEASE say something to convince me that FIDONET
|
||
isn't out to run the other networks! I wonder, did the rest of
|
||
the networks find out about this scheme the same way I did?
|
||
|
||
-----------------------------------------------------------------
|
||
FidoNews 7-46 Page 5 12 Nov 1990
|
||
|
||
|
||
Jeff Murphy
|
||
1:344/10
|
||
Ephrata, WA, USA
|
||
|
||
LDS_PRIVATE Echo Now Available
|
||
|
||
On behalf of it's participants, I wish to announce the existence
|
||
of a private echo for Latter-day Saints (Mormons). Currently
|
||
all connections are being managed by Charles Simpkinson, 1:347/3
|
||
in Boise, ID.
|
||
|
||
Those of you interested in such things will know that the MORMON
|
||
echo already exists on the backbone, and is fairly well used by
|
||
its limited audience. However, for some time now the echo has
|
||
permitted considerable discussion of religious views - which is
|
||
to say that anti-Mormons are having a field day.
|
||
|
||
Some of us had the erroneous idea that MORMON meant just that: a
|
||
forum for members of The Church of Jesus Christ of Latter-day
|
||
Saints to discuss issues of interest to themselves. We were
|
||
apparently mistaken; most of the "burning questions" raised in
|
||
there deal with issues that are fundamental to our religion, in
|
||
that they question the basic premises upon which the Church is
|
||
built, arguing for example that Joseph Smith was no prophet at
|
||
all, the Book of Mormon a total fraud, etc. In other echos, we
|
||
call this flaming. In that one, it was called intellectual
|
||
curiosity or righteous indignation. <grin>
|
||
|
||
The echo has not been placed on the backbone in order to avoid
|
||
the conflicts which come from non-members and apostates. We
|
||
would probably do so if we could figure out a way to prune the
|
||
tree when one of these worms wanders in ['scuse my French].
|
||
However, the echo is available currently throughout the west
|
||
from various boards. We invite Latter-day Saints to might wish
|
||
to participate to contact Charles at 1:347/3.
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
FidoNews 7-46 Page 6 12 Nov 1990
|
||
|
||
|
||
SGANet - Student Government Global Mail Network
|
||
Now linking student leaders in 32 countries
|
||
|
||
SGANet, started in May 1990, is a global electronic mail
|
||
discussion group for student governments and student leaders to
|
||
use to discuss campus issues, education, and governance. SGANet
|
||
is a group of seven free and open e-mail discussions in which
|
||
student leaders can discuss ideas, share information, or request
|
||
information with student leaders worldwide. The practical effect
|
||
of the system is to place the participating student leaders in
|
||
one room.
|
||
|
||
SGANet supports the following: free and open discussion areas, an
|
||
automated directory of users, archives of discussions, and an
|
||
automated group of file libraries with information about student
|
||
governance, SGAnet, and future plans.
|
||
|
||
SGANet, although relatively new, now reaches student associations
|
||
in 32 countries on six continents. Until recently, our only
|
||
publicity was word of mouth.
|
||
|
||
It is our hope that SGANet, in the future, will provide a
|
||
reliable, interactive media which will serve as a foundation for
|
||
meaningful student union on the regional, national and even
|
||
global level. Simone Botti, of Italy, recently initiated a debate
|
||
on drafting a universal Charter on Student Rights which would be
|
||
drafted later this year when we have reached a sizeable fraction
|
||
of the universities in the 70 countries served by the Internet.
|
||
|
||
SGANet is collectively maintained by an international team of
|
||
moderators and network liasions. Moderators help us keep the
|
||
network running and work primarily on technical issues. Network
|
||
liasions help us reach universities in a given region and help
|
||
prospective users with difficulties ranging from e-mail problems
|
||
to langauge barriers.
|
||
|
||
SGANet can be reached through the following networks:
|
||
BITNET/EARN, the Internet (serves over 70 countries), CompuServe,
|
||
Usenet, and Fidonet.
|
||
|
||
SGANet provides the following discussion areas, and related file
|
||
libraries:
|
||
|
||
SGANet@VTVM1.BITNET (Global discussion)
|
||
SGANet-N@VTVM1.BITNET (North American universities)
|
||
SGANet-S@VTVM1.BITNET (South American universities)
|
||
SGANet-E@VTVM1.BITNET (European Universities)
|
||
SGANet-A@VTVM1.BITNET (Asian/Australian Universities)
|
||
SGAN-SAV@VTVM1.BITNET (Student Association of Virginia, USA)
|
||
USGA-L@SIUCVMB.BITNET (Illinois Universities, USA)
|
||
SGANET-T@VTVM1.BITNET (Technical discussion group)
|
||
|
||
FidoNews 7-46 Page 7 12 Nov 1990
|
||
|
||
|
||
Automatic subscriptions can be taken by sending the following
|
||
message to LISTSERV@VTVM1.BITNET
|
||
|
||
SUBscribe (Network name) (Your name, affiliation, country)
|
||
|
||
We are interested in making SGANet, and its five
|
||
regional networks, available through Fidonet. Our ultimate
|
||
goal is to provide a forum in which student leaders can share
|
||
information, and plan strategy worldwide; and also to make
|
||
the discussions available to as wide an audience as possible.
|
||
If you would be interested in joining SGANet and/or making
|
||
SGANet available to your users contact one of the following:
|
||
|
||
Brian McConnell
|
||
SGANet System Moderator
|
||
FidoNet= 1:114/15
|
||
Internet= bmcconne@vtssi.vt.edu
|
||
UNITED STATES
|
||
|
||
Abhik Biswas,
|
||
SGANet System Co-Moderator
|
||
UNITED STATES
|
||
Bitnet= jutbaaa@iupoak.bitnet
|
||
|
||
Daniel Kalchev
|
||
SGANet-E (Europe) Moderator
|
||
BULGARIA
|
||
Daniel Kalchev
|
||
Fidonet= 2:359/1
|
||
|
||
-----------------------------------------------------------------
|
||
FidoNews 7-46 Page 8 12 Nov 1990
|
||
|
||
|
||
NewStyle Packets
|
||
A Proposal for the
|
||
Next Generation of
|
||
of FidoNet Mail Packers
|
||
|
||
Third Draft
|
||
10 November 1990
|
||
|
||
jim nutt
|
||
1:114/30@fidonet
|
||
|
||
Introduction
|
||
|
||
FidoNet has been using the Type II style packet for some
|
||
five years or more now with good results. However, at this
|
||
point, the Type II format has been extended an amazing number of
|
||
ways using the "Kludge" hidden line facility provided by a
|
||
leading ^A (ASCII SOH) on a line of text. It is my belief that
|
||
the time has come to move to a newer technology for handling
|
||
packets, one that is inherently extensible and easily handled by
|
||
a number of systems. Such a system should be able to handle
|
||
such varied things as integrated text/graphics and other special
|
||
attributes of messages. Such a system has been proposed by
|
||
Garth Kidd and is expanded upon here.
|
||
|
||
Basic Format
|
||
|
||
Essentially, this format would break a message into a
|
||
number of "chunks". Each chunk would be a maximum of
|
||
4,294,967,306(!) bytes long including its header and may contain
|
||
any type of data. A chunk header would be 21 bytes long and
|
||
would consist of a 4 byte chunk type tag followed by an 8 byte
|
||
length field. The length field does *not* include the 12 bytes
|
||
of the chunk header. Chunks would be unterminated. In C, a
|
||
chunk structure would look like this:
|
||
|
||
struct chunk {
|
||
char type[4];
|
||
char len[8]; /* 32 bit length of data field, 8 hex
|
||
digits */
|
||
unsigned char data[len]; /* not really, this isn't
|
||
legal c, but it gets the
|
||
idea across */
|
||
};
|
||
|
||
Certain chunk types require that a FidoNet address be
|
||
represented in a 24 byte hex format. This address would be
|
||
comprised of the domain, zone, net, node, and point expressed as
|
||
the following C structure:
|
||
|
||
struct address {
|
||
FidoNews 7-46 Page 9 12 Nov 1990
|
||
|
||
|
||
char domain[8];
|
||
char zone[4];
|
||
char net[4];
|
||
char node[4];
|
||
char point[4];
|
||
};
|
||
|
||
The domain name is *not* null terminated, it is however, null
|
||
padded to eight characters. If the first character of the
|
||
domain name is null, then the remainder of the domain field is
|
||
to be considered absent. This offers a space savings of 7 bytes
|
||
per address when operating in a non-domain aware Network.
|
||
|
||
All other fields are 4 hex digits, again, with NO
|
||
terminating nul character. It was chosen to use an ASCII
|
||
representation of numbers (in hex) to avoid byte ordering
|
||
problems and to enhance portability across 7 bit transport
|
||
layers.
|
||
|
||
Chunk Types
|
||
|
||
Chunk type names are exactly four characters long, padded
|
||
with spaces if necessary. Chunk types not recognized by a
|
||
program would be passed along and ignored. Chunk types that are
|
||
marked with an asterisk (*) must be recognized by a conforming
|
||
installation. Chunk types marked with a C are considered
|
||
control chunks, while those marked with D are data chunks.
|
||
Unmarked chunks are delimiters or informational. I would
|
||
propose the following base chunk types:
|
||
|
||
* BEGB A chunk indicating the beginning of a bundle.
|
||
This chunk may contain optional information
|
||
identifying the bundle.
|
||
|
||
CRTR Indicates the software and revision level used
|
||
to create this bundle. Applies only to entire
|
||
bundles.
|
||
|
||
* PSWD Password for the entire bundle, or if within
|
||
"BEGM"/"ENDM" a single message. If the password
|
||
in this chunk does not match a predefined
|
||
password on the receiving system one of two
|
||
actions occurs. If the receiving system is the
|
||
final destination of the bundle or message, the
|
||
bundle or message is discarded, optionally with
|
||
a message being sent back to the sender saying so.
|
||
If the bundle or message is only passing through,
|
||
it will not be made visible to the sysop of the
|
||
routing system, regardless of any options that
|
||
may be set to the contrary. Obviously, this is
|
||
lightweight security, but it is better than
|
||
FidoNews 7-46 Page 10 12 Nov 1990
|
||
|
||
|
||
nothing!
|
||
|
||
* BEGM A chunk indicating the beginning of a message,
|
||
this chunk may contain optional information
|
||
identifying the message.
|
||
|
||
* ROUT C Binary address of next destination for this
|
||
message or bundle. In other words, if a message
|
||
from 123/456 is going to 456/789 but is routed
|
||
through an intermediary system (say 321/654) this
|
||
address would be that of the intermediary system.
|
||
This address would be a two dimensional address in
|
||
the sender's current zone and domain. This
|
||
address would be represented in C as:
|
||
|
||
struct route_address {
|
||
char net[4];
|
||
char node[4];
|
||
};
|
||
|
||
This chunk may be applied to either a single
|
||
message or an entire bundle. If the chunk length
|
||
is 24, then the route address is a full five
|
||
dimensional address comprising domain, zone and
|
||
point information as described above in "Basic
|
||
Formats", otherwise the chunk length is 4 and the
|
||
address is in the format described above.
|
||
|
||
* TO C Name and address of receiver in ascii. The
|
||
address in this field may be anything, so long
|
||
as the system at the "ROUT" address can make
|
||
sense of it.
|
||
|
||
* FROM C Name and address of sender in ascii. This
|
||
may be anything so long as it is possible for
|
||
the receiver to reply via the address in this
|
||
field.
|
||
|
||
* ATTR C Attributes of the message. See Appendix 2 for
|
||
a complete list of message attributes. Length is
|
||
8.
|
||
|
||
* NUMB Serial number of this message on originating
|
||
system. This chunk is fixed as an 8 byte hex
|
||
word. Length is 8.
|
||
|
||
* RPLY Address and serial number of the message this
|
||
message is a reply to. This chunk is a 24 byte
|
||
hex address followed by a 8 byte hex word. Length
|
||
is 32.
|
||
|
||
FidoNews 7-46 Page 11 12 Nov 1990
|
||
|
||
|
||
* ATCH C Name of a file attached to this message
|
||
|
||
* FREQ C Name of a file requested from receiving system.
|
||
This would incorporate the same type of update
|
||
request logic as is currently used by WaZoo
|
||
mailers. A separate "FREQ" chunk is required
|
||
for each file requested.
|
||
|
||
* AREA C Echomail only, signifies the echomail area this
|
||
message belongs to.
|
||
|
||
* DOMN C Echomail only, list of domains, as 8 byte ASCII
|
||
strings (null-padded, but not necessarily null-
|
||
terminated), that have seen this message.
|
||
|
||
* ZONE C Echomail only, list, as four byte hex words,
|
||
of zones that have seen this message. This
|
||
chunk is cleared each time the message enters a
|
||
different domain and the name of the domain the
|
||
message is exiting is added to the "DOMN" chunk.
|
||
|
||
* NET C Echomail only, list, as four byte hex words,
|
||
of all nets that have seen this message. This
|
||
chunk is cleared upon export to another zone and
|
||
the exporting node's zone number is added to the
|
||
"ZONE" chunk.
|
||
|
||
* NODE C Echomail only, list, as four byte hex words,
|
||
of all nodes in the current net that have seen
|
||
this message. This chunk is cleared each time
|
||
the message enters a new net and the number of
|
||
the net the message is exiting is added to the
|
||
"NET " chunk.
|
||
|
||
* PONT C Echomail only, list, as four byte hex words,
|
||
of all point systems that have seen this message.
|
||
This chunk is cleared upon export to another node
|
||
and the node number of the exporting system is
|
||
added to the "NODE" chunk.
|
||
|
||
* PATH List of the systems this message has passed
|
||
through to reach this system, in order. This
|
||
includes all systems in all zones and domains.
|
||
All addresses would be 24 byte hex as defined
|
||
in the section "Basic Formats"
|
||
|
||
* TEXT D The text of the message
|
||
|
||
TXAT D Text attribute change. Allows for font changes,
|
||
underlining, etc. See Appendix 4 for the basic
|
||
set of text attributes.
|
||
|
||
FidoNews 7-46 Page 12 12 Nov 1990
|
||
|
||
|
||
BITS D A bitmap. To be defined (MacPaint? Windows? PCX?
|
||
TIFF?)
|
||
|
||
BITC D Bitmap continuation.
|
||
|
||
GRPH D A vector drawing. To be defined (PostScript?
|
||
HPGL?)
|
||
|
||
* ENDM A chunk indicating the end of a message. This
|
||
chunk may optionally contain information
|
||
identifying the message it terminates.
|
||
|
||
* ENDB A chunk indicating the end of the bundle,
|
||
anything after this can be safely ignored.
|
||
This chunk may optionally contain information
|
||
identifying the bundle it terminates.
|
||
|
||
Other Considerations
|
||
|
||
Chunk style packets could not be sent as *.PKT files as
|
||
they are not backward compatible with type II packets. I
|
||
propose that chunk style packets be called bundles and sent as
|
||
*.BUN files, with compressed bundles sent as *.B?? where ?? is
|
||
the compression method used (see Appendix 1 for extensions).
|
||
Bundle file names should be unique for at least a one week
|
||
cycle, a 32 bit serial number expressed in hexadecimal should
|
||
prove adequate for most applications.
|
||
|
||
Experimental chunk types are provided for by the provision
|
||
that unrecognized chunk types be passed through and ignored.
|
||
Systems that know how to use a particular chunk type (say, BITS)
|
||
can, while systems that don't understand it may ignore it.
|
||
|
||
Chunks should appear in a bundle in roughly the same order
|
||
as they appear above, with control and informational chunks
|
||
(PATH, ROUT, etc) appearing before data chunks (TEXT, BITS,
|
||
GRPH).
|
||
|
||
Control
|
||
|
||
Chunk tag name assignments are controlled by Appendix 3 of
|
||
this document. New chunk tags may be added and old ones revised
|
||
by revision of this document. Message attribute assignments are
|
||
controlled by Appendix 2 of this document. New attributes may
|
||
be assigned by revision of this document. Bundle file
|
||
extensions are controlled by Appendix 1 of this document. New
|
||
extensions may be defined and old ones revised by revision of
|
||
this document. Finally, text attributes are controlled by
|
||
Appendix 4 of this document.
|
||
|
||
Conclusion
|
||
|
||
FidoNews 7-46 Page 13 12 Nov 1990
|
||
|
||
|
||
I doubt I have covered all possible or desirable chunk
|
||
types in this document. I do believe however, that enough have
|
||
been defined to get started with. Chunks offer a highly
|
||
flexible, extensible system of bundling mail. New types of
|
||
chunks may defined as needed to accomodate advances in
|
||
technology and FidoNet. Additionally, this would further
|
||
separate the application and transport layers of FidoNet,
|
||
yielding less confusion as to their respective roles.
|
||
|
||
It may be noticed that this structure is extremely similar
|
||
to the IFF format as used on Amiga computers and introduced by
|
||
Electronic Arts Software. While inspired by IFF, this system has
|
||
been simplified somewhat and changed to be more easily
|
||
transportable between computers using different byte orders and
|
||
processors. All fields defined in this document are 7 bit ascii
|
||
and should be easily parsed by any system.
|
||
|
||
Appendix 1 - Compression Extensions
|
||
|
||
Compressed bundles would indicate the type of compression
|
||
used by the following file extensions:
|
||
|
||
Extension Creator
|
||
--------- -------
|
||
.BUN Uncompressed
|
||
.BPK PKZip
|
||
.BLH LHarc
|
||
.BAR ARC
|
||
.BDW DWC
|
||
.BPA PAK
|
||
.BZO ZOO
|
||
.BPX PKXarc
|
||
|
||
Appendix 2 - Message Attributes
|
||
|
||
Message attributes are expressed as an 8 byte hex word.
|
||
(32 bit binary) Multiple attributes may be ORed together. The
|
||
following attributes have been assigned.
|
||
|
||
0000000000000001 Privileged (sysop or
|
||
addressee access only)
|
||
0000000000000010 Encrypted
|
||
0000000000000100 Crash (high priority)
|
||
0000000000001000 Direct (send directly to
|
||
recipient system, no routing)
|
||
0000000000010000 Hold for pickup
|
||
|
||
Appendix 3 - Defined Chunk Tags
|
||
|
||
The following chunk tags are defined in this document:
|
||
|
||
FidoNews 7-46 Page 14 12 Nov 1990
|
||
|
||
|
||
BEGB NET FROM TEXT AREA
|
||
NODE ATTR TXAT ENDB PSWD
|
||
CRTR PONT NUMB BITS
|
||
BEGM ZONE RPLY BITC
|
||
ROUT DOMN ATCH GRPH
|
||
TO PATH FREQ ENDM
|
||
|
||
Appendix 4 - Text Attributes
|
||
|
||
The text attribute is a four byte hex word (16 bit binary).
|
||
Multiple attributes may be ORed together. Attributes are
|
||
toggles. The following attributes have been assigned:
|
||
|
||
00000000 Reset all text attributes
|
||
00000001 Underline
|
||
00000010 Bold
|
||
00000100 Italic
|
||
00001000 Font Change
|
||
00010000 Size Change
|
||
00100000 Color Change
|
||
|
||
The font, size and color change attributes are followed by a
|
||
one byte binary word selecting the font, size and color to
|
||
change to. In the case of changing two or all three of these
|
||
attributes at the same time, the selectors will follow the
|
||
attribute word in the order; font, size, color, with
|
||
unnecessary fields being omitted.
|
||
|
||
-----------------------------------------------------------------
|
||
FidoNews 7-46 Page 15 12 Nov 1990
|
||
|
||
|
||
Paul Knupke, Jr.
|
||
Pointless Perception
|
||
FidoNet 1:3603/110.9
|
||
Eggnet 99:9010/35
|
||
|
||
Why Not? (Because it is too simple?)
|
||
|
||
Has anyone considered the simplist method of holding elections in
|
||
Fidonet lately? How about one vote for each sysop of Fidonet and
|
||
the outcome is decided by who has the most votes or whether
|
||
there are more yes or no votes for implementation of policy. The
|
||
policy of "no vote = no" has got to stop!
|
||
|
||
In the United States of America officials are elected for the
|
||
most part by a minority of the people who are eligible to vote
|
||
because not everyone is interested in politics. Why can't Fidonet
|
||
employ such a simple method to elect the *C and *EC structure and
|
||
to decide if a new policy document will become the law. Those
|
||
who are interested will vote and those who aren't won't. Those
|
||
who don't vote have no right to complain about the results of
|
||
their non participation in an election.
|
||
|
||
I propose the following election procedure. Once a year all *C
|
||
positions are put up for reelection by those under the position.
|
||
Before any nominations and elections occur a vote counter would
|
||
be needed. The vote counter should be outside the net or region
|
||
that the election is taking place. In the ZC case the current IC
|
||
would ask a non *C sysop within their zone to serve as vote
|
||
counter.
|
||
|
||
Nominations would be sent to the vote counter via net mail. All
|
||
names received before a set date would appear on the ballot. The
|
||
ballot would be sent to the *C for distibution.
|
||
|
||
The nomination and election time frame will be one week (7
|
||
days) each. If a candidate gets a majority on the first ballot
|
||
they are declared the winner. If no single candidate gets a
|
||
majority of votes the two highest vote getters will run against
|
||
each other for a runoff election. The highest vote getter is
|
||
then declared the winner.
|
||
|
||
The individual sysops would vote for their Net Coordinator, their
|
||
Regional Coordinator and their Zone coordinator. No matter how
|
||
many times a sysop's name appears in the nodelist they get one
|
||
vote.
|
||
|
||
The time frame I am describing is 4 weeks long. The first week
|
||
of the month (first through the seventh day) is the nomination
|
||
period. The second week (eighth day through fourteenth day) is
|
||
the election period. The third week (fifteenth day through the
|
||
twenty-first day) is to tally votes. The fourth week (twenty-
|
||
second day through the twenty-eighth day) is the runoff week (if
|
||
necessary.) The results will be published with in 5 days of the
|
||
ending of the election and runoff.
|
||
|
||
FidoNews 7-46 Page 16 12 Nov 1990
|
||
|
||
|
||
Elections for the NCs, RCs and ZCs will not occur at the same
|
||
time but about 4 months apart so that the new coordinators will
|
||
be settled into their positions.
|
||
|
||
There is one problem with the above procedure that I need to
|
||
address. What happens if the newly elected coordinator wants to
|
||
run for a higher office. I propose that if the coordinator wins
|
||
the election for the higher office the runner-up in the previous
|
||
election takes over the lower position.
|
||
|
||
The runner up in any *C election would be called the Alternate
|
||
*C. In the event the current *C decides to not continue as a *C
|
||
or drops out of the network for any reason the A*C would assume
|
||
the position until the next election.
|
||
|
||
All *Cs can run for re-election. A good *C will be re-elected in
|
||
most cases and a unpopular *C will not be.
|
||
|
||
In a few weeks I'll be discussing the *EC structure and election
|
||
procedure. It differs from the *C election method because the
|
||
*EC jobs are a technical job and the *C jobs are mostly
|
||
administrative jobs.
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
FidoNews 7-46 Page 17 12 Nov 1990
|
||
|
||
|
||
=================================================================
|
||
COLUMNS
|
||
=================================================================
|
||
|
||
A View from the Bridge
|
||
|
||
"Captain's Log, Stardate 9011.11..."
|
||
by The Captain, 1:107/583@FidoNet 520/583@AlterNet 9:807/1@PNet
|
||
|
||
You know, it seems a lot of idiots who don't have anything better
|
||
to do have been jumping up and down about what's being published
|
||
in FidoNews. "IT'S NOT FIDONET RELATED!" they scream in long,
|
||
tedious articles (as opposed to short, tedious columns like
|
||
mine). Let's ask ourselves a question: What does "Fidonet
|
||
related" MEAN, and just who the u&rz are YOU to judge what should
|
||
get published or not?
|
||
|
||
There's a long standing tradition with FidoNews, going back
|
||
almost SEVEN YEARS that if it's sent in, it gets printed. With
|
||
some folks, its a selling point of joining the network! Yet
|
||
certain people with narrow minds object to their being "forced"
|
||
to distribute a file which on average is smaller than the usual
|
||
DAILY echomail bundle once a week, simply because it has
|
||
something in it THEY don't care to read. SO, they make a verbal
|
||
stink about it without doing anything constructive. Sound
|
||
familiar? Can YOU say "echomail"? I thought you could...
|
||
|
||
Needless to say I continue to support the policy of "All the News
|
||
that Fits We Print" with FidoNews. I happen to be directly
|
||
responsible for that being the motto of AlterNet's AlterNews. If
|
||
someone has something to say that they feel is important enough
|
||
that they'll write up an article and send it on their dime to
|
||
FidoNews, we oughta publish it. If you don't like that, don't
|
||
read it. If you're a *C and don't like distributing it, don't be
|
||
a *C. Nobody's FORCING you.
|
||
|
||
The only time I can remember disliking something in FidoNews was
|
||
Tom Jennings's (remember him? He invented the network...)
|
||
article on gay rights. I didn't object to his subject matter,
|
||
but felt that his profanity should have been editted before
|
||
publishing. Other people felt differently, that it should never
|
||
have been published at all. To those people I remind: "This Is A
|
||
Hobby." And some day THEY might be the ones who want to have
|
||
something published.
|
||
|
||
Good day.
|
||
|
||
-----------------------------------------------------------------
|
||
FidoNews 7-46 Page 18 12 Nov 1990
|
||
|
||
|
||
=================================================================
|
||
LATEST VERSIONS
|
||
=================================================================
|
||
|
||
Latest Software Versions
|
||
|
||
MS-DOS Systems
|
||
--------------
|
||
|
||
Bulletin Board Software
|
||
Name Version Name Version Name Version
|
||
|
||
DMG 2.93 Phoenix 1.3 TAG 2.5g
|
||
Fido 12s+ QuickBBS 2.64 TBBS 2.1
|
||
Lynx 1.30 RBBS 17.3A TComm/TCommNet 3.4
|
||
Kitten 2.16 RBBSmail 17.3B Telegard 2.5
|
||
Maximus 1.02 RemoteAccess 0.04a TPBoard 6.1
|
||
Opus 1.13+ SLBBS 1.77 Wildcat! 2.50
|
||
PCBoard 14.5 Socrates 1.10 XBBS 1.15
|
||
|
||
Network Node List Other
|
||
Mailers Version Utilities Version Utilities Version
|
||
|
||
BinkleyTerm 2.40 EditNL 4.00 ARC 7.0
|
||
D'Bridge 1.30 MakeNL 2.31 ARCAsim 2.30
|
||
Dutchie 2.90C ParseList 1.30 ARCmail 2.07
|
||
FrontDoor 1.99c Prune 1.40 ConfMail 4.00
|
||
PRENM 1.47 SysNL 3.14 Crossnet v1.5
|
||
SEAdog 4.51b XlatList 2.90 EMM 2.02
|
||
TIMS 1.0(Mod8) XlaxDiff 2.35 Gmail 2.05
|
||
XlaxNode 2.35 GROUP 2.16
|
||
GUS 1.30
|
||
HeadEdit 1.15
|
||
InterPCB 1.31
|
||
LHARC 1.13
|
||
MSG 4.1
|
||
MSGED 2.00
|
||
MSGTOSS 1.3
|
||
PK[UN]ZIP 1.10
|
||
QM 1.0
|
||
QSORT 4.03
|
||
Sirius 1.0x
|
||
SLMAIL 1.36
|
||
StarLink 1.01
|
||
TagMail 2.40
|
||
TCOMMail 2.2
|
||
Telemail 1.27
|
||
TMail 1.15
|
||
TPBNetEd 3.2
|
||
TosScan 1.00
|
||
UFGATE 1.03
|
||
FidoNews 7-46 Page 19 12 Nov 1990
|
||
|
||
|
||
XRS 3.40
|
||
XST 2.2
|
||
ZmailQ 1.12
|
||
|
||
|
||
OS/2 Systems
|
||
------------
|
||
|
||
Bulletin Board Software Network Mailers Other Utilities
|
||
|
||
Name Version Name Version Name Version
|
||
|
||
Maximus-CBCS 1.02 BinkleyTerm 2.40 Parselst 1.32
|
||
ConfMail 4.00
|
||
EchoStat 6.0
|
||
oMMM 1.52
|
||
Omail 3.1
|
||
MsgEd 2.00
|
||
MsgLink 1.0C
|
||
MsgNum 4.14
|
||
LH2 0.50
|
||
PK[UN]ZIP 1.02
|
||
ARC2 6.00
|
||
PolyXARC 2.00
|
||
Qsort 2.1
|
||
Raid 1.0
|
||
Remapper 1.2
|
||
Tick 2.0
|
||
VPurge 2.07
|
||
|
||
|
||
Xenix/Unix
|
||
----------
|
||
|
||
BBS Software Mailers Other Utilities
|
||
Name Version Name Version Name Version
|
||
|
||
MaximusCBCS 1.02.Unix.B0 BinkleyTerm 2.30b Unzip 3.10
|
||
ARC 5.21
|
||
ParseLst 1.30b
|
||
ConfMail 3.31b
|
||
Ommm 1.40b
|
||
Msged 1.99b
|
||
Zoo 2.01
|
||
C-Lharc 1.00
|
||
Omail 1.00b
|
||
|
||
|
||
|
||
Apple CP/M
|
||
----------
|
||
|
||
FidoNews 7-46 Page 20 12 Nov 1990
|
||
|
||
|
||
Bulletin Board Software Network Mailers Other Utilities
|
||
|
||
Name Version Name Version Name Version
|
||
|
||
Daisy v2j Daisy Mailer 0.38 Nodecomp 0.37
|
||
MsgUtil 2.5
|
||
PackUser v4
|
||
Filer v2-D
|
||
UNARC.COM 1.20
|
||
|
||
|
||
Macintosh
|
||
---------
|
||
|
||
Bulletin Board Software Network Mailers Other Utilities
|
||
|
||
Name Version Name Version Name Version
|
||
|
||
Red Ryder Host 2.1 Tabby 2.2 MacArc 0.04
|
||
Mansion 7.15 Copernicus 1.0 ArcMac 1.3
|
||
WWIV (Mac) 3.0 LHArc 0.33
|
||
Hermes 1.01 StuffIt Classic 1.6
|
||
FBBS 0.91 Compactor 1.21
|
||
TImport 1.92
|
||
TExport 1.92
|
||
Timestamp 1.6
|
||
Tset 1.3
|
||
Import 3.2
|
||
Export 3.21
|
||
Sundial 3.2
|
||
PreStamp 3.2
|
||
OriginatorII 2.0
|
||
AreaFix 1.6
|
||
Mantissa 3.21
|
||
Zenith 1.5
|
||
Eventmeister 1.0
|
||
TSort 1.0
|
||
Mehitable 2.0
|
||
UNZIP 1.02c
|
||
|
||
Amiga
|
||
-----
|
||
|
||
Bulletin Board Software Network Mailers Other Utilities
|
||
|
||
Name Version Name Version Name Version
|
||
|
||
Paragon 2.07+ BinkleyTerm 1.00 AmigArc 0.23
|
||
TrapDoor 1.50 AReceipt 1.5
|
||
WelMat 0.42 booz 1.01
|
||
ConfMail 1.10
|
||
FidoNews 7-46 Page 21 12 Nov 1990
|
||
|
||
|
||
ChameleonEdit 0.10
|
||
ElectricHerald1.66
|
||
Lharc 1.21
|
||
MessageFilter 1.52
|
||
oMMM 1.49b
|
||
ParseLst 1.30
|
||
PkAX 1.00
|
||
PK[UN]ZIP 1.01
|
||
PolyxAmy 2.02
|
||
RMB 1.30
|
||
TrapList 1.12
|
||
UNzip 0.86
|
||
Yuck! 1.61
|
||
Zoo 2.01
|
||
|
||
|
||
Atari ST
|
||
--------
|
||
|
||
Bulletin Board Software Network Mailer Other Utilities
|
||
|
||
Name Version Name Version Name Version
|
||
|
||
FIDOdoor/ST 1.94 BinkleyTerm 2.40 ConfMail 4.02
|
||
Pandora BBS 2.41c The BOX 1.20 ParseList 1.30
|
||
QuickBBS/ST 0.60 ARC 6.02
|
||
GS Point 0.61 FiFo 2.0b
|
||
LHARC 0.60
|
||
LED ST 0.10
|
||
BYE 0.25
|
||
PKUNZIP 1.10
|
||
MSGED 1.96S
|
||
SRENUM 6.2
|
||
Trenum 0.10
|
||
OMMM 1.40
|
||
|
||
|
||
Archimedes
|
||
----------
|
||
|
||
BBS Software Mailers Utilities
|
||
Name Version Name Version Name Version
|
||
|
||
ARCbbs 1.44 BinkleyTerm 2.03 Unzip 2.1TH
|
||
ARC 1.03
|
||
!Spark 2.00d
|
||
|
||
ParseLst 1.30
|
||
BatchPacker 1.00
|
||
|
||
|
||
FidoNews 7-46 Page 22 12 Nov 1990
|
||
|
||
|
||
+ Netmail capable (does not require additional mailer software)
|
||
* Recently changed
|
||
|
||
Utility authors: Please help keep this list up to date by
|
||
reporting new versions to 1:1/1. It is not our intent to list
|
||
all utilities here, only those which verge on necessity.
|
||
|
||
-----------------------------------------------------------------
|
||
FidoNews 7-46 Page 23 12 Nov 1990
|
||
|
||
|
||
=================================================================
|
||
NOTICES
|
||
=================================================================
|
||
|
||
The Interrupt Stack
|
||
|
||
|
||
13 Nov 1990
|
||
Third anniversary of Fidonet in Austria (zone 2, region 31).
|
||
|
||
14 Nov 1990
|
||
Marco Maccaferri's 21rd Birthday. Send greetings to him at
|
||
2:332/16.0
|
||
|
||
16 Nov 1990
|
||
100% Democratically elected administration takes over the
|
||
coordination structure in Zone-4 Latin America
|
||
|
||
1 Jan 1991
|
||
Implementation of 7% Goods and Services Tax in Canada. Contact
|
||
Joe Lindstrom at 1:134/55 for a more colorful description.
|
||
|
||
16 Feb 1991
|
||
Fifth anniversary of the introduction of Echomail, by Jeff Rush.
|
||
|
||
31 Mar 1991
|
||
Jim Grubs (W8GRT) was issued his first ham radio license forty
|
||
years ago today. His first station was made from an ARC-5
|
||
"Command Set" removed from a B-17 bomber.
|
||
|
||
12 May 1991
|
||
Fourth anniversary of FidoNet operations in Latin America and
|
||
second anniversary of the creation of Zone-4.
|
||
|
||
8 Sep 1991
|
||
25th anniversary of first airing of Star Trek on NBC!
|
||
|
||
7 Oct 1991
|
||
Area code 415 fragments. Alameda and Contra Costa Counties
|
||
will begin using area code 510. This includes Oakland,
|
||
Concord, Berkeley and Hayward. San Francisco, San Mateo,
|
||
Marin, parts of Santa Clara County, and the San Francisco Bay
|
||
Islands will retain area code 415.
|
||
|
||
1 Feb 1992
|
||
Area code 213 fragments. Western, coastal, southern and
|
||
eastern portions of Los Angeles County will begin using area
|
||
code 310. This includes Los Angeles International Airport,
|
||
West Los Angeles, San Pedro and Whittier. Downtown Los
|
||
Angeles and surrounding communities (such as Hollywood and
|
||
Montebello) will retain area code 213.
|
||
|
||
FidoNews 7-46 Page 24 12 Nov 1990
|
||
|
||
|
||
1 Dec 1993
|
||
Tenth anniversary of Fido Version 1 release.
|
||
|
||
5 Jun 1997
|
||
David Dodell's 40th Birthday
|
||
|
||
|
||
If you have something which you would like to see on this
|
||
calendar, please send a message to FidoNet node 1:1/1.
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|