FidoNews is published weekly by the International FidoNet
Association as its official newsletter. 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.
Copyright 1987 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067.
Table of Contents
1. ARTICLES ................................................. 1
Building the LATINO Net .................................. 1
Some Comments on the Proposed Policy4 .................... 3
Preferred Inbound and Alternate Inbound: A Routing Prop .. 9
SEA Letter: ARCmail, DTTY ................................ 14
FidoCon V ................................................ 16
2. NOTICES .................................................. 18
The Interrupt Stack ...................................... 18
Latest Software Versions ................................. 18
3. COMMITTEE REPORTS ........................................ 19
IFNA Status Report for November 1987 ..................... 19
FidoNews 4-41 Page 1 9 Nov 1987
Have you noticed what's been happening in the NodeList lately?
Other than continued growth, a second phenomenon is that we've
been getting nodes from Latin America. There are now nodes in
Puerto Rico, Argentina, and Suriname (OK trivia experts, where's
"Suriname"?).
Juan Davila of San Juan, Puerto Rico (18/3 soon to be 367/0)
says that though there are only two nodes presently in Puerto
Rico he already sees 5 to 6 more by year-end.
Pablo Kleinman of Buenos Aires (18/5) shows that Argentina is
really on the ball. Just last week he wrote Ken Kaplan and
got four nodes added to the list in one shot. Growth in
Argentina is expected to take off too.
So why all this sudden interest? One reason might be that La
Nacion ("South America's New York Times" according to Pablo)
recently published the history of the FidoNet in their Home
Computing section. Another is that international
telecommunications is finally past the stage of being cost
prohibitive. What ever the reasons it's a healthy development.
Could Zone 4 be far off? Only time will tell but in the mean
time we can do things to raise the Latin American participation
level. At the end of this article I have two specific questions
to ask of anyone interested in helping the effort.
Below are some ideas on what might be done. These are presented
in hopes that some of you might be interested in pursuing some of
them.
Regular E-mail Link
===================
Outbound and inbound gates through which to channel all Latin
American traffic to the U.S. need to be established. As part of
this it would probably make sense to do an analysis of just what
routing was cheapest; e.g. a call during National Mail Hour to
Argentina from the U.S. using MCI costs $1.55 for the first
minute plus $0.66 for each additional minute. Probably far less
than what it costs for Argentina to initiate phone calls. Since
we're all hobbyists we should try to keep costs down, no?
Spanish-language Echo
=====================
This would be a means by which interested people could find out
about FidoNet and new nodes could get questions answered about
participating in the Net. This echo would be a takeoff point and
would hopefully spawn other Spanish-language echos.
FidoNews 4-41 Page 2 9 Nov 1987
We're in the early stages of establishing a three-hub echo
network. Pablo for South America, Juan for Caribbean, and my
node (102/851) for the Southwest. Of course, this is just the
beginning and we would hope that it eventually will include every
Latin American country.
FidoNews Articles
=================
Having something printed in the weekly FidoNews is a good way of
elevating awareness within the FidoNet community. If articles
were published promoting the Spanish-language echo, advancing
growth of the LATINO Net, and occassionally written in Spanish
the network world would certainly become more cognizant of the
effort.
IFNA Promotion Literature in Spanish
====================================
Some of the key IFNA literature needs to be translated into
Spanish for potential Latin American members to understand about
the network and the organization. Without some decent reading it
will be hard for people to get too enthused.
Pablo, Juan and I want to do what we can to help the Net grow.
We hope you'll join us. Give us your ideas, take on some role of
your own, and jump on the wagon.
OK, now for the end of the article and my two questions:
1) Can anyone provide additional names of people in Latin America
who might be interested in joining the Net? We'd like at
least one node in each major city in each Spanish- and
Portuguese-speaking country. Having this would get us to
critical mass and the Latino Net can grow by itself.
2) Anyone out there interested in participating in a Spanish-
language echo? There's a lot of curve climbing that needs to
be done and we would use all the expertise we can get. The
LATINO echo will be available in the U.S. from 102/851.
For further information or for feedback please contact any of the
three of us. We're all available during Mail Hour and soon will
all be up 24 hours per day.
Since discussion has been solicited on Policy4, here are my full
comments on the subject. Each section that will consist of the
section number, original quote, my comment, and a proposed
revision if any. These are emphatically =not= the official
positions of the board of directors, but these are some of the
issues being discussed in IFNA_BOD echo. Make your feelings
known to me or to any member of the Board of Directors.
--------------------
SECTION 1.1 The Levels of FidoNet
"o Nodes; A node is a single FidoNet address, and is the
smallest recognized unit of FidoNet.
o Points; A point is a node on a private network which is
accessible through a node on FidoNet."
COMMENTARY: Smallest? Not an ideal word, especially since some
very popular BBS's have more users than some of the smaller
nets. Could also be perjorative. And in fact, with sub-sub-
points available with PointMap, it's no longer quite true. A
node is, however, the primary building-block of the published
nodelist. I also think it might be nice if we said something
more about bulletin-board systems in these definitions, so as to
put things in terms that even non-FidoNet folk can have a
referent, something to get a handle on what we're talking about.
SUGGESTION:
"o Nodes; A node is a single address in the international node
list, the most basic building block of FidoNet. It usually
corresponds to a single bulletin board system.
o Points; A point is a system which sends or receives mail
through a node, and is not independently listed in the
international node list. As such, there are fewer demands
upon such a system. A point usually corresponds to a single
user of a bulletin board system."
--------------------
SECTION 1.2 Coordinators
"o The Point Coordinator; Any node in FidoNet can act as a
gateway to a point network. ...
o The Sysop; A Sysop formulates his own policy for running his
board and dealing with his users, so that will not be
discussed in this document. ..."
COMMENTARY: Excuse me if I seem obsessed with definitions.
FidoNews 4-41 Page 4 9 Nov 1987
First of all, I cannot think of a single reason why these two
paragraphs shouldn't be merged. Secondly, what exactly is a
sysop? Does a mail-only node have a sysop? How about a point?
Could it be that we should drop the word? I also see no point
whatsoever in discussing at this point in the document what will
not be discussed. If it's not to be discussed, let's not
discuss it!
SUGGESTION:
"o The Node Coordinator (Sysop): Anyone who actually operates a
node on the FidoNet is a Node Coordinator. A Node
Coordinator is responsible for his own network mail and that
of any points below him, or users on his node if he or she
is a system operator."
--------------------
CHAPTER 2 SYSOP PROCEDURES
"A sysop of an individual node can pretty much do as he pleases,
as long as he ... is not excessively annoying to other nodes on
FidoNet, and does not promote the distribution of pirated
copyrighted software."
COMMENTARY: We still haven't defined "excessively annoying."
We need to do so -- or at least give better examples. Are
bombing runs "excessively annoying?" (I think so.) Is sending
advertising un-solicited? (I think so.) How about insulting
another sysop? (I think not.) Racism, sexism, or bigotry? How
about censorship? (Let's discuss these.) And then there's the
whole issue of echomail conduct ... And then there's the fact
that pirating copyrighted software is not the ONLY crime that
can be perpetuated by a BBS. Does this imply that we'll wink at
fraud? Chain-letter or pyramid schemes?
SUGGESTION:
"... is not excessively annoying to other nodes on FidoNet (see
section x.x.x below for guidelines), and does not use the
FidoNet for the commission of a crime, such as distribution of
pirated software."
--------------------
CHAPTER 2 SYSOP PROCEDURES
"National Mail Hour is the heart of FidoNet, as this is when
network mail is passed between systems. Any system which wishes
to be a part of FidoNet must be able to receive mail at this
time. ... Failure to observe the proper mail events is
sufficient grounds for any node to be dropped from FidoNet
without notice (since notice is generally given by FidoNet
mail). ..."
COMMENTARY: Now that the use of Points makes possible special
FidoNews 4-41 Page 5 9 Nov 1987
gateways, I think this is even more important than ever. I
stand 110% four-squarely behind these paragraphs. Now ... do we
want to go farther? Consider the existence of nodes with no
listed phone number. (1) Since no one can call them without
making special arrangements, do they need to observe NMH? On
the other hand, (2) since they cannot be called directly, do
they have any place in the nodelist? One area where I feel
particularly strongly about this is unlisted nodes not in a
network, since there is effectively no way to send mail to these
people - so why list them at all?
--------------------
SECTION 2.1 How to get a node number
"Your application for a node number must be sent to the
coordinator by FidoNet mail, and must include at least the
following:
1) Your name.
...
6) The maximum baud rate you can support."
COMMENTARY: As a person who finds Bob Hoffman's use of another
machine to mimic the one he wanted, thereby requesting two
separate node numbers from the same machine, excessively
annoying, I would add to this "... directly from the machine
requesting the address, ..." It also occurs to me that this is
an excellent place to enforce at least SOME degree of
familiarity with POLICY4, by adding another requirement.
SUGGESTION:
"Your application for a node number must be sent to the
coordinator by FidoNet mail directly from the machine requesting
the address, and must include at least the following:
...
7) A statement to the effect that you have read, are familiar
with, and will abide by the rules in version 4 of
POLICY.DOC."
--------------------
SECTION 3.2 Node list distribution
"The node list is posted weekly on Saturday, along with a
'difference file' giving the changes for the week. It is your
responsibility to obtain the difference file from your
coordinator every week and to distribute it to the coordinators
below you. ..."
COMMENTARY (Minor quibbles, both): (1) I think it's a bad idea
in general to have so much of the traffic tied to a specific day
when we all know that sometimes it doesn't happen that way.
Frankly, I've set my system up so that whatever day Rich crashes
FidoNews 4-41 Page 6 9 Nov 1987
the NODEDIFF through, I'll process it. So let's make it
"weekly, usually on Saturday." (2) Suggested clarification:
"... and to distribute it to the coordinators and nodes directly
below you."
--------------------
SECTION 3.6.3 Regional Coordinator procedures
"A Regional Coordinator should try to avoid the needless
proliferation of networks. Networks should not be allocated on
any basis other than technical and practical considerations
relating to network mail operations. For example, persons
wishing to establish networks on the basis of special interests
or for company mail should be encouraged to investigate the
alternatives, such as echomail conferences and point networks."
COMMENTARY: I notice that as written, this section makes no
mention of geography. Does this mean that is =is= OK for a node
in Philadelphia to host the network for Arkansas? Does this say
anything about two or more networks that cover the same range of
phone numbers, such as nets 102 & 103, or 125 & 161?
--------------------
SECTION 3.6.4 Network Coordinator procedures
"3) The most common source of routing overload is echomail.
Echomail is a nice invention, and offers great benefits, but
it cannot be allowed to degrade the ability of FidoNet to
handle normal message traffic. If a node in a network is
routing large volumes of echomail, the sysop can be asked to
either limit the amount of echomail, or even to stop routing
his echomail completely. The design of echomail is such that
it is a simple matter to do either of these."
COMMENTARY: As this problem is ancient history, and as this
problem is also used for an example (4.1.7), I find this entire
paragraph redundant. In fact, I'd blow all three of these
paragraphs into one much shorter sentence.
SUGGESTION:
"If for any reason, a single node is receiving a dis-
proportionate amount of the mail addressed to its network, the
network coordinator should require the node to either arrange
for the mail to be sent direct or the node should be referred to
the region coordinator to become an independent node, achieving
the same end."
--------------------
CHAPTER 4 RESOLUTION OF DISPUTES
"... In other words, there are no hard and fast rules of con-
duct, but reasonably polite behavior is expected. ..."
FidoNews 4-41 Page 7 9 Nov 1987
COMMENTARY: I believe we want this to read, "... there are FEW
hard and fast rules of conduct ..."
--------------------
SECTION 4.1 Case Histories
"A few actual case histories of past disputes may be instructive
to show general procedures and methods."
COMMENTARY: And then again, they might not. This whole section
makes me vaguely uncomfortable. It's chatty, it gives few or no
general principles to extrapolate from, and despite the fact
that it coyly leaves out names and addresses, it invites
speculation. (The fact that I happen to be case 4.1.7 is
irrelevant. I'd feel the same way even if it weren't me being
pilloried behind that gauze curtain.) (Grin) I would much,
much rather see this entire section re-written, after MUCH
discussion, into a list of behaviours which have been found
"extemely annoying"<tm?> in the past, and/or which we have
decided (will have decided, rather) are "extremely annoying."
--------------------
SECTION 4.1.1 The Case of the Crooked Node
"A sysop of a local node was using network mail to engage in un-
ethical business practices. ... Independent status was denied."
COMMENTARY: Do we mean illegal? If so, let's say illegal.
Unethical by whose standards? This is why I don't like the
whole coy, chatty/catty tone of this chapter. I =don't= like
the idea that somebody can be kicked out of the nodelist because
one host thinks he's a bit shady. C'mon, are we going to ban
nodes by ambulance-chasing personal-injury law firms? By share-
lease real estate salesmen? Or do we actually want legal
proceedings? Is the word of the local BBB sufficient?
--------------------
SECTION 4.1.6 The Case of the Sysop Twit
"A patron of various local nodes had been roundly recognized by
all sysops as a twit. The user obtained his own system, became
a sysop, and applied for a node number. The Network Coordinator
denied the request. No appeals were made."
COMMENTARY: This one makes me almost as uncomfortable as 4.1.1,
for similar reasons. It's vague. It tells us nothing. What's
a "twit?" Someone who's young? Someone who treats female
users/sysops in a sexist fashion? Or do we have to go all the
way up to attempted crashers ... in which case, this section is
redundant with "The Case of the Hacker Mailer." Is Bob Hoffman
a twit? How about Adam Selene? How about Mike? How about me?
Who decides? And does that last line imply that appeals would
have been seriously considered, or not?
FidoNews 4-41 Page 8 9 Nov 1987
--------------------
SECTION 4.1.7 The Case of the EchoMail Junkey key key
"A local node became enamored with EchoMail and joined several
conferences, routing his outbound mail through his network. He
then started an EchoMail conference of his own and began
relaying EchoMail between several systems, again routing it all
through his network."
COMMENTARY: Since I was there, I know that this one neglects a
lot of what =I= (as the accused) think are important facts: like
the fact that I had permission to route a few of those
conferences through 100/10; the fact that I couldn't bloody well
STOP folks from sending me mail via 100/0 (what was I supposed
to do, mail them a letter bomb?); and the most important fact
that the packets that actually affected network mail performance
were NOT intentional on my part, they were accidental - I had my
route-file set up incorrectly. Would Ken Kaplan really have
ejected me from the node list for an honest, easy-to-make
technical mistake which I corrected as soon as possible?
Preferred Inbound and Alternate Inbound
A Routing Proposal
(This article is NOT COPYRIGHTED and may be reproduced by anyone,
in any form, with no strings attached.)
The present scheme of regions, hosts, hubs, and nodes within
Fidonet was developed in an era when, by and large, all telephone
costs were distance-sensitive (and where the costs always
increased when your call terminated at a more distant point).
Even at that time those assumptions were not always true (due to
the use of leased lines and the generally higher cost for in-
state calls as opposed to out-of-state calls) but now that we
have PC Pursuit and AT&T's Reach Out America plan, distance is
often of no consideration in making modem calls.
Still, nets are often arranged geographically, with all BBS's in
a given region grouped together on a geographic basis. This
works well enough when an entire net is located in a major
metropolitan area, but it often does not meet the needs of Sysops
in more remote areas.
The major reason that it doesn't work well is that the backwater
Sysop's HOST is probably accessible only via the long distance
phone system, and the HOST itself may be in only a medium-sized
city. Consider, for a moment, the disadvantages that our rural
Sysop will face:
1) He will probably be expected to POLL his host for mail on a
regular basis, even though the volume of received mail may be
very low.
2) He probably does not yet have access to an alternate long
distance carrier, let alone a packet network or PC Pursuit, so
his calls to the host will be at AT&T long distance rates. If
the host is located in the same state and is some distance
away, those rates may be VERY high, even at night!
3) If the host is not in a PC-Pursuitable city, other Sysops will
charge their users to send mail through to the remote board
(if they allow it at all). This, in turn, will lower the
volume of received mail, making the prospect of having to poll
the host regularly even less attractive.
What we are talking here is COST. The Sysop who is out of the
mainstream of traffic may have expenses that are many times those
of a sysop living in a larger city. But inefficient routing can
also affect Sysops in more populated areas. For example, if your
inbound host is a long distance call (and is not PC Pursuitable),
it's still going to cost you to connect with him even though you
may be able to access other hosts (of other nets) for free or for
less money.
I'm sure that others have suggested that the whole Fidonet system
FidoNews 4-41 Page 10 9 Nov 1987
be reconfigured to take maximum advantage of PC Pursuit or Reach
Out America or some other quirk in local calling rates. There
are a couple of major problems with that, however. The first is
that if the service that the net is configured around goes down
or has a dramatic rate increase, you're right back to inefficient
routing (for example, if the proposed FCC regulations go through
and PC Pursuit is discontinued, I can guarantee you that there
will be some major changes in the way that Echomail is being
routed!). The second is that the geographic unity of a net is
not something that should be easily cast aside. It is nice (and
usually very beneficial) to be in frequent communication with
other Sysops in your own area!
Therefore, I have a proposal that would retain the present
net/hub/node structure but would allow calls to be rerouted based
on least-cost principles, where the sysop of the receiving board
is willing to put a little effort into making it happen. My
proposal involves new comments in the miscellaneous field of the
nodelist:
AI:net/node - An alternate inbound routing that MAY be used if it
is less cost to the calling board.
PI:net/node - A PREFERRED alternate inbound routing that SHOULD
be used by the calling board if it is the same cost
or less cost than host routing or direct routing.
This might be used when it is a toll call from the
receiving board to the net host, but a "free" (PC
Pursuit, possibly?) call to the preferred
alternate.
In either case, more than one net/node may be specified. Let me
give a hypothetical example of how such routing might save some
money. Since a picture is supposed to be worth 1,000 words and
I'm tired of typing, please refer to the following diagram of
nodes in imaginary net 999:
999/999 999/123 888/888 777/777
BACKWATER <-----> SMALLTOWN ----> HUBTOWN -----> METRO
x x
| | (TELENET (PC PURSUIT
x x ACCESS) INBOUND CITY)
HOST 999/0 (TOLL CALL)
Let's assume that BACKWATER is at the edge of nowhere, but is
within the local telephone calling area of SMALLTOWN, which is,
presumably, in the middle of nowhere! In our hypothetical
example, the Net 999 Host is a toll call for both boards but the
Sysop of the Smalltown board happens to be a business owner with
a direct line (foreign exchange or WATS, perhaps) to HUBTOWN,
which as it happens is the location of a HUB for net 888
(unfortunately, that's NOT part of the same net!). Our Smalltown
BBS operator POLLs the Hubtown node daily to pick up echoes and
whatever mail might be incidentally routed that way. Meanwhile,
the Hubtown node operator, which has access to a Telenet local
line, places a daily call via PC Pursuit to POLL node 777/777 in
FidoNews 4-41 Page 11 9 Nov 1987
METRO for mail.
Under the present setup, both the Backwater and Smalltown Sysops
would have to POLL their host to receive incoming matrix mail.
Of course, they could realign themselves to be under Net 888,
ASSUMING that the host of node 888 has no objections and the
regional coordinator(s) involved are willing to allow the
transfer - but what if, two months later, the Sysop of the
Smalltown node decides to pull the plug on his system? Then the
Backwater Sysop is left high and dry, with no connection to Net
999 and the possibility of a not-too-satisfying relationship with
Net 888.
Let's suppose, however, that our Backwater Sysop would take the
initiative to contact all of the nodes involved and set up the
following arrangement:
METRO 777/777 receives mail for Backwater - this in effect makes
the Backwater board PC Pursuitable for mail purposes - and HOLDs
it for pickup by HUBTOWN 888/888. HUBTOWN 888/888 in turn HOLDs
it for pickup by SMALLTOWN 999/123. When 999/123 receives the
mail packet, he immediately CRASHes it to 999/999 because it's a
local call. This much of it is all workable under the present
system. The only problem is that any Sysop that simply runs
Xlatlist, without knowing about this arrangement, will
automatically route mail for 999/999 to the Host (999/0) which,
as noted earlier, happens to be a toll call for the Net 999
boards in question.
Now, if our Backwater Sysop could some convince everyone to ARC
his mail TO 888/888 or 777/777, he'd be in fine shape. He
wouldn't have to Poll the host to get his mail. So how does he
do this? Under my proposal, he would place this comment in the
nodelist:
PI:888/888 777/777
This would tell other Sysops that, if it is a toll call to his
board, he would prefer that mail be routed to 888/888 or 777/777
rather than to the Net 999 Host. On the sending end, the program
that handles the mail (that would have to be written to implement
this scheme) would use this logic to route the outgoing call:
1) Is 999/999 a local/zero cost call? If so, direct route it.
2) Is 888/888 a local/zero cost call? If so, route it via
888/888.
3) Is 777/777 a local/zero cost call? If so, route it via
777/777.
4) Is the HOST (999/0) a local/zero cost call? If so, host route
it (the HOST may still receive some inbound mail for this
node, but he may be able to Arc it To a node in the Backwater
system's "free" path, if the call is also "free" for him.)
FidoNews 4-41 Page 12 9 Nov 1987
5) If all of the above are toll calls, then check the cost fields
to determine which of routing direct to 999/999, indirect via
888/888, indirect via 777/777, or indirect via the host
(999/0) is the least expensive and use that method.
6) Where the costs are the same, the first choice would be direct
routing. Since this was set up as a Preferred Inbound, the
second and third choices would be to route via 888/888 or
777/777. Host routing would only be used if it was clearly
the lowest cost choice for the sender.
Now let's change the scenario a bit. Suppose that the above
diagram is the same except that the HOST happens to be a local
call. In this case, the Backwater Sysop isn't out anything when
he polls the host, so he doesn't care if other boards send mail
directly to his board, or route it via his Host. The only
problem with this scenario is that the Host isn't in a PC
Pursuitable city, which means that users in distant areas have to
pay their Sysops to send mail to Backwater. Now, instead of PI:
(Preferred Inbound), the Backwater Sysop would use AI: (Alternate
Inbound). This simply reverses the priorities so that Host
routing would be preferred over the use of 888/888 or 777/777 for
inbound mail, BUT if it is a zero cost (or lower cost) call for
the originating BBS, it MAY route via one of the other two
boards.
Of course, the above describes one particular situation (any
similarity to a real-life situation is purely coincedental) but
the ability to use the PI and AI comments (one or both) in the
comment field might permit mail to flow at a lot lower cost.
More importantly, I think, is that existing Net bonds are not
destroyed and if something changes, changing the preferred or
alternate routing is as easy as making a change in the nodelist.
Now, how would a PI: or AI: be used at the sending end? Well,
the lo-tech method would be for a Sysop to manually eyeball the
nodelist and look for the PI's and AI's. Let's suppose he found
the Backwater BBS and, because he was a PC Pursuit user, could
call 777/777 for free. He would then insert a statement such as
ArcTo 777/777 999/999 in his route control file. Most Sysops
wouldn't enjoy doing this very much (although they might make the
necessary adjustments for frequently-called nodes), so I'm sure
that someone would write a utility that would scan the nodelist
(after xlatlist processing) and generate appropriate statements
for the route control file. Such a utility, when it encountered
a PI: or AI: statement, would check the cost fields of the boards
referenced by the PI: or AI: and generate any necessary
statements based on the logic outlined above. If the board with
the PI: or AI: statements happened to be a Host or a Hub, then
the routing for all boards below that host or hub would also be
checked and changed if the alternate routing could be
accomplished at lower cost. Ultimately, a new version of
xlatlist might handle all of this automatically, or a newer
version of the BBS or mail-handler program (whichever brand
you're using) might read the comments and make the necessary
adjustments in calling patterns.
FidoNews 4-41 Page 13 9 Nov 1987
As with anything, this kind of alternate routing capability could
be misused (I can envision "super" mailboards in the large PC
Pursuit cities becoming nearly impossible to reach due to
overloads), so it would have to be used with some restraint to
spread the message traffic evenly. But I also think that many
Sysops would welcome this method of reducing costs for outgoing
mail, while at the same time encouraging a freer flow of mail to
the boards in the outlying areas.
Comments on this proposal may be left to me via the BIXNET BBS
(120/64, 616-361-7500 300/1200/2400bps), although I really can't
do much more to develop it. The idea is simple, could be
implemented NOW in a limited manner, and when appropriate
software is written could be more fully implemented. For the
present, a Sysop could just ignore the PI: and AI: comments and
continue to Host route mail, or could manually make changes to
his route control file for as many boards as he cares to make the
effort. I hope that this idea will receive some consideration
among those in the Fidonet community.
Did you ever try to send 4096 blocks of echomail to someone, just
to have the line die on you after 4095 blocks? Frustrating,
isn't it?
A few people have thought about ways to handle that. Answers
range from lots of little mail relays throughout the day to
implementing a ZMODEM based protocol that can resume an aborted
transfer in the middle. But nobody has actually implemented a
workable solution. Until now, that is.
As of 3 November 1987, SEA has released version 1.11 of our
popular ARCmail program. This version adds a variation of the -d
parameter to create discrete archives based on the size of the
previous archive. For example, suppose you have two mail
archives waiting to go out. One of them is going to 107/312 and
is 120k in size. The other is going to 107/16 and is 50k in
size. You are now about to send another 30k of mail to each
person. If you give the command:
arcmail to 107/312 107/16 -d100
ARCmail 1.11 will add the packet to the archive to 107/16,
because his archive is still small. But the archive for 107/312
is larger than 100k, so ARCmail will create a new archive for
him. "-d100" means "create a new archive if the old one is larger
than 100k" (you can vary the size, of course).
So how does this answer the problem, you ask? Simple. SEAdog
keeps track of what files have or have not been sent, and will
not resend a file that has already been sent. Thus, the 4096
block archive in our earlier example will now be sent as five
smaller archives, and if the line drops while the last archive is
being sent, then ONLY the last archive will be sent on the next
call.
In other news, we have also released version 1.23 of the DTTY
terminal program. DTTY still isn't very bright, but now she
knows better than to call a board that has an unpublished number.
Two other changes have been made:
1) DTTY will now respond to an ENQ with your name, as listed in
your CONFIG.DOG file, in the format "First;Last". People who
call TBBS boards a lot should appreciate this.
2) The Give and Ask commands have been modified to work with
Opus upload and download. Any of the DTTY supported
protocols may be used.
FidoNews 4-41 Page 15 9 Nov 1987
Products mentioned in this article may be file requested from
1:107/6 at any time outside of National Mail Hour, or may be
downloaded from the SEA customer support board at (201) 473-1991.
How convenient that the Oct 5 FidoNews should have a request
for suggestions on where FidoCon V should be held, I just send a
letter to Mr. President about where I thought it should be held.
Well, I'll publish it here and forward a copy to the RIGHT place,
now.
Although I cannot answer every question posed there, I can
probably get pretty far. My suggestion is to hold it at the
InfoMart in downtown Dallas. Dallas is home to many computer
hobbists (just look at the size of net 124) and the InfoMart is
an ideal place for any computer-related conference. It is seven
floors and features such things as talking elevators, automatic
flushing urinals (programmers are so forgetful), a bar, a
cafeteria, underground parking, many many many rooms and
auditoriums, a computer bookstore, and a basement that can hold
several hundred vendors.
The InfoMart was specifically designed for computer
conferences and for permanent vendor displays. Tandy, IBM, Xerox,
and many other companies whose names I've never heard of have
permanent "booths" there where clients can come by and get
demonstrations. It is also the home, on the 2nd Saturday of every
month, of the Dallas Computer Council user's group meetings,
where hundreds of vendors with rock-bottom prices crowd the
basement and groups for Apples to Zeniths have their meetings and
talk about everything from C to 1-2-3 to dBase, representing
almost every interest.
Since it is in downtown Dallas, I imagine everything you need
will be right there. There is public transportation (DART), but
as far as "shuttles" as such I do not know. There are hotels down
there, and I'm sure they've struck up some kind of deal with
InfoMart. I'm sure the price is right; if DCC, being made almost
exclusively of hobbists, can meet there every month without
charging a mandatory fee, I'm sure we can, particularly if we can
produce non-profit organization status. Net 124 would probably
host it if it came to that (Wynn Wagner lives in Dallas, another
plus), and I certainly can't speak for them whether they can do
all those things (make T-SHIRTS and SOUVENIRS available? GIMME A
BREAK!) but net 124 is strong and I'm sure they could if they
wanted to. Net 130 (Fort Worth, a half-hour away) would be
willing to help if it came to that.
Since August gets really hot in Dallas, I recommend something
earlier, perhaps the second or third week in June or thereabouts,
or even in July.
Dallas is a growing technological city that can offer an
awful lot in the area of entertaining Fido sysops. InfoMart is an
excellent place for a computer conference and was designed
FidoNews 4-41 Page 17 9 Nov 1987
specifically for that purpose. The airport is easily accessable
and DFW is a major airport (it is one of American's hubs) and
there should be no problem getting a non-stop. I hope that IFNA
will seriously look into Dallas as the home for FidoCon V (geez,
that sounds like a sci-fi movie....)
14 Nov 1987
The First New England Sysop Conference, to be held at the
Lederle Graduate Research Center, 16 Floor University of
Massachusetts, Amherst. Contact Mort Sternheim at 1:321/109
for details.
7 Dec 1987
Start of the Digital Equipment Users Society meeting in
Anaheim, CA. Contact Mark Buda at 1:132/777 for details.
24 Aug 1989
Voyager 2 passes Neptune.
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
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.
Don Daniels, President
International FidoNet Association
FidoNet 1:107/210
IFNA Status Report for November 1987
PROGRESS DURING THIS PERIOD
General
I am sorry to report that this Status Report will not be as
positive as I might had hoped, as we are still being plagued by
start-up problems. That is not to say that a lot of
individuals have not pitched in are doing a good job, because
that does seems to be the case. Rather, our problems seem to
primary be that of an administrative and management nature. It
is hoped, however, that we are building up some inertia in the
right directions.
This month I only received two status reports from the various
Committee Chairmen. A synopsis of their reports and some
additional concerns are included below.
Administration and Finance
Ken Kaplan met with Treasurer Leonard Mednick in St. Louis in
what seems to have been a very productive meeting. Len informs
me that we is still waiting on some additional material being
forwarded by Ken, but we have already seen the beginnings of
new forms and procedures to make various of our operations
easier to perform and manage.
Board of Directors
No report this month.
By-laws and Rules
The Chairman of this committee informed me that he was taking a
month off because of some personal concerns. Last night I
heard that he is back and will be picking up efforts next
month.
Executive Committee
This month has primarily centered on organizational concerns.
International Affairs
This committee has not still not "met" as of yet, primarily
because of our own domestic focus. However, so many items of
concern are happening overseas that it looks like we can't put
this off any longer.
Membership Services
FidoNews 4-41 Page 20 9 Nov 1987
No report.
Nominations and Elections
Dave Dodell informs me that primary activity centered on
discussions on how to secure echomail voting by email. Legal
rulings from IFNA Counsel indicate that voting by electronic
means would not be invalid. Encoding of passwords in voting
messages is being studied.
Publications
Although not officially received, Brian Hughes indicated he has
resigned as Chairman. Ken Kaplan has named Tim Sullivan as the
replacement.
Technical Standards
No report.
PRESENT PROBLEMS
General
Getting such a large body to develop inertia in the right
direction is proving very difficult considering the limited
resources that can be brought to bear. My apologies to those
who have suffered from our lack of expedient responses.
Administration and Finance
No significant problems reported at this time.
Board of Directors
We have still not learned how to actually conduct business in
an EchoMail environment. Overcoming this will take
considerable discipline.
By-laws and Rules
Specific direction has still not been received from either the
BoD or Executive Committee.
Executive Committee
We have not yet resolved how we will meet our obligations to
meet "at least quarterly" and handle all the concerns that are
being placed before us. The problem with working in EchoMail
has resulted in many delays which in turn are causing friction
with those laying business before us. We are currently divided
as to how best to proceed.
International Affairs
A very large storm seems to be brewing in Australia. Distance,
of course, makes it difficult for us to effectively intervene
and provide assistance.
Membership Services
None reported at this time.
Nominations and Elections
None reported at this time.
FidoNews 4-41 Page 21 9 Nov 1987
Publications
With no Chairman, this committee has not been in operation.
Technical Standards
No report.
PROGNOSIS FOR THE COMING MONTH
General
It is hoped that we will solve some of organizational problems
this month and get on to the backlog of business.
Administration and Finance
Leonard Mednick will continue to take over much of the
administrative factors previously handled exclusively by Ken
Kaplan.
Board of Directors
No Report.
By-laws and Rules
Activity in this committee will mostly still be tabled.
Executive Committee
As this Committee is required to meet quarterly it is expected
that much of the orgainizational concerns and backlog of work
will be addressed this month, providing some acceptable
compromise can be met on how to meet.
International Affairs
This committee will begin to get underway this month.
Membership Services
No report. FidoCon proposals should be acted on, however.
Nominations and Elections
Furthur development of electronic voting with appropriate
software development.
Publications
Installation of new Chairman should get this committee rolling.
Membership for the International FidoNet Association
Membership in IFNA is open to any individual or organization that
pays an annual specified membership fee. IFNA serves the
international FidoNet-compatible electronic mail community to
increase worldwide communications. **
Name _________________________________ Date ________
Address ______________________________
City & State _________________________
Country_______________________________
Phone (Voice) ________________________
Net/Node Number ______________________
Board Name____________________________
Phone (Data) _________________________
Baud Rate Supported___________________
Board Restrictions____________________
Special Interests_____________________
______________________________________
______________________________________
Is there some area where you would be
willing to help out in FidoNet?_______
______________________________________
______________________________________
Send your membership form and a check or money order for $25 to:
International FidoNet Association
P. O. Box 41143
St Louis, Missouri 63141
USA
Thank you for your membership! Your participation will help to
insure the future of FidoNet.
** Please NOTE that IFNA is a general not-for-profit organization
and Articles of Association and By-Laws were adopted by the
membership in January 1987. The first elected Board of
Directors was filled in August 1987. The IFNA Echomail
Conference has been established on FidoNet to assist the
Board. We welcome your input on this Conference.
The IFNA publications can be obtained by downloading from Fido
1/10 or other FidoNet compatible systems, or by purchasing them
directly from IFNA. We ask that all our IFNA Committee Chairmen
provide us with the latest versions of each publication, but we
can make no written guarantees.
System Enhancement Associates SEAdog $60.00 _____
ONLY 1 copy SEAdog per IFNA Member.
Fido Software's Fido/FidoNet $65.00 _____
ONLY 1 copy Fido/FidoNet per IFNA Member.
As of November 1, 1987 price will increase to
$100. Orders including checks for $65 will be
returned after October 31, 1987.
SUBTOTAL _____
Missouri Residents add 5.725 % Sales tax _____
International orders include $5.00 for
surface shipping or $15.00 for air shipping _____
TOTAL _____
SEND CHECK OR MONEY ORDER TO:
IFNA
P.O. Box 41143
St. Louis, Missouri 63141 USA
