textfiles/bbs/FIDONET/JENNINGS/STANDARDS/fidonet.doc.txt

Tom Jennings
30 Apr 84
Fido #1: (415)-864-1418

	Some preliminary ideas for the FidoNet. (If you<6F>
haven't heard, FidoNet is an intersystem message forwarding<6E>
system mostly for Fidos, but could be used for others as<61>
well.)

	Please, don't worry about all the seeming complexity<74>
here. Most will go away. I have just typed everything I<>
could think of all at once, and not all is applicable.<2E>
(Besides, you're (probably) not gonna code it.)

	There are some points that need ideas: mainly, how<6F>
to pay for it, how it will appear to callers trying to send<6E>
mail, and any mysterious operational type problems you see.<2E>
Like most of Fido, I imagine this too will be built with 90%<25>
suggestions.

	If you have any ideas on this proposed system,<2C>
please leave me a note on Fido #1 at the above number.<2E>
Thanks.

		O P E R A T I O N


	From a callers point of view, the system will have<76>
one additional feature when entering a message. One way or<6F>
another the caller tells Fido which system the message is to<74>
be sent to. This could consist of a prompt (System A, B,<2C>
...) or some such thing. (Any ideas?)

	In any case, mail will only work from a MAIL<49>
subdirectory. Messages left here will be like all other<65>
messages; readable or not, depending on the privacy, etc.<2E>
Replies can be left, etc, which get mailed in the same way.

	It may be desirable to search this area for each<63>
user after signon, the same way message searching works now.<2E>
If old messages don't pile up like in other areas, this<69>
should be nice and fast.

	There will not be any automatic confirmation of<6F>
received messages. It will be up to the user to do so, by<62>
mailing a message stating that is was received. Maybe it<69>
will be possible to confirm, by reading the RECV'D flag from<6F>
the message, but that won't go into the first one.

	In the MAIL area, the usual message search<63>
("Messages to you" etc) should be adequate, if mail traffic<69>
is less than or the same as the current message traffic.

	I M P L E M E N T A T I O N

	The only change to Fido will be a new command line<6E>
parameter:

	<number>/Y
	<number>/W

	/Y Is the hour of the day to start doing mail as<61>
opposed to normal BBS stuff. /W is the window width, in<69>
minutes, to do mail in. For example, 0200/Y 90/W says do<64>
mail from 2:00AM, for up to 90 minutes, i.e. until 3:30AM.<2E>
During this time, Fido will not accept any normal callers.<2E>
Also, outside these times, Fido will not accept mail. If no<6E>
switch is present, or the window is set too small (TBD) then<65>
it will not send or receive mail, like it does now.

	Neither will it bump someone off if they happen to<74>
call just before the appointed time. However, as soon as<61>
they logoff, it will start handling mail if it's supposed<65>
to.

	The mailer (the program that actually sends and<6E>
receives mail) is a seperate program. It is run from the<68>
batch file (RUNBBS.BAT) right after Fido.EXE. This works<6B>
like Control-C and errors do; via ERRORLEVEL. For instance,<2C>
the batch file might look like:

	    FIDO  ... 0200/Y 90/W
	    IF ERRORLEVEL 4 GOTO MAIL
	    IF ERRORLEVEL 1 GOTO END
	    RUNBBS
	MAIL:
	    MAILER 0200/Y 90/W
	    RUNBBS
	END:

	Like current Fidos, ERRORLEVEL is 0 if normal<61>
termination (caller hung up, etc) 1 if Control-C or stack<63>
overflow, 2 if disk file error (disk full, missing files,<2C>
etc) or 4, the new level for: "Time to do Mail".

	If it's time to do mail, Fido exits with ERRORLEVEL<45>
4. If 4 or higher, it runs MAILER, which then runs<6E>
RUNBBS.BAT which starts it all over again. Otherwise, if 1<>
(or higher) it is an error, it goes to the end and stops.

	When run, the mailer sits and waits for phone calls,<2C>
or if instructed to do so, (command line switches or a<>
command file, whatever) makes calls. If a human type caller<65>
calls, they will get a message to the effect "Waiting for<6F>
mail, please call back after <xxx>", where <xxx> is the end<6E>
of the window to wait for mail, and hang up on them. (The /W<>
and /Y switches will be duplicated in the mailer, for<6F>
reasons I'll not bother with now.)

			C O S T

	First, it is very important that we figure out what<61>
it would cost. This is the second most important part. The<68>
cheaper it is, the more likely FidoNet can be made operable.<2E>
However, no matter how cheap it is, if an ingenous way of<6F>
paying for it doesn't exist, then it all falls flat.

	Right now, late night long distance (coast to coast)<29>
toll charges are about $13.00 per hour. ATT is proposing, as<61>
part of some other boring issue, lowering this to $10.00 per<65>
hour. This is quite cheap; a lot of messages can be sent in<69>
an hour.

	I hereby declare the mail size unit to be the Cubit:

	1 Cubit == 80 characters * (1200 / baud rate)

	A cubit of mail sent at 300 baud will cost 4 times<65>
as much as one sent at 1200. When 4800 baud modems become<6D>
available, the price per cubit will drop.

	Unlike commercial mail systems that are out for<6F>
profit, FidoNet's mail unit, the Cubit, is small enough to<74>
account for very small messages, but large enough not to be<62>
too small to account for. There are 12.8 cubits in a K byte. 

	An error checking transfer protocol is needed;<3B>
XMODEM will not be used, as transfer times routinely double<6C>
with long phone lines. (Dont want to pay for that.) More on<6F>
that later.

	As an example, say we want to send a small (five<76>
lines, 64 characters per line) message from Los Angeles to<74>
New York. Each message has a header (to, from, date, etc)<29>
that consumes about 80 characters. Assume also that the<68>
transfer rate is 1200 baud, and also that the transmission<6F>
method has a 10% overhead. 

Msg size:	      4.	Cubits
Message Overhead:     1.	Cubit
Message Size:	      5.	Cubits
Message Size:	    400.	Characters

Cost Per Hour:	     13.00	Dollars
Chars/Second:	    120.0	(10 bits/char)
Cubits/Second:	      1.3636..	(120sec / (cubit * 1.10))

Cubits/Hour:	  4,909.	(3600 sec * cubits/sec)
Cost/Cubit:	      0.2648	Cents ($13.00/cubits/hr)

Sample Msg Cost:      1.324	Cents

	Yes ... its cheap. Remember, this is pure cost, no<6E>
hardware maintenaince overhead, no payroll, no profit, etc.<2E>
Delivery time, nor even delivery, is garenteed. The above<76>
does NOT include any connect/disconnect or disk access<73>
overhead. However, it also does not count any savings from<6F>
text compression, which could save 10% to 40% maximum.<2E>
Probably more like 20% maximum in the real world.

	P A Y I N G    F O R    A L L    T H I S

	This is the most serious problem. The technical part<72>
is easy! Also, BBS's in general are run more like little<6C>
fiefdoms than businesses, in the sense the are usually<6C>
operated privately, and almost never pay for themselves,<2C>
never mind make money! If FidoNet takes inordinate amounts<74>
of effort on the part of the sysop, it'll probably fold up<75>
due to that also.

	There are a couple of ways this can be paid for, but<75>
none are really any good for typical free systems. (Note<74>
that receiving (accepting) mail costs nothing. FidoNet might<68>
be able to operate well with only a few well placed<65>
"benefactors", and work acceptably well with only local<61>
"paying" nodes, if mail is limited to say, an area code.)

	IF YOU HAVE ANY IDEAS AT ALL ON THIS SUBJECT PLEASE<53>
LET ME KNOW!!!!!! THIS WILL MAKE OR BREAK THE FIDONET<45>
IDEA!!!!

	In any case, some sort of accounting will have to be<62>
done. Except for very rare cases, mail will have to be paid<69>
for. The mailer will be able to account for each messages<65>
cost, length of transmission, etc. There must be a method<6F>
for limiting mail sent by a specific user, and a "sysop"<22>
type feature for relatively unlimited, or at least<73>
differently limited, mail. The information associated with a<>
peice of mail will have to be worked out in detail later,<2C>
and while not too complex (any complexity can be put upon<6F>
the mailer) it must be adequate for future expansion.

	Presumably, not everyone will be allowed to forward<72>
mail indescriminately. That would be awful nice, but<75>
unfortunately not practical. There may be exceptions: for<6F>
instance, for a club-run system, you might want to let any<6E>
user send a fixed amount of mail over a fixed period of<6F>
time, say, a month. If it was a dues paying club, a number<65>
could be worked out that would accomodate this. Anything<6E>
beyond that amount would have to be accounted for by some<6D>
other method.


IDEA #1

	Club-run systems. Basically, covered above.

IDEA #2

	Private, pay-ahead system. While this is very<72>
workable, it means even more work for the sysop, and<6E>
probably some legal liability, like running a business,<2C>
unless the proper rigamarole wording is used, i.e.<2E>
"donations" not "charges".

	No one will be able to send mail unless they mail<69>
some amount of money to the sysop. The amount donated is<69>
kept in a list maintained by the mailer, who subtracts the<68>
cost of the message from the balance. Usual warnings if not<6F>
enough, etc, and probably a warning when it reaches some<6D>
threshold.

		T H E    N E T W O R K


	Might as well be trendy and use some network<72>
terminology here. Some of it's even handy.

	The topography of FidoNet is in keeping with<74>
bulletin board philosophy; totally random and as little<6C>
organization as possible. Also, there is no control over the<68>
location of the various message nodes (mail send/receive<76>
systems).

	My first thought was to pass mail over as short a<>
distance as possible; however, this is a waste of time, as<61>
late night long distance calls are charged on a per hour<75>
basis, and in any case the more transfers the higher<65>
likelyhood of messages getting lost.

	Message delivery time, if all is well, should be<62>
overnight. If a system goes down, delays will be in<69>
increments of 24 hours.

	There should also probably be a "broadcast" type<70>
message, that stops at each node. Also, there really isn't<>
anything stopping binary files from being mailed; they are<72>
not included here mainly because costs will skyrocket, but<75>
it would be a nice way to do Fido updates, etc.


	So, my current idea (any other ideas at all<6C>
welcome!) is:

	Each sender has a list of systems it can forward to.<2E>
This can be used to limit forwarding to non-toll call areas<61>
if desired. Also, this same list can be used to send mail<69>
destined for one system, to be sent to a different system,<2C>
for further forwarding. This allows cheapskates to let<65>
someone else make the toll calls. (If they in turn let it<69>
go) Also, it lets a well funded system forward mail for<6F>
other systems.

	If there are messages destined for five different<6E>
systems, there will be five calls made (unless the<68>
abovementioned forwarding is done). This "nodeless" system<65>
is then relatively insensitive to down machines, etc, such<63>
that only mail for the down system will not be sent. 

	If the net gets tied up (everyone calling everone<6E>
else, for instance, though I think thats unlikely!) then<65>
some message forwarding can be done to lessen the traffic<69>
load between busy systems.