bbs/deb-mbse
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updated documentation

Browse Source
This commit is contained in:
Michiel Broek 2004-01-11 16:50:10 +00:00
parent 2257b2bc25
commit 40e2939e73
38 changed files with 50 additions and 17437 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
html/Makefile
View File

@ -9,17 +9,7 @@ H_BASE = dist.html manual.css \
intergate.html intro.html invoking.html faq.html \ intergate.html intro.html invoking.html faq.html \
known_bugs.html mgetty.html routing.html nodelist.html known_bugs.html mgetty.html routing.html nodelist.html
H_FTSC = ftsc/fsc-0039.html ftsc/fsc-0056.html ftsc/fsc-0087.html \ H_FTSC = ftsc/index.htm
ftsc/fts-0007.html ftsc/fsc-0046.html ftsc/fsc-0057.html \
ftsc/fsc-0091.html ftsc/fta-1005.html ftsc/fts-0008.html \
ftsc/fsc-0048.html ftsc/fsc-0059.html ftsc/fts-0001.html \
ftsc/fts-0009.html ftsc/fsc-0049.html ftsc/fsc-0062.html \
ftsc/fsc-0093.html ftsc/fts-0004.html ftsc/index.htm \
ftsc/fsc-0050.html ftsc/fsc-0070.html ftsc/fts-4008.html \
ftsc/fts-5000.html ftsc/fsc-0053.html ftsc/fsc-0072.html \
ftsc/fsp-1002.html ftsc/fts-0006.html ftsc/fsc-0035.html \
ftsc/fts-4009.html ftsc/fsp-1011.html ftsc/ftscprod.html \
ftsc/fsc-0088.html ftsc/fts-4001.html ftsc/fts-5001.html
H_IMAGES = images/b_arrow.png images/magic.png images/nodes1.png \ H_IMAGES = images/b_arrow.png images/magic.png images/nodes1.png \
images/connec.png images/mbsetup0.png images/nodes2.png \ images/connec.png images/mbsetup0.png images/nodes2.png \

9
html/dist.html
View File

@ -14,7 +14,7 @@
</HEAD> </HEAD>
<BODY> <BODY>
<BLOCKQUOTE> <BLOCKQUOTE>
<div align="right"><h5>Last update 15-Aug-2003</h5></div> <div align="right"><h5>Last update 11-Jan-2004</h5></div>
<div align="center"><H1>Unix Distributions.</H1></div> <div align="center"><H1>Unix Distributions.</H1></div>
<H3>Which distribution</H3> <H3>Which distribution</H3>
@ -59,9 +59,14 @@ The installation works on a Debian 2.1, 2.2 and 3.0 distribution without any pro
How to build an optimized Debian system is not tested by me. How to build an optimized Debian system is not tested by me.
<P>&nbsp;<P> <P>&nbsp;<P>
<H3>GenToo</H3>
<P>
Installation and startup scripts are tested on GenToo.
<P>&nbsp;<P>
<H3>FreeBSD</H3> <H3>FreeBSD</H3>
<P> <P>
I test on FreeBSD 3.2 and 4.4 stable releases. I tested on FreeBSD 3.2, 4.4 and 4.7 stable releases.
The setup is quite simple, do a small setup (average user), and add some needed packages The setup is quite simple, do a small setup (average user), and add some needed packages
from the ports collection such as gcc, mgetty, infozip etc. The test machine from the ports collection such as gcc, mgetty, infozip etc. The test machine
has a 500 MB harddisk, about 250 MB is still free. Note that the older has a 500 MB harddisk, about 250 MB is still free. Note that the older

80
html/ftsc/fsc-0035.html
View File

@ -1,80 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Transparant Gateways to and from FidoNet.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Transparent Gateways to and from FidoNet <tm>
Technical Considerations
FSC-0035
Michael Shiels 22 June 89
Copyright 1989, Michael Shiels. All rights reserved. The right to distribute
for non-commercial use is granted to the FidoNet Technical Standards Committee,
provided that no fee is charged. This may be posted on FidoNet electronic BBSs
which charge no fee for accessing this document. Any and all other reproduction
or excerpting requires the explicit written consent of the author.
Gateways
--------
Gatewaying between Fidonet and other networks seems to be the latest feature
which hopefully brings more benefits to the users of each network. But there
are some real problems with gatewaying and doing "transparent" replies.
This proposal should allow for almost totally transparent gateways but requires
the co-operation of BBS software writers to support this following protocol.
Incoming Messages
-----------------
When a message is entered into fidonet from another network it will be entering
through one machine (say 1/2). The userid on the other network may not match
very will with the 2 word 36 character userid on Fidonet. So the following is
done to store away the proper userid of the sender.
Two (2) lines are added to the message (usually at the top of the text portion
hidden by the infamous ^A KLUDGE).
^AREPLYADDR .....\r
which signifies the FULL userid of the person on the other network. The first
36 characters or the full userid if less than 36 characters long, are stored
in the FROM field of the message header. When replies are done they use a
second line of the following form.
^REPLYTO zone:net/node firstname lastname
which is used to signify the "userid" which mail destined to this other network
must be sent to and on which machine that userids resides. Replies are sent
to this zone:net/node and userid with the first line of the message being
changed into 'TO: ....' where .... is the FULL userid from the ^AREPLYADDR
line.
Should you have constructive correction or criticism, please contact:
Michael Shiels
FidoNet: 1:250/410 michael.shiels@masnet.fidonet.org
uucp: ?!tmsoft!masnet!michael.shiels
Internet: michael.shiels@masnet.uucp
----------
FidoNet is a trademark of Tom Jennings and Fido Software, to whom we all owe
much thanks for the origin and spirit of FidoNet.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

363
html/ftsc/fsc-0039.html
View File

@ -1,363 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Type-2 Packet Extension Proposal.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0039
Version: 04
Date: 29-Sep-90
A Type-2 Packet Extension Proposal
Mark A. Howard 1:260/340@FidoNet
Status of this document:
------------------------
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements. Distribution
of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido Software.
FTS-0001 is a copyrighted work of Randy Bush.
Introduction
------------
This document serves two major purposes. The first is an attempt to define
and document the Type-2 packet which is widely in use in FidoNet today.
Although FTS-0001 defines the structure of a Type-2 packet, the natural
evolution of our network, mostly with regards to addressing methodology,
has made it necessary to utilize hitherto unused portions of the header
to insert Zone and Point information. Also, it has become apparent that
some of the existing fields are not large enough to accomplish their
original tasks.
The second is to propose a simple mechanism to allow FidoNet to begin to
utilize advanced mail packing techniques. It is quite apparent that while
Type-2 has served us faithfully for some time now, the evolution of our
network in terms of technical and physical complexity has caused us to
consider more efficient and functional ways to pack mail.
It should be made clear that with the exception of the Capability Word,
Capability Word Validation Copy, ProductCode(hi), and Revision(minor),
which are proposed extensions to the Type-2 packet header, this FSC is
an attempt to correctly document existing practices with regards to the
insertion of zone and point info by at least three mail processors in
use today.
The Type-2 Header (Where's the Zone?)
-------------------------------------
Although FTS-0001 has recently been updated to reflect the use of some of
the areas in the packed message header for zone data, at least two other
methods for inserting the zone information have been adopted, making it
necessary to provide support for both formats in all of the zone aware mail
processors. The end result is more code, and redundant information in the
packet header.
This has presented a problem in logistics, as it is difficult to consider
the project of updating mail processors using one type to use the other.
As sufficient indentification is provided, in the form of the product code,
to determine the expected location of the zone information, and because
code already exists in most of the mail processors to overcome this, this
proposal does not attempt to suggest that one method be used over the
other, rather the intent is to attempt to document the extensions in use,
and the products involved.
See the accompanying chart and cross-reference.
The Product Code
----------------
Based upon the current rate of requests for product codes from the FTSC,
it is probable that the Product Code byte will not be large enough to
accomodate all of the codes required. While it is not reasonable to
expect that all Type-2 processors will eventually check the hi-order byte
proposed here, it is likely that 'current' mail processors will. This
can be nothing but benefical, as it will force users to upgrade their
mail processors to a product which will as a minimum, support Type-2
with Zone and Point extensions, and quite possibly, processors that will
utilize more advanced mail packing techniques, making Type-2 extinct once
and for all.
The Capability Word (How do we GET there from here?)
-----------------------------------------------------
Everybody would like to see more efficient and functional ways to pack and
exchange mail. Several Type-3 message bundle proposals exist, but none
really address a problem which must be solved first. The problem is that
since FidoNet is a hobbyist network, no demands can be placed on any one
sysop to upgrade or change their bundling software. Because of this, it
is necessary to consider strategies which allow for the existence of Type-2
bundlers in the network topology.
Considerable advantages can be realized, however, between systems that
consent to use advanced bundling techniques. One way to do this is to
simply send netmail to all of your connecting systems, saying "Hey, I've
got a Type-3 bundler now, how about you?" This could become quite
tiresome, and does not represent much of an improvement on the current
situation.
What would be desirable is a network that would 'upgrade itself'. Given a
situation where mail processors of various capabilities will exist in a
network topology, the goal is to provide a mechanism whereby two links can
determine and utilize the most efficient bundling method to use, in a
manner transparent to the sysop.
For instance, let's say that the FTSC releases the Type-7 All New Singing
and Dancing bundle format. Well, your current version of SlingToss can
only support Types 2, 3, and 5. One of your downlinks gets a new version
of MailMangle which can support Types 2, 3, 4, and 7. Well, it is quite
obvious that since you and he are exchanging 4 megs of mail each night,
and it's an overseas call, that it would be in your interest to obtain a
new version of SlingToss which can support Type 7.
Note that this is *optional*. Because both processors can support Type-3,
they will continue to exchange Type-3 mail quite happily, even though
MailMangle is happily advertising the availability of Type-7. Even your
downlinks which are still using stone-age Type-2 processors will be fine,
as SlingToss will always export Type-2 bundles when no higher capability
can be determined.
So, after dashing off the check to the author, your new version of
SlingToss comes in the mail! You rush over to your system, and install it.
The next time SlingToss exports mail to the MailMangle system, it says
"Hey! I can now support Type 2, 3, 5, and 7! So, whattya got?" This is
no skin off MailMangle's nose, he's had Type-7 for quite a while, and he
begins to export Type-7 bundles to SlingToss. "It's about time.", he says.
Now, this scenario is made possible by implementing a 'Capability Word' in
the present and future packet headers. The Capability Update mechanism
depends on several assumptions:
1) Any Advanced Capability Bundler *MUST* be capable of receiving and
faithfully processing Type-2 bundles. Hopefully, the inbound packets
will be in the new format proposed by this document, but then again,
this is not an exact science. What this means is that it is likely
that some packets may arrive with the Capability Word (CW) set to 0.
In this case, Type-2 is assumed, assuring compatibility. The only
caveat is that it is conceivable that some obscure mail processor
uses the location proposed for the CW for other arcane purposes. This
| can detected through the CWValidation Copy, which is byte-swapped and
| compared with the CW at that time. If a mismatch is found, a CW of
| type 0 is assumed, and a Type-2 bundling method is used.
2) An Advanced Capability Bundler, hereafter referred to as a Type-N
Bundler, must have a method to store and maintain the node-by-node
capability information. This can be done many ways, and in fact
several processors already have begun to maintain node information
outside of that found in AREAS.BBS, mostly to implement pre-arranged
alternate compression methods. In a text configuration file, you
might see the following:
; Address Comp Send LastCW ; Comments
Node 1:260/340 ZIP Auto 7 ; Auto detect & upgrade
Node 1:135/20 LZH 3 2,3,7 ; Always send Type-3
Node 1: ARC 2 0 ; Stone-Age processor
Node 1:135/4 --- Auto 7 ; Sent me netmail
Node 1: --- 0 0 ; Don't send CW
In this example, the fields are:
Address - downlink address. Note that this is not necessarily
relative to echomail, only, it is possible to append
information to the node database as netmail packets are
receieved from different addresses.
Comp - desired mail compression method.
Send - Auto - automatically determined maximum common packing
method to use. Automatically update to LastCW
when packing.
LastCW - Last CW received from remote system.
3) A Type-N Bundle will always advertise it's capabilities in the CW
regardless of the type being sent. As shown in the above example,
it allows Type-N processors to automatically track the capability
of your system. Again, in cases where a stone-age processor is
being used, this field will be ignored, and in the unusual event
that it is not ignored, and is somehow harmful to the far system,
the Type-N processor can be configured to send a CW of 0.
The format of the Capability Word is designed to support up to 15 future
bundle types, and is bit-mapped to facilitate the easy determination of
the maximum common level supported between two nodes:
msb Capability Word lsb
Node Supports ------------FTSC Type Supported----------------
U 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2
2, 3, and 7 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1
2, 3, and 5 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1
2 (this FSC) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
Stone Age** 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
^
+--- Indicates UseNet RFC-822 capability
** - a mismatch in the CWValidation Copy also
produces a CW=0.
In this example, the Type-N bundler would first compare the remote CW
| and the byte-swapped remote CWValidation Copy, and check for a mismatch.
Prior to the compare, the MSB of the CW's are masked, as this bit is
reserved to indicate whether the mail processor is capable of also
accepting UseNet RFC-822 bundles. Following the MSB mask, and bit
comparison, if they do not match, a remote CW of 0 is assumed. If they
match, the Type-N processor would AND the local and remote CW words,
obtaining a CW expressing the Types which are in common to both systems.
The most significant Type will be used, by default, but note that this
assumes that new bundling Types will be increasingly more efficient or
in some way more beneficial.
Because this may not always be the case, there should be a method provided,
as illustrated above, to override the automatic upgrade should this become
the case.
The MSB of the CW is used to indicate whether the mail processor can accept
UseNet RFC-822 bundles or not. It is a separate indicator, and not intended
to be used as a part of the above comparison, however can be used to also
advertise RFC-822 capability to other systems. Since RFC-822 is 'set in
stone', there is no need to assign more than one capability bit.
It might seem somewhat limiting to only consider the possibility of 15
different future bundling methods, but it is my opinion that the careful
use of a 'Sub-Type' byte in the packet header can allow for the variations
on a single theme, and that proposals for new formats should be evaluated
by the FTSC to determine whether sufficient benefit can be realized in
the implementation of the given format, prior to assigning a new type
code.
Mailers
-------
It is quite clear to me that should this concept take hold, that the
logical place to store node capability data is in the local nodelist
database, or an index-associated data file. As above, it is necessary
to generate Type-2 packets for whatever purpose, unless it is known
by prior association, that the far mailer can accept other types of
packets. It is also quite reasonable to assume that a nodelist flag
could be assigned to advertise the CW for a given node, which the
native mailer nodelist compiler could then immediately determine the
preferred bundling method for any given node in FidoNet.
Another possibility would be to pass a capability advertisement in the
extensible portion of a handshake protocol, which may or may not already
exist in FidoNet.
The approach suggested previously in this document suggests the use of
a text configuration file, but it is quite obvious that many benefits
can be realized through the use of the nodelist, including the use of
additional flags to indicate the preferred compression method, etc.
Summary
-------
This document has been created in an attempt to define a method to allow
the future expansion and enhancement of FidoNet technology mail processors
and mailers, and in a way that is the least disruptive to existing mail
operations. The intent is to provide for an environment that is as open,
and extensible as possible.
The mechanism described should allow many different types of processors
(FTSC-registered) to exist in the network at once, and to provide an
environment which is designed to operate at it's maximum efficiency
wherever possible or practical.
Revision 2 of this document was produced to implement suggestions made
primarily by Jan Vroonhof, who suggested the use of the CW Validation
Copy. Jan presented this idea in his FSC-0048, along with other concepts
relating to the correct indentification and handling of zone and point
addressing. This document sanctions the improvements to the CW as
recommended, but does not address or support the other extensions
recommended in FSC-0048.
Thanks
------
To Ward Christensen, creator of XModem and BYE.
Tom Jennings, who started this whole mess.
Joaquim Homrighausen, for lots of good ideas, and motivation. Here's
another Lamborghini to work on.
Wynn Wagner, Oliver McDonald, Roeland Meyer, Andrew Farmer, Claude
Warren, Jan Vroonhof, Bob Hartman, and Vince Perriello, who all
contributed in some way to the creation of this document, mostly
through their messages in NET_DEV.
Type-2 Packet Format (proposed, but currently in use)
-----------------------------------------------------
Field Ofs Siz Type Description Expected value(s)
------- --- --- ---- -------------------------- -----------------
OrgNode 0x0 2 Word Origination node address 0-65535
DstNode 2 2 Word Destination node address 1-65535
Year 4 2 Int Year packet generated 19??-2???
Month 6 2 Int Month " " 0-11 (0=Jan)
Day 8 2 Int Day " " 1-31
Hour A 2 Int Hour " " 0-23
Min C 2 Int Minute " " 0-59
Sec E 2 Int Second " " 0-59
Baud 10 2 Int Baud Rate (not in use) ????
PktVer 12 2 Int Packet Version Always 2
OrgNet 14 2 Word Origination net address 1-65535
DstNet 16 2 Word Destination net address 1-65535
PrdCodL 18 1 Byte FTSC Product Code (lo) 1-255
* PVMajor 19 1 Byte FTSC Product Rev (major) 1-255
Password 1A 8 Char Packet password A-Z,0-9
* QOrgZone 22 2 Int Orig Zone (ZMailQ,QMail) 1-65535
* QDstZone 24 2 Int Dest Zone (ZMailQ,QMail) 1-65535
Filler 26 2 Byte Spare Change ?
| * CapValid 28 2 Word CW Byte-Swapped Valid Copy BitField
* PrdCodH 2A 1 Byte FTSC Product Code (hi) 1-255
* PVMinor 2B 1 Byte FTSC Product Rev (minor) 1-255
* CapWord 2C 2 Word Capability Word BitField
* OrigZone 2E 2 Int Origination Zone 1-65535
* DestZone 30 2 Int Destination Zone 1-65535
* OrigPoint 32 2 Int Origination Point 1-65535
* DestPoint 34 2 Int Destination Point 1-65535
* ProdData 36 4 Long Product-specific data Whatever
PktTerm 3A 2 Word Packet terminator 0000
* - extensions to FTS-0001
Ofs, Siz are in hex, other values are decimal.
Zone/Point Aware Mail Processors (probably a partial list)
----------------------------------------------------------
Prod
Code Name - Uses QOrg/QDstZone Orig/DestZone Orig/DestPoint
---- ----------- ------------- ------------- --------------
0x0C FrontDoor Reads/Updates Yes Yes
0x1A DBridge ????? Yes Yes
0x45 XRS Reads/Updates Yes Yes
0x29 QMail Yes ????? Not point-aware
0x35 ZMailQ Yes ????? Not point-aware
0x3F TosScan Reads/Updates Yes Yes
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

228
html/ftsc/fsc-0046.html
View File

@ -1,228 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Product Identiefier for FidoNet Message Handlers.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0046
Version: 005
Date: 30-Aug-94
A Product Idenfifier for FidoNet Message Handlers
Joaquim Homrighausen
2:270/17@fidonet or joho@abs.lu
August 30, 1994
Copyright 1994 Joaquim Homrighausen; All rights reserved.
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Purpose
This document should serve as a guide for the product identfier, PID
hereafter, format for FidoNet message handlers. The purpose behind PIDs
is related to my attempt to remove the requirement of Origin lines in
conference mail messages.
While I fully understand that this won't happen in all conferences, I
would like to provide the facility to those who can use it (i.e. for
conferences where all the participants are using software that supports
messages without origin lines).
Another use for PIDs is to minimize the excessive amount of information
some programs put on the tear lines which increases overall
transportation cost and time of conference mail.
PID
A PID replaces the program identifier often seen on the tear line of
conference mail messages and is hidden behind a ^A (ASCII SOH, 01h).
This also allows for better tracking of software causing problems in
conferences.
: Only one PID per message is allowed and should only be added by the
: program that creates the message. I.e. programs passing the message on
: to someone else may not add additional PIDs. If a PID is added, no
: program information may be present after the tear line.
A PID also offers the ability to add serial numbers to identify a
specific copy of a program as being the source of a message with little
or no effort.
Format
^APID: <pID> <version>[ <serial#>]<CR>
Sample
^APID: FM 2.11.b<CR>
Would identify FrontDoor's editor, beta version 2.11 and replace:
--- FM 2.11 (beta)
Fields
pID The ID of the product responsible for creating the message.
This should be kept as short as possible. The maximum
length for this field is 10 characters.
version The version of the product including any alpha, beta, or
gamma status. Only the relevant part of the version should
be included. I.e. 1.00 should be expressed as 1, 1.10 as
1.1 and 1.01 as 1.01. Alpha, beta, or gamma status should
be expressed by appending a / or . followed by a, b, or g
and optionally a revision indicator, such as a1, b2, etc.
The maximum length for this field is 10 characters.
serial# The serial number of the product, omitted if irrelevant
or zero. The maximum length for this field is ten (10)
characters.
TID
TIDs or "Tosser IDs" started to appear shortly after the first
revision of this document was released. They are added by Conference
Mail ("EchoMail") processors when a message is exported from the
local message base and injected into the network distribution scope
for a conference.
When a Conference Mail processor adds a TID to a message, it may not
add a PID. An existing TID should, however, be replaced. TIDs follow
the same format used for PIDs, as explained above.
List of products
The accompanying file, PIDLIST.TXT, is a list of products known to
support the PID proposal. Software authors are encouraged to inform
the author of this document of changes and additions to this list.
--- end of file "fsc-0046.005" ---
</PRE>
<HR>
<PRE>
Document: PIDLIST.TXT (FSC-0046)
Date: 30-Aug-94
A list of used product idenfifiers
Joaquim Homrighausen
2:270/17@fidonet or joho@abs.lu
Product identifiers
Product Version ID Author
-----------------------------------------------------------------------------
!!MessageBase 1.6+ !!MB Holger Lembke 2:240/500.20
Alert 2.1+ Alert Richard Kail 2:310/25.2
ANet 921213+ ANet Thomas Ekstroem 2:201/411
ArcMail RISC OS 1.04+ AM Philip Blundell 2:440/34.4
Artmail Mailer System 1.00+ ART Klaus Landefeld 2:247/402
Auto Message Taker 1.00+ AMT Patrik Torstensson n/a
AVALON 3.10+ AVALON Stephan Slabihoud 2:2401/103.6
CrossPoint 2.10+ XP Peter Mandrella 2:243/97.80
EchoSprint 1.02+ ES Ben Elliston 3:620/262
Enhanced Mail MAnager .01+ EMMA Johan Zwiekhorst 2:292/118
Enhanced Message EDitor .02+ EMED Johan Zwiekhorst 2:292/118
EZMail .67+ EZMail Torben Paving 2:234/41
F_POINT 1.1+ F_POINT Florian Rupp 2:248/107.2
FastEcho 1.21a+ FastEcho Tobias Burchhardt 2:245/39
FileScan 1.5+ FileScan Matthias Duesterhoeft 2:241/4513
Freqit (Windows) 1.0+ FIW Marvin Hart 1:106/462
Freqit (MS-DOS) 1.0+ FID Marvin Hart 1:106/462
FrontDoor APX 1.00+ FDAPX Joaquim Homrighausen 2:270/17
FrontDoor (Editor) 2.00+ FM Joaquim Homrighausen 2:270/17
FrontDoor (Mailer) 2.00+ FD Joaquim Homrighausen 2:270/17
FrontEnd FX 1.00+ FEFX Eric Theriault 1:132/220
GEcho 1.00+ GE Gerard van der Land 2:2802/110
GeeMail 2.00+ GeeMail Lech Szychowski 2:480/4.7
HbToSca 1.00+ HTS Jani Laatikainen 2:220/150
HyperBBS 2.00+ HyperBBS Jani Laatikainen 2:220/150
JetMail 1.00+ JetMail Daniel Roesen 2:243/93.8
LazyBBS .5+ LazyBBS Franck Arnaud 2:320/100
Mail FX 1.00+ MFX Eric Theriault 1:132/220
MsgTrack 3.20+ MT Andrew Farmer 1:243/1
NewsFlash 1.01+ NwF Chris Lueders 2:2402/330
NodeDiff Processor 3.00+ NDP Serge Vikulov 2:5080/5
Notify 2.1 Notify Frank Schuhardt 2:247/160
OFFFax 3.03 OFFFax Frank Schuhardt 2:247/160
Pobble 0.15+ Pobble Josh Parsons 3:771/340
QBBed 2.64+ qbbed Werner Berghofer 2:310/90.100
RemoteAccess 1.10+ RA Andrew Milner 2:270/18
RASS 1.00+ RASS Yossi Gottlieb 2:403/139.75
SendFile 1.00+ SendFile Mike Shoyher 2:5020/17.3
Synchronet 1.00+ SYNC Rob Swindell 1:103/705
TB-Edit 1.10+ TB-Edit Arjen Lentz 2:283/512
TB-Mailer 1.97+ TB-Mailer Arjen Lentz 2:283/512
TB-Point .10+ TB-Point Arjen Lentz 2:283/512
TechBBS 1.00 TECHBBS Marcel Tegelaar 2:281/409
TechMail 1.00 TECHMAIL Raymond van der Holst 2:281/409.2
TosScan 1.10+ TosScan Joaquim Homrighausen 2:270/17
TPCS .89b TPCS Krister Hansson-Renaud 2:201/201.7
Mikael Kjellstrom 2:201/201.10
XRobot 3.00+ XRobot Joaquim Homrighausen 2:270/17
Xrs Alternative Packer 1.04+ XAP Jeroen Smulders 2:512/1.8
ZeroToss 1.00 ZeroToss Jeff Masud 1:103/115
-----------------------------------------------------------------------------
Product identifier registration
Simply fill in the required information and send this form to the author of
this document via private netmail.
Product: _________________________________________
Version: __________
PID info: _________________________________________
Author: _________________________________________
Address: ___________________________ (eMail address)
--- end of file "pidlist.txt" ---
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

418
html/ftsc/fsc-0048.html
View File

@ -1,418 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Proposed Type-2 Packet Extension.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0048
Version: 002
Date: 21-Oct-90
A Proposed Type-2 Packet Extension
Jan Vroonhof
2:281/1.12@fidonet
Oct 21, 1990
Status of this document
=======================
This FSC suggests a proposed protocol for the FidoNet(r)
community, and requests discussion and suggestions for
improvements. Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Purpose
=======
The final goal of this document is to become a widely used
standardised extension to FTS-0001, like FTS-0006, 0007 and
0008 are, and provide an elegant way to switch to a new
bundling method without requiring major effort or breaking
anything.
Prologue
========
The main thing that needs stressing is that the additions
covered by this document are FULLY (I repeat FULLY) BACKWARDS
COMPATIBLE with FTS-0001 (and other existing standards and
practices in FidoNet and WhatEverOtherNets that I know of).
When I say "backwards compatible" I mean that problems it would
create already exist in the current FTS-0001 system (e.g.
zone conflicts when dealing with a non compliant system). In
short it only corrects some flaws in FTS-0001 WITHOUT
generating new ones.
In this document I have tried to stay as much as possible on
the paths of existing practices. Therefore I think
implementation of the additions it proposes will not be too
hard.
! Prologue to revision 2
! ======================
! Revision 2 of this document reserves a bit in the
! CapabilityWord for one bundle type already in use outside of
! FidoNet, RFC-822. A small change was made to the "receiving"
! flowchart in order to ensure compatibility with FSC-0039.004.
! In the process a lot of errors and omissions in the spelling,
! credits etc. were corrected.
===============
! All references in the following to FSC-0039 are to Revision 1
! of that document.
My thoughts on FSC-0039 and FTS-0001 rev 12
===========================================
First, revision 12 of FTS-0001 introduced the term "(some
impls)" to indicate that some implementations used their own
! extensions to FTS-0001 (Note that in later revisions this was
! changed to "optional"). The problem is that this info cannot be
relied upon, because there is no way to actually validate the
data. One can only check whether the values of these fields are
in the range of valid values and hope for the best.
Second, FSC-0039 introduced the idea of having a bitfield
(called the Capability Word) indicating whether extension data
was valid. Through the Capability Word, it also made it
possible to indicate the ability to support other, non type 2,
packets, thus allowing for flexible migration towards type 3.
It also documented the addressing extensions used by various
programs.
However, FSC-0039 has two flaws:
1. One cannot be sure the bitfield is zero because other
implementations might use this field for their own purposes.
Therefore this document includes a second validation copy
for the Capability Word (CW hereafter). This copy allows the
FSC-xxxx compliant software to validate the CW by comparing
the two. The chance of some junk portraying itself as a CW
is significantly reduced by this.
! Please note that the validation copy is byte swapped
! compared to the normal capability word. While this started
! out as a typo, I decided to leave it in as it introduces
! some extra safety, without requiring much extra code effort.
! In later revisions of FSC-0039, Mark adopted this idea of a
! validation copy too and eliminated the problem.
2. Although FSC-0039 provides a way to make packet headers 4D
it is not backwards compatible. It cannot be used in FTS-
0001 sessions to unknown systems, making FidoNet still not
totally 4D capable. Although it implements fields for zone
and point number, an FTS-0001 compliant application is not
required to look at these fields. When a point mails using
these fields to implement its 4D address, a system only
looking at the net/node info, as is required by FTS-0001,
still sees it as a boss node, causing the obvious problems.
This document provides a way for transparent point handling,
using a technique already exploited by many mailers
internally. It will allow this document to be implemented
and used by mailers not supporting it. At the same time the
danger that a point is seen as the boss node is eliminated.
It does NOT provide full inter-zone backwards compatibility,
but that is not needed as badly, as problems are not yet too
great. Any measures to ensure backwards compatibility in
this area might harm communication with non-supporting
programs, when the old system could handle the situation.
Packet Header
=============
The "|" character is used to indicate extensions documented in
FTS-0001 revision 12, the ":" character indicates those
documented here and in FSC-0039.
Offset
dec hex
.-----------------------------------------------------.
0 0 | origNode (low order) | origNode (high order) |
+--------------------------+--------------------------+
2 2 | destNode (low order) | destNode (high order) |
+--------------------------+--------------------------+
4 4 | year (low order) | year (high order) |
+--------------------------+--------------------------+
6 6 | month (low order) | month (high order) |
+--------------------------+--------------------------+
8 8 | day (low order) | day (high order) |
+--------------------------+--------------------------+
10 A | hour (low order) | hour (high order) |
+--------------------------+--------------------------+
12 C | minute (low order) | minute (high order) |
+--------------------------+--------------------------+
14 E | second (low order) | second (high order) |
+--------------------------+--------------------------+
16 10 | baud (low order) | baud (high order) |
+--------------------------+--------------------------+
18 12 | 0 | 2 | 0 | 0 |
+--------------------------+--------------------------+
20 14 | origNet (low order) | origNet (high order) |
: | Set to -1 if from point |
+--------------------------+--------------------------+
22 16 | destNet (low order) | destNet (high order) |
+--------------------------+--------------------------+
| 24 18 | ProductCode (low order) | Revision (major) |
| +--------------------------+--------------------------+
| 26 1A | password |
| | 8 bytes, null padded |
| +--------------------------+--------------------------+
|: 34 22 | origZone (low order) | origZone (high order) | }
| +--------------------------+--------------------------+ } As in
|: 36 24 | destZone (low order) | destZone (high order) | } QMail
: +--------------------------+--------------------------+
: 38 26 | AuxNet (low order) | AuxNet (high order) |
: +--------------------------+--------------------------+
: 40 28 | CWvalidationCopy (high) | CWvalidationCopy (low) |
: +--------------------------+--------------------------+
: 42 2A | ProductCode (high order) | Revision (minor) |
: +--------------------------+--------------------------+
: 44 2C | CapabilWord (low order) | CapabilWord (high order) |
: +--------------------------+--------------------------+
: 46 2E | origZone (low order) | origZone (high order) | }
: +--------------------------+--------------------------+ } As in
: 48 30 | destZone (low order) | destZone (high order) | } FD etc
: +--------------------------+--------------------------+
: 50 32 | origPoint (low order) | origPoint (high order) | }
: +--------------------------+--------------------------+ } As in
: 52 34 | destPoint (low order) | destPoint (high order) | } FD etc
: +--------------------------+--------------------------+
: 54 46 | Product Specific Data |
: + +
: | 4 Bytes |
+--------------------------+--------------------------+
58 3A | zero or more |
~ packed ~
| messages |
+--------------------------+--------------------------+
| 0 | 0 | 0 | 0 |
'-----------------------------------------------------'
Packet = PacketHeader { PakdMessage } 00H 00H
PacketHeader = origNode (* of packet, not of messages in packet *)
destNode (* of packet, not of messages in packet *)
year (* of packet creation, e.g. 1986 *)
month (* of packet creation, 0-11 for Jan-Dec *)
day (* of packet creation, 1-31 *)
hour (* of packet creation, 0-23 *)
minute (* of packet creation, 0-59 *)
second (* of packet creation, 0-59 *)
baud (* max baud rate of orig and dest *)
PacketType (* old type-1 packets now obsolete *)
origNet (* of packet, not of messages in packet
set to -1 if orig=point *)
destNet (* of packet, not of messages in packet *)
+ productCode Lo (* 0 for Fido, write to FTSC for others *)
|+ serialNo Maj (* binary serial number (otherwise null) *)
| password (* session pasword (otherwise null) *)
| origZone (* zone of pkt sender (otherwise null) *)
| destZone (* zone of pkt receiver (otherwise null) *)
| auxNet (* contains Orignet if Origin is a point *)
+! Bytesw. CWvalidationCopy (* Must be equal to CW to be valid *)
+ ProductCode Hi
+ revision Minor
+ origZone (* zone of pkt sender (otherwise null) *)
+ destZone (* zone of pkt receiver (otherwise null) *)
+ ProdData (* Product specific filler *)
When the two copies of the CW match they can be asumed to be
valid and used.
Stone-Aged: Old FTS-0001
Type-2+ : Old FTS-0001 plus changes indicated by "|" and ":"
are valid
A Type-N Bundle will always advertise its capabilities in the
CW regardless of the type being sent. As shown in the example
below, the CW allows Type-N processors to automatically track
the capability of your system. Again, in cases where a stone-
age processor is being used, this field will be ignored, and in
the unusual event that it is not ignored, and is somehow
harmful to the far system, the Type-N processor can be
configured to send a CW of 0.
The format of the Capability Word is designed to support up to
15 future bundle types, and is bit-mapped to facilitate the
easy determination of the maximum common level supported
between two nodes:
msb Capability Word lsb
Node Supports ------------FTSC Type Supported **)------------
U 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2+
2+,3, and 7 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1
2+,3, and 5 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1
2+ (this Doc) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
Stone Age 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
! ^-- "U" Indicates nodes able to process RFC-822
! bundles.
** - In the example bit definitions only type 2,
and the Stone-Age type, are defined now.
The rest are to be concidered "reserved by
FTSC".
The receiving Type-N bundler would AND the two words, obtaining
a word expressing the Types which are common to both the
receiving and the sending system. The most significant Type
will be used for future sessions, by default. Please note that
this assumes that new bundling Types will be increasingly more
efficient or in some way more beneficial. Because this may not
always be the case, there should be a method provided to
override the automatic upgrade, as illustrated above, should
this ever happen.
! N.B. The one bit left over (Msb) is now used as indicator for
! RFC-822 type bundles. For info on RFC-822 please check out
! the relevant documents themselves.
! For a more explanatory text on using the CW to its full
! potential, refer to the FSC-0039 text by Mark Howard.
! Mark also gives some more rationale for the origional idea
! of the CW.
Generating Type-2+ bundles
==========================
Do we have a CW Does CW indicate
stored for dest? YES ----&gt; higher packets YES ---&gt; Generate higher
NO we support? packet
| NO
\|/ |
+-----&lt;----------------------+
|
Fill header with all info
|
\|/
|
Are we sending from a point? (origPoint != 0) YES --+
| |
NO |
| \|/
| set AuxNet = OrigNet
\|/ set OrigNet = -1
| |
+-----&lt;----------------------------------------+
|
Add Messages
|
Terminate packet
|
Send packet
Receiving Type-2+ bundles
=========================
Receive Packet
|
Packettype = 2 NO -------------&gt; Process Type-Other
YES
|
|
CWcopies match NO --------+------&gt; Treat as normal Stone-Age packet
YES | |
| | |
Store CW /|\ |
| | /|\
CW is 0 YES --------------+ |
NO |
| |
| |
CW indicates support for 2+ NO --+
YES
|
|
! OrigPoint is not 0 and OrigNet = -1 YES -------+
NO |
| \|/
! \|/ Set OrigNet is AuxNet
| |
+------&lt;-----------------------------------+
|
Process using added info
Credits
=======
To Mark Howard, for introducing the idea of a CW in his FSC-
0039 document and quite rightly pointing out one big omision
in revision 1 of this document.
To Rick Moore, for doing a good job in processing all these
revisions by Mark and myself, and for his work for the FTSC in
general.
To Joaquim Homrighausen, for his contributions to FidoNet
software in general, and especially for his time devoted to
reading, discussing and implementing the ideas Mark and I
introduced.
To Andre van de Wijdeven, for producing and letting me beta
test his TS-MM software, which in my opinion is the best point
software around. (I'm not saying available, because it isn't
:-()
To john lots, for shipping this stuff to the US.
To Jon Webb, for doing a much needed grammar and spelling
check.
To Bob Hartman, Vince Periello, Tom Jennings, Eelco de Graaff,
aXel Horst, Arjen van Loon, jim nutt, Odinn Sorensen, David
Nugent, Peter Janssens and many others, for making FidoNet
what it is now, for me and for everybody.
Epilog
======
So this it, now it's up to you to decide whether or not to
implement it. A small change was made in the receivers
flowchart and a small incompatibility with the later revisions
of FSC-0039 was removed. That will ensure that FSC-0048 and
FSC-0039 mailers can happily talk to each other....
The best way to implement this would be to always support FSC-
0048 on inbound trafic and generate FSC-0048 on outbound by
default. A switch on a per-node basis will force your software
to be FSC-0039 or even FSC-0001 only, and you will cover all
bases.
This can be done easily, as FSC-0048 is a superset of FSC-0039
(The -1 thing on points being the difference) which in turn is
a superset of FTS-0001 (CW). I'd be glad to get some feedback.
You can put it in NET_DEV or netmail me.
Jan Vroonhof (2:281/1.12@fidonet)
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

104
html/ftsc/fsc-0049.html
View File

@ -1,104 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Proposal for Passing Domain Information During an FST-0006 Session.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0049
Version: 001
Date: 03-Jul-90
A Proposal for
Passing Domain Information
During an FTS-0006 Session
by
Bob Hartman
1:104/501@fidonet.org
July 3, 1990
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
FSC-0045 proposes a method for sending five dimensional FidoNet addresses
(ie, zone:net/node.point@domain) via the type 2 packet header. This
document describes a proposed method for sending the same five dimensional
address in the Hello packet of an FTS-0006 session, with the additional
advantage of being able to utilize the full Internet recognized domain name
for various Fidonet technology networks. This proposal, combined with
FSC-0045 will help to solve one of FidoNet's most pressing problems: How to
recognize alternative networks without the need of some centralized
management looking at all of them and what they are doing with Zone numbers,
etc. Like FSC-0045, this proposal remains backwards compatible with what it
is replacing.
Currently FTS-0006 has provisions for zone, net, node, and point information
to be passed in the Hello packet. To extend this to allow the domain name
to be passed, an extra capability bit is used. This bit corresponds to the
0x4000 bit, and will be called the DO_DOMAIN bit. If this bit is set, it
means that the sender is domain aware, and has enclosed his domain in the
Hello packet. The domain is stored in the system name field, after the null
that terminates the real system name. The system name field is a maximum of
60 characters, so the sender must make the real system name, a null, the
domain name, and another null byte fit within the 60 bytes. The domain will
start at the byte immediately after the first null byte. The domain is
arbitrary length and should correspond to the Internet assigned domain name.
This is NOT the same as the FSC-0045 domain, and therefore there needs to be
a mapping between real Internet domains, and the FSC-0045 style domain name,
if FSC-0045 is accepted by the FTSC as a standard for use by all mailers.
This mapping is normally straightforward (for example, Internet fidonet.org
would correspond to FSC-0045 domain FidoNet). Since most alternative nets
do not have a registered Internet domain, the naming convention should be
"known by" domain (ie, FSC-0045 domain name) followed by .ftn (for FidoNet
Technology Network). So, the FSC-0045 domain "Alternet" would be converted
to alternet.ftn under this proposal. This allows domains which are not
normally FidoNet aware to use FTS-0006 to talk to FidoNet technology mail
programs. For example, a mailer located at Camex in Manchester, NH might
send it's mail as 'man.camex.com' during an FTS-0006 session. When parsing
the domain name, the parsing should try to match the domain from right to
left (Internet naming is hierarchical from right to left), so that if a
mailer knew about man.camex.com, that could also match something of the form
super.machine.silly.name.man.camex.com. The domain name should be case
INSENSITIVE, and the FSC-0045 abbreviation of it should be unique within the
first 8 characters, and also should not include any periods ('.') or at-signs
('@') since those characters are significant in the Internet domain naming
scheme.
In order for this proposal to be adopted, the FTSC would have to assign the
DO_DOMAIN bit, and have it documented in FTS-0006. This method is fully
backwards compatible, since a domain aware mailer could send the domain
information, and if the other end was not domain aware, it would ignore it.
If the other end was domain aware, it would be able to extract the domain
information easily and would then have a full five dimensional address
available for the sender. This proposal remains fully backward compatible
with the current uses of all FTS-0006 fields, and should not affect operation
of any mailer that has used reserved bytes in the Hello packet.
</PRE>
<A HREF="./"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

99
html/ftsc/fsc-0050.html
View File

@ -1,99 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Character Set Identifier For FidoNet Message Editors.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0050
Version: 001
Date: 14-Jul-90
A Character Set Identifier For FidoNet Message Editors
Draft I
Thomas Sundblom
2:201/114@fidonet
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Purpose
This document should serve as a guide for the character set
identifier, CHARSET hereafter, format for FidoNet message Editors.
The purpose behind CHARSET is related to my attempt to make it
easier for each reader of a FidoNet message to identify the
characters used in the messages.
Since FidoNet messages aren't restricted to use any special character
sets in the messages, there will be differences between computer
kinds and special country dependent characters. To avoid confusion
in such cases, I'm hereby introducing the CHARSET kludge.
There is no need that each FidoNet Message reader should be able
to understand every possible character set. If the reader can't
handle the special character set found in a message, then it should
use a default character set (as most readers do today).
Format
^aCHARSET: &lt;Character set identifier&gt;
Sample
^aCHARSET: ISO-11
Would identify that the message is written using the ISO-11
character set, which relates to the character set mainly used
in Sweden.
Supported character sets
No special character set is specified, but it is recomended to
use the ISO numbering of the different character sets. Where no
ISO number is available, an easy to understand code should by used.
Character set identifier examples
ISO-6 Relates to plain ASCII 7 bit character set.
ISO-11 Swedish character set, 7 bit.
ISO-21 Germany character set, 7 bit.
ISO-69 French character set, 7 bit.
Other character set identifiers could be
PC-8 IBM PC complete character set.
ATARI ATARI ST complete character set
AMIGA AMIGA complete character set
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

188
html/ftsc/fsc-0053.html
View File

@ -1,188 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Specifications for the ^aFLAGS field.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0053
Version: 002
Date: 08-Dec-92
Specifications for the ^aFLAGS field
Joaquim H. Homrighausen
2:270/17@fidonet or joho@ae.lu
December 8, 1992
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Purpose
To explain and document the existing usage of the ^aFLAGS field used
by many software packages, including FrontDoor, TosScan, and
D'Bridge. And to inform software authors of its proper usage.
Prologue
One of the problems with the FTS-1 (stored) message format is its
limitations in regards to message attributes. Several bits are used
(reserved) by SEAdog, another by several packers and editors - even
though most mailer authors don't support them, they remain. One
reason would be backward compatibility with older software.
Unfortunately, this presents a problem for software authors that
would like to pass extended message attributes for use and handling
by other software.
Some software packages have been using an alternate method called
"FLAGS" which is 7-bit ASCII placed behind <SOH>FLAGS somewhere near
the beginning of a message. The various flags will now be described.
Flags
The FLAGS string should be placed somewhere near the beginning of
the message text, and is preceeded by a &lt;SOH&gt; (^a) character. There
is no need to support all or any of the below mentioned flags.
If flags are stripped when a message passes through a system, all
relevant and correct FTS-1 status bits should be updated to indicate
the original contents of the FLAGS field.
Flag Brief Long description
--------------------------------------------------------------------
PVT Private Indicates that the message may only be read
by its addressee and author.
HLD Hold Message should be held for pickup by its
destination system.
CRA Crash High-priority mail.
K/S Kill/Sent Remove message after it has been success-
fully sent.
SNT Sent Message has been successfully sent (used
for message without Kill/Sent status).
RCV Received Message has been read by its addressee.
A/S Archive/Sent Place message in "sent mail" archival
system after it has been successfully sent.
DIR Direct Message must be sent directly to its
destination and may not be routed.
ZON Zonegate Send message through zonegate (if
possible).
HUB Hub/Host-route Host- or Hub-route message (as
appropriate).
FIL File attach Message has one or more files attached to
it.
FRQ File request Message has one or more file requests in
subject field.
IMM Immediate NOW!-priority mail. Send at first
opportunity, override any transmission
restrictions enforced by events, costs, or
qualification.
XMA Xmail Message has alternate form of compressed
mail attached.
KFS Kill file Remove attached file(s) after they have
been successfully sent. Only valid for file
attach message.
TFS Truncate file Truncate attached file(s) to zero length
after they have been successfully sent.
Only valid for file attach message.
Primarily used by Conference Mail
processors.
LOK Lock Prevent message from being processed.
This includes sending, deleting,
purging, and editing.
RRQ Receipt REQ When the mailer/packer at the message's
final destination unpacks the message, it's
asked to generate a receipt to the author
of the message that indicates that the
message arrived at its final destination.
CFM Confirm REQ When message is read by its addressee, a
Confirmation Receipt should be generated to
the author of the message.
HIR HiRes FAX: Hi-Resolution image.
COV CoverLetter FAX: Cover sheet.
SIG Signature FAX: Signature.
LET LetterHead FAX: LetterHead.
| FAX Fax image The filename specified in the message's
| subject field contains a fax document that
| should be viewed using software capable of
| doing so.
| FPU Force pickup Treated as a message with an IMM flag. This
| instructs the mailer to keep calling the
| destination system, if the connection is
| aborted for some reason, until a valid "End
| of files" signal is received (i.e. no more
| files remain to pick up).
Notes
Xmail is related to the ARCmail 0.60 standard as adopted by the FTSC.
The exception is that any type of compression method may be used and
the naming convention isn't necessarily limited to that of the
ARCmail 0.60 standard.
Epilogue
Feedback would be appreciated and can be sent to me at the addresses
specified on the title page. Please send feedback via netmail.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

1079
html/ftsc/fsc-0056.html
View File

File diff suppressed because it is too large Load Diff

534
html/ftsc/fsc-0057.html
View File

@ -1,534 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Conference Managaers - Specifications for Requests.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0057
Version: 003
Date: 07-Dec-92
Conference Managers - Specifications for Requests
December 7, 1992
Fabiano Fabris Joaquim H. Homrighausen
2:285/304.100@fidonet 2:270/17@fidonet
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community, and
requests discussion and suggestions for improvements. Revision 3
presents several additions and enhancements over the previous revision.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
1 Purpose
This document will explore the methods implemented by various
conference managers which process requests (in net mail form)
for changes to the conference mail links on the system on which
they are in use.
Until now, it would appear that no real standard exists, so most
software authors have either tried to emulate another program, or
to create a new method of their own, or both.
Here, an attempt will be made to define a standard, one which tries
to maintain compatibility with methods already in use, while also
extending them to provide new functions.
2 Conventions
The names of the commands described in the following paragraphs are
given in upper case, for legibility. However, a conference manager
should be able to interpret them even if they are given in lower
or mixed case.
Similarly, conference names, or tags, are given in upper case, but
the conference manager should be able to handle them even if typed
in lower or mixed case.
Optional information is enclosed with square brackets, while
variable information is enclosed with angle brackets. For example:
+CONF [,R=&lt;n&gt;]
indicates that the section within square brackets is optional, and
if supplied, requires a parameter after the equals sign.
Some conference managers may allow commands to be abbreviated to the
shortest non-ambiguous string. For example, %LIST might be reduced
to %L.
3 Format of the request
A request to a conference manager is generally made in a net mail
message containing specific information in some of the fields. In
particular, the addressee is the name of the conference manager
itself, and the subject of the message is a password assigned by
the sysop of the system running the program.
For example:
From: John Doe, on 2:123/56
To: Program, on 2:234/0
Subject: password
Here the first problem is encountered. Each of the existing programs
recognizes a different addressee. For this reason it is proposed
that all such programs recognize requests made to a single,
"standard" addressee, besides any other they may wish to implement.
The term "ConfMgr" has been arbitrarily chosen, and should be used
by those programs which adhere fully to all the standards proposed
in this document.
The text of the message itself contains the request proper, and is
the subject of the following paragraphs.
4 Linking and Unlinking of conferences.
The current methods for requesting that a conference be linked are
basically two:
+CONFNAME
CONFNAME
For reasons of uniformity, it is proposed that all conference
manager programs recognize the first method.
Requests that a conference be unlinked are given by:
-CONFNAME
It might be interesting to implement some form of pattern matching,
similar to the unix shell. The following basic wildcards should be
considered:
* matches zero or more characters
? matches any one (not zero) character
Since the requests are processed top-down, a request of the form
+CONFNAME
-*
would be redundant, since the ConfMgr would link CONFNAME from the
first line, and then immediately unlink it again because of the
second line, which requests that all linked conferenecs be unlinked.
It should also be possible to specify more than one conference tag
on the same line. For example:
+CONF1 CONF2 CONF3
would link the three conferences CONF1, CONF2 and CONF3.
5 Rescanning Conference Mail
Many conference managers currently allow a system to request that an
area be "rescanned". In other words, the system receiving the
request will export all mail in one or more areas to the requesting
system.
This may be accomplished by specifying the %RESCAN command in the
body of the request. This will force the ConfMgr to generate a scan
request for those areas which the remote system requested with the
message containing the %RESCAN command.
Rescans of a single area, newly linked, could be requested as
follows:
+CONFNAME, R[=&lt;n&gt;]
where 'n' is the number of messages in that area to be rescanned.
(The space following the comma is optional, but allowed.)
Rescanning has one serious drawback: dupes! It is very possible for
the requesting system to have already set up the area with several
downlinks. Thus, when the rescanned mail is received, it could be
exported to other systems. In a tree-based topology, this is
harmless, but in circular topologies this would create dupes.
Thus, it is proposed that system receiving the rescan request add a
kludge to the messages, so that they can be recognized by the
requesting system and not re-exported.
The proposed kludge is:
^ARESCANNED &lt;addr&gt;
where &lt;addr&gt; is the network address, including domain, of the
system from which the mail was rescanned.
In alternative to a rescan, a sysop might request a "sample",
consisting of a series of messages contained in a text file. The
ConfMgr would export some or all messages from an area to a plain
ASCII text file, and send it along with the reply, to the requesting
system. A "sample" request would be made as follows:
+CONFNAME, S[=&lt;n&gt;]
where 'n' indicates how many messages should be sampled.
a) Updating Conferences
Update requests allow a sysop to rescan or "sample" an area
without having to first unlink from it, and then relink with the
rescan or "sample" parameter.
The format of this command is:
=CONFNAME, &lt;param&gt;[=&lt;n&gt;]
Thus a rescan request for the most recent 50 messages would be
specified as:
=CONFNAME, R=50
6 Information Requests
Requests for information have until now taken two forms. In one
case, they are given as switches after the password on the subject
line, while in the second they are given as "commands" within the
body of the message text. It is proposed that the second method be
chosen as standard, since it is considerably more flexible.
Below are listed the proposed commands:
%HELP Sends a (pre-defined) help text to the
requesting system, explaining how the
ConfMgr is to be used.
%LIST[,B] Lists the conferences currently available
to the requesting system, on the basis
of a method internal to the conference
manager itself. This list would flag the
areas which are already linked. The 'B'
modifier would generate the list in
binary format (see section 8e).
%BLIST Equivalent to %LIST,B above.
%QUERY Lists the conferences currently linked to
the requesting system.
%UNLINKED Lists the conferences which are available
to the requesting system, but not
currently linked. This is the logical
difference between a %LIST and a %QUERY.
7 Remote Maintenance
Besides these simple functions, it is becoming more and more
interesting to make handling of the conference mail flow even more
automatic. For this reason, for example, it might be useful to
allow another sysop control over your own system, adding and
removing conferences as need requires. Thus a hub or coordinator
could automatically have a new area added to their conference
lists, or discontinued ones removed.
Naturally, the ConfMgr must be able to distinguish which system has
the ability to make such changes, but that is beyond the scope of
this document.
It is proposed that a conference manager be able to automatically
add a new conference to the system's list if/when it is detected.
Thus no special commands would be required. The manager should be
able to determine a default list of down-links for the new area,
and also the "group" of systems which could then request it.
However, should it be desired to explicitly create a new conference
via remote, this could be done by including a line such as the
following in the message text:
&amp;CONFNAME
In order to remote delete an area, the requesting sysop should
include a line like this in the body of the message text:
~CONFNAME
Thus, if the system has remote privileges, the conference would be
deleted (and optionally, all systems linked to the conference could
be informed of this fact).
Similarly, it would also be possible to allow a system to change the
tag of a conference. This would be accomplished by a line such as:
# OLD_NAME NEW_NAME
The ConfMgr should inform all downlinks of the change by sending a
net mail message.
It might also be desirable to allow a sysop to make changes on
behalf of another system. This could be done by inserting a special
command at the beginning of the request itself. For example:
From: John Doe, on 2:123/1
To: Program, on 2:987/65
Subject: password
Text:
%FROM: 2:234/56
+CONFNAME
The %FROM command would make the ConfMgr carry out the changes as if
the system 2:234/56 had requested them. The password should
nonetheless be the one assigned to 2:123/1.
8 Further Automation
In order to make the system more powerful, and to reduce the
necessity for human intervention, several extensions are feasible.
a) ARCmail Compression Method
One interesting application is the possibility of allowing a
remote system to change the compression program used to "pack"
mail bound for his system. This could be done with the following
command in the message to a ConfMgr:
%COMPRESS &lt;method&gt;
where &lt;method&gt; is one of the compression programs supported by
the system. Of course, the remote system should also be able to
determine which compression methods are available; this could be
done with
%COMPRESS ?
Requests for an unsupported compression method should also be
responded to with a list of those available.
From the practical point of view, only systems which pick up
their mail (as opposed to those to whom mail is sent) should be
allowed to change the compression method used. How this
distinction is achieved is beyond the scope of this document.
b) Passwords
A sysop should be able to change the password used to make
requests to a ConfMgr without requiring the intervention of the
other system's sysop. This could easily be done if the
conference manager implemented the following command:
%PWD &lt;new_password&gt;
The new password (case insensitive) would replace the current
one as of the next request.
c) Temporary Unlink
Should a system's sysop be absent for a prolonged period of time,
he might want to temporarily cut all conferences from his
uplink. This could be accomplished with the
%PAUSE
command. This would tell the ConfMgr to temporarily stop sending
conferences to that system. On his return, the sysop could
reactivate them all with the
%RESUME
command.
d) Forwarding Remote Requests
If a conference manager receives a remote request to delete an
area, it could very easily "forward" that request to all its
downlinks by producing a similar request. In that way, a single
request originating from, for example, a Region Coordinator,
would result in the conference being deleted from all systems
"below" him.
Similarly, remote requests for conference name changes could
also be passed on to downlinks.
e) Automatic Requests for Conferences
A conference manager should also be able to automatically request
an area from an uplink. This would become necessary if, for
example, it processed a request for an area not currently
available on the system. In this case, it would scan a series of
conference lists for the requested area, and if found, would
send a request for that area.
In order to be able to do this, the ConfMgr would need to have
one or more lists of conferences from the uplinks. These lists
could be produced on request by the ConfMgr itself. In order to
simplify matters, a binary format is proposed. (Note that these
are C-style structures, with everything which that implies.)
This binary file is called a Binary Conference List (BCL).
The file starts with a header, containing some basic system
information:
struct bcl_header {
char FingerPrint[4]; /* BCL&lt;NUL&gt; */
char ConfMgrName[31]; /* Name of "ConfMgr" */
char Origin[51]; /* Originating network addr */
long CreationTime; /* UNIX-timestamp when created */
long flags; /* Options, see below */
char Reserved[256]; /* Reserved data */
}
The currently defined flags for the header are:
BCLH_ISLIST 0x00000001L
File is complete list
BCLH_ISUPDATE 0x00000002L
File contains update/diff information
The BCL would then contain a series of entries having the
following format:
struct bcl {
int EntryLength; /* Length of entry data */
long flags1, flags2; /* Conference flags */
char *AreaTag; /* Area tag [51] */
char *Description; /* Description [51] */
char *Administrator; /* Administrator or contact [51] */
}
The flags currently defined are:
FLG1_READONLY 0x00000001L
Read only, software must not allow users to enter mail.
FLG1_PRIVATE 0x00000002L
Private attribute of messages is honored.
FLG1_FILECONF 0x00000004L
File conference.
FLG1_MAILCONF 0x00000008L
Mail conference.
FLG1_REMOVE 0x00000010L
Remove specified conference from list (otherwise add/upd).
Thus, instead of scanning an AREAS.BBS style list, the ConfMgr
would parse and use lists in the above format. Naturally, each
list would be in some way "attached" to a node number, and a
corresponding ConfMgr password.
Each system may only have one master file, called anything they
want. But when transmitted to other systems, this file must
always be named ????????.BCL.
The list would be generated in response to a
%LIST, B
command in the message text.
f) Receipts
It might be useful to have the ConfMgr generate a receipt to be
sent to another system, perhaps a co-sysop or a sysop point
node. This could be done with the command:
%RECEIPT &lt;name&gt;,&lt;address&gt;
embedded in the request message. For example:
%RECEIPT JoHo,2:270/17
9 Comments in the request
It should be possible for a sysop to insert a comment in the request
made to a conference manager. These comments, naturally, would be
destined to the sysop of the system, and not to the conference
manager itself. Such comments should be placed at the end of the
message, following a %NOTE command.
In all cases except the above, the request can be deleted by the
ConfMgr once processed, but messages containing comments should be
retained.
Note: the current method used is to supply comments after a tear-
line. This practice is somewhat "messy", but it might be wise to
support it until such time as all conference managers have
implemented the %NOTE command.
10 Summary
+CONFNAME[,R|S] Request to link to CONFNAME
-CONFNAME Request to unlink from CONFNAME
=CONFNAME,R|S Rescan or "sample" linked conference
&amp;CONFNAME Request to create CONFNAME
~CONFNAME Request to delete CONFNAME
#OLD NEW Name change request
%LIST[,B] List available areas, flag linked
%QUERY Only list linked areas
%UNLINKED List available but unlinked areas
%HELP Send help text
%FROM &lt;addr&gt; Simulate request from another system
%RESCAN Rescan conferences linked in current request
%COMPRESS &lt;method&gt; Change compression method
%PWD &lt;new_pwd&gt; Change ConfMgr password
%PAUSE Suspend link
%RESUME Resume link
%RECEIPT &lt;name&gt;,&lt;addr&gt; Send copy of receipt to another system
%NOTE Introduces comment to the sysop
11 Final Note
This document is to be considered as a suggestion for software
developers to make their programs compatible with one another, so as
to make life easier for the average sysop when dealing with
conference managers.
Feedback would be appreciated and can be sent to us at the addresses
specified on the title page. Please send feedback via netmail only.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

1623
html/ftsc/fsc-0059.html
View File

File diff suppressed because it is too large Load Diff

364
html/ftsc/fsc-0062.html
View File

@ -1,364 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Proposed Nodelist flag indicating Online Times of a Node.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FSC-0062
| Version: 003
| Date: April 14, 1996
| Author: David J. Thomas
A Proposed Nodelist flag indicating Online Times of a Node
David J. Thomas
2:442/600@fidonet.org
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Note
----
Changes in content between the previous edition of this document, and this
edition, are signified by bars (|) in the left margin, except where
otherwise specified. I have changed the format of the document slightly to
allow this. Where the format of the document has changed, but the actual
text has not, bars are not present.
Purpose
-------
There are currently several systems within FidoNet that offer file request
or mail holding capabilities but are not continuously online. The only time
during which these nodes can be contacted with reference to the nodelist is
currently the Zone Mail Hour of the zone to which the systems belong. In
theory, mailers can only use the zone mail hour(s) specified by the system
in question to contact these nodes, which does not provide for any method
of file requesting or calling for echomail that does not conflict with the
Policy requirement that no echomail or files be transferred during the zone
mail hour. This means that, in practice, if it is known that a particular
node is online for more time than ZMH alone, but less than 24 hours a day,
it is necessary to "kludge," or set this up as a special situation, in most
mailers whenever a node has to be contacted a number of times, whether
regularly or irregularly. The proposed flag would benefit the mailers in
such a way as to provide for them the online times that the node is usually
online for, thus cutting on the costs of calling a non-continuous mail
node, only to find that it is not available; and also, hopefully preventing
annoyance for a sysop whose mailer is being called whilst it is not online,
for example in the case of a voice/data shared line.
Compatibility
-------------
Since the current nodelist format is always being extended and nodelist
processors look only for the flags that they know about, there are no
expected compatibility problems with the suggestion outlined below.
Format of additional nodelist flag
----------------------------------
The proposed nodelist flag has the following form:
Txy
where x represents the startup time, and y the end time, in the following
format:
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
|Letter|Time| |Letter|Time| |Letter|Time| |Letter|Time| |Letter|Time|
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
| A |0000| | F |0500| | K |1000| | P |1500| | U |2000|
| a |0030| | f |0530| | k |1030| | p |1530| | u |2030|
| B |0100| | G |0600| | L |1100| | Q |1600| | V |2100|
| b |0130| | g |0630| | l |1130| | q |1630| | v |2130|
| C |0200| | H |0700| | M |1200| | R |1700| | W |2200|
| c |0230| | h |0730| | m |1230| | r |1730| | w |2230|
| D |0300| | I |0800| | N |1300| | S |1800| | X |2300|
| d |0330| | i |0830| | n |1330| | s |1830| | x |2330|
| E |0400| | J |0900| | O |1400| | T |1900| | | |
| e |0430| | j |0930| | o |1430| | t |1930| | | |
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
| This flag is not intended to be a user flag. The flag is intended to provide
| information to computerised mailer processes, and is not easily read by
| human beings (although they can of course interpret the meaning of the
| flag); most mailers however do not attempt to interpret any information that
| is specified as a user flag, assuming that it is there for the benefit of
| human beings. Such mailers would not be able to make use of the information
| provided, which is the purpose of the flag.
| This flag is of course not specified in FTS-0005 at the time of writing, but
| this is not regarded by FidoNet as a problem because other flags in current
| use are not specified in FTS-0005.
The case of the letter could be relevant. Whereas the case is currently not
used by any flags in the document describing the current format of the
nodelist, there exists the potential for the case of a letter to have
relevant meaning. The case has to be correct for the CRC check calculation
to prove correct, and this would be a good use for the case of the letter.
If it is necessary to ignore the case, then the upper on-the-hour time
should be used, i.e. the time that is listed after the upper-case letter.
| These times are expressed in UTC so that the flag is useful for systems all
around the world, without the need for specific time zone information to be
included in the nodelist. They do not adjust with daylight saving time for a
similar reason. Note the section on daylight saving time for information
about handling adjustments without changing the flag; this is important.
Where necessary, the times can wrap around midnight, so for example, for a
| node that is online between the hours of 1800 and 0600 UTC, the flag TSG
would be a valid indication of this time.
This nodelist entry is not required by any node. It is supplementary to the
#01, #02, #08, #09, #18, #20 flags and their !xx counterparts, though its
meaning is different. It has been suggested to me about the possibility of
an additional flag with the same meaning, but having a W as the first
letter, indicating that the node is also available for all hours during
weekends; however, I believe that the simple inclusion of the single flag
indicated above will solve most problems, as it does indicate a period for
non-CM nodes during which the node is available, which is all that is
really required.
Daylight saving time
--------------------
If a node changes online times with respect to UTC when daylight saving
time becomes effective (which would be the case with most part time nodes),
then this is to be taken into account when assigning this flag. An online
times flag assigned to a node should not be altered for the specific
purpose of adjusting due to daylight saving time, since large difference
files (NODEDIFF's) would result if every node was allowed to do this, e.g.
my node used to be online from 2300 to 0800 in local time, which in winter
| is UTC, but in the summer it becomes BST (British Summer Time). This is one
| hour ahead of UTC, and the corresponding availability times of my node
| during the summer period were 2200 to 0700 UTC. Therefore my online times
flag would have indicated availability between the hours of 2300 and 0700
| UTC, the daily time period encompassing both times, so the flag would be
TXH.
Policy considerations
---------------------
This is a technical document. However, since the flag could make for an
increase in the size of difference files, the author feels that the
following guidelines should be adopted concerning the use of the flag.
The online times flag does not replace the requirement for exclusivity of
zone mail hour to be maintained. It is still annoying behaviour to have
this flag and be unavailable during ZMH, just as it is annoying behaviour
to have the CM (continuous mail) flag in one's entry, and disregard ZMH.
Except for during ZMH, the sysop of a node using this flag finding that
they need to take their mailer offline during the specified times to
perform system maintenance, or for any other reason, would not be acting in
an annoying manner to do so, unless the practice is found to be continuous,
in which case the flag's times could be reduced, or the flag itself could
be removed from their node entry.
It should be noted that this flag is present for the benefit of mailers,
not human beings. This means that the flag should be used only to indicate
when a mailer is ready to receive calls. A system that uses a FidoNet-
technology mailer in ZMH, and a human-access only system during other
period(s) of the day that cannot receive mail, should not use this flag.
This flag does not explicitly specify online times of a public access BBS,
although for presumably most nodes with FidoNet-capable software, a public
access BBS will be available during the times indicated.
Where the flag is used, it should not often be changed. If a situation
exists, for example, where a node uses a certain set of times during the
first two weeks of a month, and a different set of times during the
remainder period, the flag should be set to a time during each day of the
month when the node is online. For example, if a node is online during
1800-0800 for the first two weeks, and then during 2200-1000 for the
remainder, the time flag should specify 2200-0800 only. If there is no such
time (other than ZMH) then no flag should be used. Of course, any permanent
changes, and any necessary reductions in the times, should be permitted at
any time, but changes owing only to daylight saving time should certainly
be expressly forbidden.
File requests and user access are of course permitted during the online
times indicated (except ZMH).
The above list may seem rather frightening! Please note that they are
guidelines rather than rules, unless FidoNet policy has included them as
rules. In the vast majority of situations where a node is online for a
fixed set of hours per day, the only thing to watch out for is that you get
the daylight saving time period right. Then you don't have to worry about
changing it at any time, except when your own online times change.
Example
-------
With regard to time zones now; this is a complicated topic, so I wish to
express an example. Imagine a node in Indiana, USA. It is online for the
time period beginning 6 o'clock pm (1800) and ending 8 o'clock am (0800).
This changes with daylight saving time, so the times expressed effectively
| become an hour earlier with respect to UTC during daylight saving time.
| Indiana is in the Central time zone, which is 6 hours behind UTC. Therefore,
| the online times in UTC can be expressed as 0000-1400 UTC during winter.
| During daylight saving time, however, the local time for Indiana is 5 hours
| behind UTC. The online times during this period are 0100-1500 UTC. The
| subset should be used, so that the online times flag for the node should
| indicate availability between 0100 and 1400 UTC, which is indicated
| by the flag TBO.
| (Thanks to a few people for pointing out that the previous example was in
| error; it assumed that Indiana was ahead of UTC, and not behind as is
| actually the case.)
ANSI C routines to Calculate the Online Times Flag
--------------------------------------------------
These were not provided in the first edition. Change bars will not be used
here, since they would interfere with the syntax of the presented routines.
The first program calculates the online times flag from the user's entry of
the online times of a system, expressed in the local time zone, and the
offset to UTC used by the user's country. It takes into account that the
clock is put forward and back once a year by reducing the end time by one
hour. The program should work on any platform, and has been tested.
=== start of code ===
/* TIMEFLAG.C
Calculates FSC-0062 time flag requirement from user input */
#include &lt;stdio.h&gt;
char *onlineflag(char *on, char *off, int utc_diff);
void main()
{
char on[6], off[6]; int utc_diff;
printf("\nPlease specify the time you come online [HH:MM]: ");
scanf("%s", on);
printf("\nPlease specify the time you come offline [HH:MM]: ");
scanf("%s", off);
printf("\nSpecify the difference between your local time zone in winter\n"
"time and UTC (e.g. if your time zone is 6 hours behind UTC,\n"
"enter 6): ");
scanf("%d", &amp;utc_diff);
printf("\nYour online time flag is %s\n\n",
onlineflag(on, off, utc_diff));
}
char *onlineflag(char *ontime, char *offtime, int utcdiff)
{
int onhour, onmin, offhour, offmin;
static char flag[4]="T ";
sscanf(ontime, "%d:%d", &amp;onhour, &amp;onmin);
sscanf(offtime, "%d:%d", &amp;offhour, &amp;offmin);
if(onmin&gt;30) ++onhour;
--offhour; /* to correct for daylight saving time */
onhour = (onhour+24+utcdiff) % 24;
offhour = (offhour+24+utcdiff) % 24;
flag[1]='A'+onhour;
flag[2]='A'+offhour;
if(onmin&gt;0 &amp;&amp; onmin&lt;31) flag[1] += 'a'-'A';
if(offmin&gt;29) flag[2] += 'a'-'A';
return flag;
}
=== end of code ===
The second program calculates the online times from the time flag, input
as a pointer to char to the routine (this being of the format "Txy"). It
returns a pointer to a structure which contains the on- and off-times in
UTC. This is not a complete program; it is designed to be used by mailers
to determine the valid online times. It has also been tested.
=== start of code ===
/* INTFLAG.C
Interprets online time flags and converts them to a set of UTC times */
struct TIMES {
int on_hour;
int on_min;
int off_hour;
int off_min;
};
struct TIMES *interpret_flag(char *time_flag);
struct TIMES *interpret_flag(char *timeflag)
{
static struct TIMES times;
times.on_min=0;
times.off_min=0;
times.on_hour=timeflag[1]-'A';
if(times.on_hour&gt;23) {
times.on_hour -= 'a'-'A';
times.on_min=30;
}
times.off_hour=timeflag[2]-'A';
if(times.off_hour&gt;23) {
times.off_hour -= 'a'-'A';
times.off_min=30;
}
return &times;
}
=== end of code ===
| The above routines can be copied and re-used as desired. I am now an
| amazing C programmer, but I still make no guarantees about them! :-)
Summary
-------
I believe this to be a neat and compact solution to, what is in my opinion,
one of the gravest problems currently facing FidoNet. In FidoNet, most
nodes are continuous mail, but it is important for the growth and
popularity of FidoNet that non-CM nodes do not receive many mailer calls at
times when they are off line. Users are bad enough in this respect. It is
also useful for people wishing to contact hubs that are non-CM with mail
for a downlink, and for people wishing to file request from a node that is
not CM. There is no need for systems that are only online in zone mail hour
to adopt this flag; also, there is no need for CM systems to adopt this
flag.
Contacting the Author
---------------------
My board is now online continuously, except for periods of down time during
| which the board is maintained (few and far between now that Linux is used).
Netmail contact is therefore possible at any time. I went CM because of a
certain number of nodes calling at the wrong times, and also users. Users
weren't too bad, but I dislike 0600 am wake-up calls, repeated at regular
three-minute intervals for an hour, by mailers, rather intensely :-)
End of document.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

123
html/ftsc/fsc-0070.html
View File

@ -1,123 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Improving FidoNet/UseNet gating and Dupe Checking.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0070
Date: 15-Jul-94
Revision: 002
Improving Fidonet/Usenet gating and Dupe Checking
Franck Arnaud, Fidonet 2:320/213.666
Status of this document
-----------------------
This FSC suggests a proposed standard for the FidoNet(r) community,
and invites discussion and suggestions for improvements. Distribution of
this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido Software.
Introduction
------------
The complexity of Usenet/Fidonet gating and the large number of gateways
has led to a non-negligible quantity of duplicates appearing regularly in
both the Usenet and Fidonet worlds. This proposal defines a standard method
for gateway software to deal with conversion of message identifiers between
both worlds, so that we can improve the reliability of Usenet/Fidonet
gateways.
In this document "^" means &lt;control-A&gt; (character 01h).
History
-------
Revision 002 adds details and makes the Fidonet to Usenet sheme FTS-0009
compliant.
Usenet To Fidonet Message Identifier Conversion
-----------------------------------------------
A major problem is preventing messages gated into Fidonet from RFC822 from
being gated back to Usenet at another gateway with a new message id. The
easy way to solve that is simply to store the RFC message ID in a kludge
line. This kludge line could also allow identifying messages gated from
Usenet (this could be used by message editors to allow private replies to
the nearest uucp gateway for example).
It is proposed that the ^RFCID: kludge is used to store the RFC Message-ID:
in Fidonet messages. Of course, the use of the RFCID kludge doesn't replace
the standard fts-0009 Message-ID:.
(Usenet) Message-ID: &lt;92_feb_10_19192012901@prep.ai.mit.edu&gt;
to (Fido) ^MSGID: 2:300/400.5 6789fedc
^RFCID: 92_feb_10_19192012901@prep.ai.mit.edu
Note ^RFCID does not include the Message-ID enclosing "&lt;" and "&gt;".
Then if a gateway finds a ^RFCID line in a Fido message, it will use it in
the Usenet message ID, instead of converting the ^MSGID.
Fidonet to Usenet Message Identifiers Conversion
------------------------------------------------
The dupe checking in Usenet is based on the message ID. Fidonet now has its
own standard message identification standard (fts-0009).
So it would be interesting if the same Fidonet message gated at different
gateways had the same ID in Usenet to help news processing programs in
stopping dupes.
The proposed fido ^MSGID: to RFC1036 Message-ID: conversion method is
defined as below:
The ^MSGID: value (a string) is not parsed and converted as below to the ID
part of Usenet's Message-ID. The Message-ID domain is the fidonet domain,
"fidonet.org" if the gated echomail comes from the Fidonet(tm) network.
To convert the MSGID string, the following rules are applied:
- Alphanumeric (a-z,A-Z,0-9) characters are kept intact (case preserved).
- Non-alphanumeric characters - including the space beetwen the origin
address and the serial number - are converted to '-'.
Some examples:
(Fido) ^MSGID: 2:300/400 12345AbC
to (Usenet) Message-ID: &lt;2-300-400-12345AbC@fidonet.org&gt;
(Fido) ^MSGID: 15:300/400.50@somenet abcd6789
to (Usenet) Message-ID: &lt;15-300-400-50-somenet-abcd6789@fidonet.org&gt;
(Fido) ^MSGID: Internet.Domain.org aBcD1234
to (Usenet) Message-ID: &lt;Internet-Domain-org-aBcD1234@fidonet.org&gt;
(Fido) ^MSGID: "LZKkoe$1982 98a" 45678bcd
to (Usenet) Message-ID: &lt;-LZKkoe-1982-98a--45678bcd@fidonet.org&gt;
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

1926
html/ftsc/fsc-0072.html
View File

File diff suppressed because it is too large Load Diff

306
html/ftsc/fsc-0087.html
View File

@ -1,306 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>File Forwarding in Fidonet Technology Networks.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FSC-0087
| Version: 001
| Date: 31 October, 1995
|
| Robert Williamson FidoNet#1:167/104.0
File Forwarding in Fidonet Technology Networks
Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
Purpose:
To document current practices in File Forwarding and the minimum
requirements and known extensions of the TIC file format.
Acknowledgements:
The TIC file format was introduced by Barry Geller, in the MSDOS
File Forwarder, Tick. Useful extensions to this format were introduced
by Harald Helms, in the MSDOS FileForwarder, AllFix.
Terminology:
FTN - Fidonet Technolgy Network, such as FIDONET, AMIGANET or IBMNET.
Sometimes used interchangably with the term DOMAIN.
FNC - FileName Conversion, process of converting filenames to msdos 8.3
format for transmission.
FQFA - Fully Qualified FTN Address, the format is
FTN#Zone:Net/Node.Point
CRC - Cyclic Redundancy Check, method to determine whether some data
has been altered. CRC-32 is used in File Forwarding.
TIC - a file that contains control information for the File Forwarding
system. These files are named xxSTAMP.TIC, where xx is an
abbreviation representing the File Forwarding program name and
stamp is a unixdate stamp truncated to 6 characters.
UTC - Universal Time Coordinated, the time at the 0o meridian
(Greenwich); previously called GMT
forwarding - the process of creating and sending tic files and the
associated file to one's downlinks.
ticking - the processing of reading and verifying a tic file and it's
associated file.
hatching - the process of introducing a new file into a fileecho
cross-hatching - the process of forwarding a file from one fileecho
(ususally restricted) to another
Associated File - The file listed in the FILE field of the TIC file.
Note that use of UPPERCASE on tic file keywords in this document in
for display purposes only.
Format of a TIC file:
Addressing:
In a tic file any form of FTN address representation from 3d to
FQFA may be used. All File Forwarders must understand the
following formats:
zone:net/node - 3D
zone:net/node.point - 4D
zone:net/node@ftn - 5D - point 0 assumed
zone:net/node.point@ftn - 5D
ftn#zone:net/node.point - fqfa
File Forwarders should have configurable options per site as to the
type of addressing each of it's downlinks can understand.
Dates:
All dates are expressed in UTC.
TimeDateStamps:
All TimeDateStamps are unix TimeDateStamps (# of seconds since Jan
1, 1960) in UTC and expressed in hexadecimal notation.
Case Insensitivity:
the format is completely case-insensitive. It is general practice
that the first letter of a keyword is uppercase. This is not a
requirement.
Order Dependancy:
keywords are not order dependant.
Order dependancy is required in some groupings of a keyword, such
as PATH, VIA, DESC and APP.
Modification of address fields on PassThrough:
The forwarding site may modify the addresses in any keyword field
to make them compliant with the addressing limitations of each
downlink.
Stripping of SeenBys:
The forwarding site may strip seenbys to current FTN, ZONE or NET,
when not forwarding outside of current FTN, ZONE or NET. This does
not imply nor permit the stripping of of a direct downlink which is
outside the current strip filter.
Keywords:
There are no colons on keywords.
Each keyword line is terminated with CR LF pair.
The maximum length of a keyword line is 256 characters, including the
CRLF termination. Some keyword lines may have a shorter limit.
Keywords are separated from their data by a single space. There is
no space if there is no data associated with the keyword.
eg: ReturnReceipt
Keywords are case-insensitive and order independant.
Keywords not understood are to be passed-though.
Known Keywords that are blank should not be passed though.
For example, an empty AREADESC, could be either dropped or the
blank replaced with the proper description.
Most Keywords are passed through when processing.
There are exceptions. In some cases, a site-specific replacement
may be created.
Keywords marked with a ^ should not be passed-through.
Keywords marked with a * are REQUIRED when processing a TIC file.
If any of these are missing, the tic file should be considered as
BAD and the associated file not forwarded to downlinks.
Keywords marked with a # are CREATED when hatching or forwarding.
*# AREA [AreaName]
the TagName of the file area.
AREADESC [description of area] OPTIONAL
a short (80 chars) description of the file area. This could be
the description found in FileBone.NA
*# FILE [File being sent]
the name of the file being sent, no path
the filename must conform to msdos 8.3 format, unless it is known
that the receiving site can handle longer filenames.
^# FULLNAME [original filename before FNC] OPTIONAL FNC only
the original filename (no path) before FileName Conversion
*# CRC [CRC-32 in hex]
crc of the file being sent, 8 hexadecimal characters
^ MAGIC [MagicName] OPTIONAL
Name under which the file can be FREQed from the site listed in
FROM. This is NOT passed though when forwarding, unless the
MAGIC name is the same on the forwarding site. It can be
replaced by the appropriate name.
REPLACES [FileName] OPTIONAL
Filename (no path) of a file hatched in the AREA that the
associated file replaces. If the site expects FNC files, and the
filename does not confrom to msdos 8.3 convention, the REPLACES
name should also be FNC.
# DESC [Description]
Description of the file, limited to 80 characters per line,
including CRLF termination.
If multiple LDESC lines are used, the DESC line must provide the
maximum information. No File Forwadrer is required to passthough
or make use of any extra DESC line after the first.
# LDESC [multiple lines]
A long description of the file. LDESC does NOT replace DESC, it
is used IN ADDITION to the short description. No File Forwarder
is required make use of LESC lines.
# SIZE [Bytes] OPTIONAL, SHOULD be required
Length of the file in bytes
DATE [TimeDateStamp]
TimeDateStamp of the file. Can be date of creation of archive.
RELEASE [TimeDateStamp]
Date when file is TO BE released. Usually used by SDS, but can
be used by ADS as well.
AUTHOR [name]
Name of the author of the software package being hatched. This
field is obviously not applicable to Newsletters, Nodelists and
Diffs and the like.
SOURCE [authors_address]
FTN address of the Author of the software package being hatched.
Not necessary the same as the ORIGIN hatch site. Does not have
to be an FTN address.
^ APP [program] [Application Specific Information]
The APP keyword is a keyword known to programs of the name
indicated. APP'S are order dependent and must be passed though.
*# ORIGIN [Address]
Site where file entered the fileecho
*^# FROM [Address] [Pwd]
Site that is forwarding the file to the next site. Pwd is
optional and rarely used, IF AT ALL. Pwd is NEVER passed through.
^ TO [Address] OPTIONAL
Site to which this TIC and the assocaited file are being sent.
This keyword is included in the .TIC file when:
a) the file is being routed via another system which permits
such routing.
b) the platform in use does not have any FTN software
independant method of associating a file nd it's
destination. eg. platforms that do not have filenotes
that could contain this information as part of the
filesystem.
If the address in the TO line is that of the receiving site, the
field is not passed through when forwarding. If the address in
the TO lines IS NOT that of the receiving site, it should be
forwarded to the TO site, if a routing agreement is in place with
the sending site.
*^# CREATED [by] [Program Banner]
File Forwarder which created the TIC file. This is generally in
the form:
Created [by] program_name version [copyright_info]
VIA [FROM CREATED] OPTIONAL (tracking)
Copy of CREATED line of FROM, with 'Created [by]' stripped and
FROM prepended. Always passed though. The VIA is only created
by the receiving site when forwarding. It is never created by the
hatching site. Therefore, in any TIC file, the addresses in the
FROM and VIA should never be the same.
examples:
Via 1:167/100 ALLFIX+ 4.31 Copyright (C) 1992,95 Harald Harms (2:281/910)
Via FIDONET#1:167/104.0 XTick 3 Copyright (c) 1995 Robert Williamson FIDONET#1:167/104.0
*# PATH [Address] [TimeDateStamp] [date and time]
Address of Site which has forwarded the file. TimeDateStamp,
date and time is that of when the Site received and Processed the
file.
* # SEENBY [Address]
Site which has received the file. There are multiple lines of
Seenby and they are unordered.
* PW [password]
Site or Area password. This is case-insensitive and should be at
least 5 characters in length.
PGP [signature]
PrettyGoodPrivacy signature. To be discussed.
^ ReceiptRequest -no data- OPTIONAL
A request to the receiving system to generate a IsReturnReceipt
(attribute word bit 13) messsage, in the same manner it would if
it had received a message with the FileAttach an ReturnReceipt
attributes and a subject of the filename.
There is NO requirement to recognize this keyword. It should
never be passed through.
Transmission of Files:
The associated file, that is, the file Listed in the FILE field of the
TIC file, should always be sent FIRST. In the case of a failed session,
sending the FILE first prevents the orphaning of the file that is
normally caused by the deletion or movement of the TIC file to BAD.
File Forwarders should not move or delete orphaned TIC files, but this
can neither be relied upon nor mandated.
File Forwaders should be transparent to the renaming of file by
mailers. This means that if the mailer renames a duplicate file by
renaming or bumpinmg a numeric extension, the File Forwarder should be
able to use the size and crc fields of the TIC to find and properly
rename the associated file referred to in the TIC.
File Forwaders should always delete and dequeue unsent TIC files when
re-hatching the same or updated version of an associated file. The
implementor may wish to allow exceptions for periodicals such as
nodediffs and newsletters.
-to be continued-
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

327
html/ftsc/fsc-0088.html
View File

@ -1,327 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Compatibility and Link Qualifier Extensions for EMSI Sessions</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FSC-0088
| Version: 001
| Date: 31 October, 1995
|
| Robert Williamson FidoNet#1:167/104.0
Compatibility and Link Qualifier Extensions for EMSI Sessions
Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
Purpose:
The basic purpose of this document is to start discussions which will
hopefully result in an improved handshake negotiation protocol.
Scope:
Relation of flags to Types of files transferred:
The FSC-0056 EMSI specification (hereafter referred to as EMSI-I)
makes little distinction between ARCmail/packets and other types of
files, such as files attached and TIC'ed files. In EMSI-I, the term
'Mail' when not used in conjunction with the term 'compressed', is
interpreted to mean ANY file.
This extension (hereafter referred to as EMSI-II) makes reference to
and allows control of types of files in addition to 'compressed mail'.
References to 'Mail' are changed to 'File' where common practice so
indicates. The additional qualifier flags described provide for more
control as to the types of files a system is prepared to receive.
Relation of flags to presented addresses:
The EMSI-I specification does not allow qualification for any address
other than the PRIMARY address. This means that Link flags are limited
in application to either all presented addresses or to the primary
presented address only.
This extension also allows application of Link flags to specific
addresses other than the primary.
Distinctions between Calling and Answering System:
In the EMSI-I spec, the type of flags that may be presented is limited
by the status of the site. Certain flags may only be presented when
the site is the caller and other flags may only be presented when the
site is the answerer. This proposed extension removes this
distinction.
In the EMSI-I spec, certain Link and Capability (a.k.a: Compatibility)
flags are caller-driven, while others are controlled by the answering
system. This specification attempts to harmonize these discrepancies.
A attempt is made to remain somewhat backwards compatible and to have
new flags follow the original flag naming convention. However, IMHO,
it would be preferable to harmonize the flags; reducing the number of
them while retaining the fine type control, so that the same codes are
used in all sessions.
Under both EMSI-I and EMSI-II, any flags that are not understood, are
to be ignored. Therfore, if a site presents it's flags in EMSI-II
format and the other site does not do EMSI-II, it is permissable for
that site to interpret all flags according to EMSI-I specifications.
Specifics:
Compatibility flags:
Compatibility flags consist of a string of codes that specify the
PROTOCOL CAPABILITIES and ENABLED FEATURES of the mailer.
ARC, XMA
These EMSI-I compatibility flags have no meaning relavant to the
transfer of files and are not to be presented under EMSI-II. If
received, they are to be ignored.
FNC
The FNC EMSI-I compatibility flag has been identified as a 'mistake' by
the author of EMSI-I. This is agreeable as that specification called
for the creation of a filename that was ALWAYS 8.3, not
up-to-8.up-to-3.
It is not to be presented under EMSI-II. If received as a
compatibility flag, it is to be ignored.
Protocol Selection:
In the EMSI-I spec, a requirement is placed upon the calling system to
present it's available protocols in order of preference. A quote
follows:
The calling system must list supported protocols first and
descending order of preference (the most desirable protocol
should be listed first).
The answering system should only present one protocol and it
should be the first item in the compatibility_codes field.
Some mailer authors have interpreted 'the compatibility_codes field' in
the second sentence to mean that of the answering system, thereby
making protocol selection RECEIVER-PREFS driven. This interpretation
makes unnecessary the 'decending order' requirement placed upon the
calling system, so shall be considered in conflict with that
requirement.
Most mailer authors have interpreted that phrase to mean the
'compatibility_codes field' OF THE CALLER, thereby making protocol
selection CALLER-PREFS driven. Since EMSI-I was intended to be "a
clear protocol definition for state-of-the-art E-Mail systems to
follow", they cannot be faulted for interpretation. Caller-prefs
driven selection is state-of-the-art, receiver-prefs driven selection
is older technolgy, such as Wazoo.
This specification requires that the second interpretation,
CALLER-PREFS driven, be mandatory.
New Compatibilty Flags:
----------------------
EII
Indicates that the system will interpret flags under this
specification, if other end also presents this flag. IF either or both
systems do not present this flag, all interpretations are done
according to EMSI-I.
DFB
Indicates that the system presenting is capabable of fall-back to
FTS1/WAZOO negotiation in the case of failure of EMSI handshake or no
common protocol. Since ZMO is the minimum required protocol, NCP
should only occur if the answering system presents more than one
protocol.. (ie. it's broken)
FRQ
Indicates that the system will accept and process file requests
received during outbound calls. In other words, the calling system
will do a second turnaround for uni-directional protocols, to send the
files requested, at his cost.
NRQ
NRQ should be presented ONLY IF the mailer does not have a file request
server, task or function and cannot accept requests.. It should NOT be
used to indicate that the function is temporarly disabled.
When examined, No requests will be sent. It would be advisable that
the mailer alert the system operator of this occurance to prevent
continued polling of the remote site.
Protocol Capabilities:
Protocol capability flags are presented in decending order of
preference by the caller. The answering system selects and presents
the FIRST protocol from the callers list that it supports. The
answering system must present only ONE protocol.
HYD Hydra bi-directional (link flags define parameters)
JAN Janus bi-directional
TZA DirectZap (TrapDoor DirectZap varient)
DZA DirectZap (Zmodem variant, reduced escape set)
ZAP ZedZap (Zmodem variant, upe 8K blocks)
ZMO Zmodem w/1,024 packets (Wazoo ZedZip)
SLK SeaLink (no TYSNC, No MDM7, No TeLink)
(8-32k window/ReSync/OverDrive/LongNames)
NCP
This is presented if no compatible protocol can be negotiated under
EMSI. Since in most FTN networks, a common protocol DOES exist,
fallback to WaZoo and FTS1 negotiation is expected. If these
negotiation methods are not available, the session is terminated.
This condition should never occur under normal circumstances. It
should be considered as a problem with the design or configuration of
one of the mailers involved.
Link flags:
----------
Link flags consist of a string of codes that specify DESIRED CONNECT
CONDITIONS. They apply to the CURRENT SESSION ONLY. Under EMSI-I,
there are four TYPES of link flags: communications parameters, session
parameters, pickup options and hold options. Under EMSI-II, only three
types are used, the communications parameters type is REMOVED, as it
serves no purpose whatsoever in FTN operations.
Link Session options:
FNC
If either system presents this flag, it is an indication that the
presenting system requires filename conversion to cp/m-msdos
conventions. The other system will convert filenames to cp/m cpm/msdos
8.3 conventions before sending.
The convention is defined as a filename consisting of two
parts, the filepart and extension. The filepart and extension are
separated by a period ".". The filepart may be from 1 to 8 characters
in length and the extension may be from 0 to 3 characters. The
character set shall be any uppercase character in the range A-Z and any
numeric character in the range 0-9. If the extension is of zero
length, the period may or may not be present.
RMA
Indicates that the presenting site is able to send and process multiple
file requests. If both sites present this flag, the caller will send
any REQ files found for each AKA presented by the answering system.
The answering system will process each received REQ.
RH1
Indicates that under the Hydra protocol, batch one contains file
requests only, while batch 2 is reserved for all other files.
(others to be defined)
Pickup and Hold Flags:
Under the EMSI-I specification, Link Pickup flags are only presented
when calling (an Outbound Session) and are examined and processed only
when answering (an Inbound Session) and Link Hold flags are only
presented when answering (an Inbound Session) and are examined and
processed only when calling (an Outbound Session).
With EMSI-II, BOTH Pickup and Hold flags are presented by both sites
during a session. This allows more control for those systems, for
example, which cannot modify addresses presented or rotate akas to
change the primary address presented on a per-session or per-site
basis.
Link Pickup and Hold:
Each system can present one of three (or more) Link options related to
application of addresses. If neither of these flags are presented, PUA
is to be assumed.
Neither PUA nor PUP is to be presented if only one address was
presented.
PUP Pickup FILES for primary address only
/ PUA Pickup FILES for all presented addresses
/ PUn Pickup FILES for address number n in AKA list
one of |
\
\ NPU No FILE pickup desired. (calling system)
HAT Hold all FILES (answering system)
HAn Hold all FILES for address number n in AKA list
Qualifiers:
Qualifiers are processed in the order presented, with any conflict
being resolved by subsequent qualifiers overridding any conflicting
previous qualifier in the list.
Qualifiers may be not be presented with either NPU or HAT and should be
ignored if received with NPU or HAT.
PickUp:
PMO PickUp Mail (ARCmail and Packets) ONLY
PMn PickUp Mail ONLY for address number n in AKA list
NFE No TIC'S, associated files or files
attachs desired
NFn No TIC'S, associated files or file attaches,
for address number n in AKA list
NXP No compressed mail pickup desired
NXn No compressed mail pickup desired,
for address number n in AKA list
NRQ File requests not accepted by caller
This flag is presented if file request processing
is disabled TEMPORARILY for any reason
NRn File requests not accepted by caller
for address number n in AKA list
Note that NFE,NPX,NRQ != NPU
Hold:
HNM Hold all traffic EXCEPT Mail (ARCmail and Packets)
HNn Hold all traffic EXCEPT Mail (ARCmail and Packets)
for address number n in AKA list
HXT Hold compressed mail traffic.
HXn Hold compressed mail traffic.
for address number n in AKA list
HFE Hold tic's and associated files
and file attaches other than mail
HFn Hold tic's and associated files
and file attaches other than mail
for address number n in AKA list
HRQ Hold file requests (not processed at this time)
This flag is presented if file request processing
is disabled TEMPORARILY for any reason
HRn Hold file requests (not processed at this time)
for address number n in AKA list
Note that HXT,HRQ,HFE == HAT
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

61
html/ftsc/fsc-0091.html
View File

@ -1,61 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>ISDN nodelist flags (rev.002).</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: fsc-0091
| Version: 001
| Date: 01 Jun 1996
| Arjen Lentz, 2:283/512
ISDN nodelist flags (rev.002) Arjen Lentz (agl@bitbike.com)
addendum to FTS-0005 FidoNet 2:283/512
superceding FSC-0075 October 30th, 1995
Input from Michael Buenter, Jan Ceuleers, Chris Lueders, and others. Thanks!
The proposed new information text in nodelist trailer is as follows:
Nodelist Specification of minimal support required for this flag;
flag any additional support to be arranged via agreement between users
======== =================================================================
V110L ITU-T V.110 19k2 async ('low').
V110H ITU-T V.110 38k4 async ('high').
V120L ITU-T V.120 56k async, layer 2 framesize 259, window 7, modulo 8.
V120H ITU-T V.120 64k async, layer 2 framesize 259, window 7, modulo 8.
X75 ITU-T X.75 SLP (single link procedure) with 64kbit/s B channel;
layer 2 max.framesize 2048, window 2, non-ext.mode (modulo 8);
layer 3 transparent (no packet layer).
ISDN Other configurations. Use *only* if none of the above fits.
===========================================================================
NOTE: No flag implies another. Each capability MUST be specifically listed.
If no modem connects are support, the nodelist speed field should be 300.
Conversion from old to new ISDN capability flags:
- Nodes in the USA currently use the 'ISDN' flag.
Most will be able to change to V120H (64k lines).
Also many to V120L,V120H (64k lines) with autodetecting equipment.
Some to only V120L (still with 56k lines).
- Nodes in Europe currently use the ISDNA, ISDNB and ISDNC flags.
A simple translation will do the trick here.
ISDNA -&gt; V110L
ISDNB -&gt; V110H
ISDNC -&gt; X75
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

157
html/ftsc/fsc-0093.html
View File

@ -1,157 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Reduced seen-by lines.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FSC-0093
| Version: 001
| Date: 13 September, 1996
| Title: Reduced seen-by lines
| Author: Frank Ellermann, 2:240/5815.1
Reduced seen-by lines
Frank Ellermann, 2:240/5815.1
Abstract
--------
A way to save great amounts (estimated 10 %) of echo mail traffic by
reducing "seen by" informations, compatible with existing echo mail
tossers conforming to FTS-0004.
Definitions
-----------
A thorough understanding of FTS-0004 is required, the reader should
be familiar with PATH and SEEN-BY lines in echo mail, illegal and
legal echo mail distribution topologies, i.e. dup-rings, as well
as with some pre-requisite knowledge of zones, 4D and 2D addresses,
and the "sticky" 2D notation in PATH and SEEN-BY lines.
PATH: path lines as specified in FTS-0004
FSB: full seen-by informations as specified in FTS-0004
TSB: tiny seen-by informations as mentioned in FTS-0004, see below
RSB: reduced seen-by informations specified below
dupe: multiple arrival of the same echo mail (e.g. different paths)
Examples of echo mail distribution topologies
---------------------------------------------
In all examples a) to d) echo mail entered at system 1 is sent to
systems 2 and 3 with FSB 1 2 3. Therefore system 2 (3) knows, that
system 3 (2) already got this mail, topology a) is perfectly legal.
a) 1 - 3 b) 1 - 3 c) 1 - 3 d) 1 - 2
| / | | | / | | X |
2 2 - 4 2 - 4 2 - 4
In the exanmples b) and c) both systems 2 and 3 forward all mails
from system 1 to system 4, these topologies contain a dup-ring and
are therefore illegal following FTS-0004.
The examples a) and d) show fully connected polygons with three or
four nodes. In example d) a mail entered at system 1 is sent to
systems 2, 3, and 4 with FSB 1 2 3 4. The topologies a) and d) are
perfectly legal, there are no dupes caused by distribution.
In example b) each mail entered at system 1 reaching system 4 via
system 2 carries FSB 1 2 3 4, therefore system 4 will not forward
such mails to 3. Using TSB at system 2 the same mails would carry
TSB 2 4, therefore system 4 would forward them to 3 as dupes.
Note that illegal topologies as in example b) and c) cause dupes
with either FSB or TSB. The real problem with TSB is example b),
as it allows for loop mails on the dup-ring 1 - 2 - 3 - 4 - ...
and vice versa, if no additional checks for dupes are employed.
With RSB (specified below) systems contained in the PATH are not
stripped from the seen-by informations, therefore RSB avoid loop
mail much like FSB.
FSB algorithm
-------------
1) add own system to the PATH.
2) all area links not contained in the FSB qualify as recipients.
3) add own address(es) to the FSB set if not already contained.
4) add recipients to FSB, sort FSB, forward mail to recipients.
TSB algorithm
-------------
1) add own system to the PATH.
2) all area links not contained in the TSB qualify as recipients.
3) strip old TSB and start new TSB with own address(es).
4) add recipients to TSB, sort TSB and forward mail to recipients.
RSB algorithm
-------------
1) add own system to the PATH.
2) all area links not contained in the RSB qualify as recipients.
3) strip RSB addresses not matching an address in the PATH, then
add own address(es) to the RSB set if not already contained.
4) add recipients to RSB, sort RSB and forward mail to recipients.
PATH considerations
-------------------
There are 2 problems with the PATH kludge as specified in FTS-0004:
First like in the FSB the addresses in the PATH are 2D, and having
the same 2D address in different zones is possible. Therefore zone
gates are required to use the TSB algorithm. Unfortunately the PATH
is forwarded without regarding zone gating, therefore detection of
loop mail based solely on the PATH could be erroneous.
Further FTS-0004 (written 1989) expects future echo mail tossers to
implement PATH support, but doesn't require this support from old
implementations. Strictly spoken the PATH is still only an option.
In some areas of FidoNet (e.g. in zone 2) at least all non-terminal
nodes are required to fully support the PATH line, therefore this
problem will probably not show up in praxis. Of course any tosser
implementing the RSB feature is required to fully support the PATH.
Summary
-------
To show the benfits of RSB compared with FSB assume the following:
An echo mail travels from node to echo hub, host, major star, echo
host, hub, and finally arrives at a recipient. Each routing system
has 10 links, i.e. FSB at the recipient contain 51 addresses, about
400 characters, but RSB only 15 addresses in about 150 characters.
Therefore in an echo mail with 2500 characters about 10 % of its
size can be reduced using RSB in favour of FSB. If this estimation
is applicable on world wide FidoNet echo mail traffic, RSB can save
us an immense amount of costs.
This document can be adopted by the FTSC as FTS, in this case it
has to be regarded as an addition to FTS-0004 with the extension,
that all non-terminal nodes are required to support PATH lines as
specified in FTS-0004.
For additional informations (e.g. aspects of zone gating) feel free
to send mails to Frank Ellermann 2:240/5815 or leo@bfispc.hanse.de
- eof -
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

141
html/ftsc/fsp-1002.html
View File

@ -1,141 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Numeric reply indication in FTN subject lines.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1002
Revision: 2
Title: Numeric reply indication in FTN subject lines
Author: Odinn Sorensen, 2:236/77
Revision Date: 19 October 1997
Expiry Date: 11 October 1999
----------------------------------------------------------------------
Contents:
1. Scope
2. Format
3. Reply procedure
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
When making a reply to a message, there are currently three common
ways to handle the subject line:
1. Don't change it.
2. Insert the string "Re: " in front of it.
3. Insert the string "Re^n: " in front of it, where 'n' is increased
by one if the original subject was already a reply.
This document concerns itself with specifying the third variant.
1. Scope
--------
This standard is specified for all FTN messages. Implementations
will typically be message editors and other software that creates
replies to messages.
2. Format
---------
The format is "Re^n: ", where n is an unsigned integer number with
one or more digits. The range of the number must be at least 0 to
255. Negative numbers are not allowed. Note that there must be a
space after the colon. The letters are not case sensitive, but
uppercase 'R' and lowercase 'e' is recommended.
3. Reply procedure
------------------
When making a reply that conforms to this specification, this
procedure, or a functionally identical one, must be followed:
1. If the original subject does not have a leading "Re: " or
"Re^n: ", put the string "Re: " in front of it. Don't use a
number here.
Example: "Hello world" -&gt; "Re: Hello world"
2. If the original subject has a leading "Re: ", put the string
"Re^2: " in front of the subject.
Example: "Re: Hello world" -&gt; "Re^2: Hello world"
3. If the original subject has a leading "Re^n: ", increase the
number 'n' by one and modify the subject accordingly.
Example: "Re^4: Hello world" -&gt; "Re^5: Hello world"
Notes:
* The numbers 0 and 1 should not occur in the "Re^n: " string under
normal circumstances, but a robust implementation should just
increase the number in any case.
* The number should not be increased beyond the range of the number
type used in the implementation, or in other words, it should not
roll around to zero. If it can't be increased, leave it alone.
* When inserting the "Re: " or "Re^n: " string in front of the
subject, information from the end might be lost, because the
message storage or packet formats use fixed length subject fields.
Intelligent subject-based reply linking software should be aware
of this and try to link correctly anyway.
A. Author contact data
----------------------
Odinn Sorensen
Fidonet: 2:236/77
E-mail: odinn@goldware.dk
WWW: http://www.goldware.dk
B. History
----------
Rev.1, 971011: First release.
Rev.2, 971019: Added note that "Re" is not case sensitive.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

1757
html/ftsc/fsp-1011.html
View File

File diff suppressed because it is too large Load Diff

269
html/ftsc/fta-1005.html
View File

@ -1,269 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>FTSC Product ID List.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FTA-1005
Revision: 3
Title: FTSC Product Codes
Author: Administrator
Revision Date: 22 March 1998
Expiry Date: 22 March 1998
----------------------------------------------------------------------
Contents:
1. Format of product code list
2. Application for a product code
----------------------------------------------------------------------
1. Format of product code list
------------------------------
The FTSC publishes a list of all product codes issued. The filename
is FTSCPROD.nnn, where nnn is a number which increases with each
revision.
The list is an ASCII text file with one line per product. Each line
contains a number of fields, delimited by commas. Some fields may
contain more than one value. In this case, the different values are
delimited with a forward slash ('/'). Spaces in fields are replaced
with underscores ('_'). Fields are not case-sensitive.
These are the fields which are currently defined:
code,name,platform,type,contact,netaddr[,assigned[,updated]]
code The product code. 4 digits hexadecimal.
name Product name.
platform Platforms(s) supported.
type Type(s) of product.
contact Name of contact person.
netaddr FidoNet address of contact person.
assigned Date the product code was originally assigned.
updated Date of last update of the product code data.
Platforms
---------
See the list for examples. (Will be specified more firmly later).
Product types
-------------
Mailer A mailer is a product that exchanges mail with FTS-0001,
FTS-0006, EMSI or other protocols that include a product
code field.
Packer A packer is a product that creates .PKT files.
Dates
-----
The format is YYYYMMDD. A date field may also be blank.
If you write software which is dependant on this format, please make
it tolerant of additional fields after these for upwards
compatibility.
2. Application for a product code
---------------------------------
FidoNet products without an allocated product code which either
create Type-2 packets, or negotiate FTS-0001 sessions must use a
product code FEh (254d) in Type-2 compatible packet headers. This
code as been reserved for that purpose (use by product without a
product code). The product code FFh (255d) has been reserved to
indicate that the product code is stored elsewhere in the packet
header at an as yet unallocated offset.
The FTSC is currently working on an update to the Type-2 packet
specification, to allow 16-bit codes while keeping full backward
compatibility with 8-bit codes (something which the current Type-2
proposals in the FSC's are not). Until the specification is ready,
16-bit codes are issued with the low byte set to FFh (255d).
Below is an application form for an FTSC product code, which is used
to identify your product when used in FidoNet, and providing a means
by which you can be contacted should your product be found
responsible for problems encountered during its use. The issuance of
this product code in no way implies authorisation or approval of
your product for use on the network, only provides a means of ready
identification.
This application should be completed and submitted for only `real'
and completed products which will be used by FidoNet systems. If you
are currently developing a product which is not yet ready for use on
the network out of experimental stage, use product code 0 (zero)
which is, by convention, reserved for this purpose.
Please answer the questions as accurately and completely as
possible. We need to know what will actually be used on the net, so
describe only the current product, and leave future features and
plans for the comments section.
Send the completed form to the administrator of the FidoNet
Technical Standards Committee. Please see FTA-1003 for addresses.
We hope that you will take the time to revise your answers by
submitting updates as your product changes. A summary of the
information you provide is compiled into a list of all product codes
published and updated periodically by the FTSC called
"FTSCPROD.nnn".
A. Application Form
-------------------
--- Cut along here ---------------------------------------------------
FTSC Product Code Application
=============================
Type of application
-------------------
1. Mark whichever is appropriate:
____ New product application
____ Update existing product for existing product code ____
2. If this is an update, please briefly state the nature of the
update (change author's node number, change of product name, etc.)
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
Product information
-------------------
3. What is the name of the product and the current version name or
number?
__________________________________________________________________
4. What is the name, FidoNet node, and postal address, and voice
number of the person(s) or organization responsible for the
product? Where should inquiries be directed and who should be
contacted if the product is thought to cause errors on the
network?
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
5. What operating systems does it currently run on?
__________________________________________________________________
6. Does the product contain a 'mailer'? E.g. the package transmits
mail to other FidoNet systems and can fall back to FTS-0001,
though it may handle other protocols.
__________________________________________________________________
7. If the answer to question (6) is yes, what additional protocols
other than FTS-0001 does the product support? Refer to the
specific FTSC document which details this protocol, if any.
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
With what additions or restrictions?
__________________________________________________________________
8. Is the package capable of servicing file requests, and if so,
'Bark' style (FTS-0008) and/or WaZOO .REQ (FTS-0006) or both?
__________________________________________________________________
With what additions or restrictions?
__________________________________________________________________
9. Is your software capable of functioning as a Continuous Mail
system? i.e. nodes running it might be marked as such in the
FidoNet nodelist?
__________________________________________________________________
10. How is the product distributed?
Public Domain ____________ Shareware ______________
Commercial ____________ Other ______________
Object code ____________ Source code ______________
Comments: ________________________________________________________
__________________________________________________________________
__________________________________________________________________
11. Please give additional comments to describe your product.
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
--- Cut along here ---------------------------------------------------
B. Acknowledgements
-------------------
The application form was inspired by one originally published in
FSC-0022 and later FSC-0090, originally by Bob Hartman, Jim Long,
and Randy Bush and modified by Rick Moore and David Nugent.
C. History
----------
Rev.1, 19970407: First non-draft release. Author Adrian Walker.
Rev.2, 19971229: Author changed to Administrator. Reformatted
document slightly. Changed all dates in the lists
to 4 digit centuries. Added information about
status of 16-bit product codes.
Rev.3, 19980322: Moved the product code list out of the document and
into a separate list, FTSCPROD.nnn. Added an
application form. Revised text about 16 bit codes.
**********************************************************************
</PRE>
<A HREF="./"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

1261
html/ftsc/fts-0001.html
View File

File diff suppressed because it is too large Load Diff

415
html/ftsc/fts-0004.html
View File

@ -1,415 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Echomail Specification.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
FTS-0004 EchoMail Specification
This document is directly derived from the documentation of
-------------------------------------------------------------------------------
The Conference Mail System
By
Bob Hartman
Sysop of FidoNet(tm) node 132/101
(C) Copyright 1986,87, Spark Software, Inc.
427-3 Amherst Street
CS 2032, Suite 232
Nashua, N.H. 03061
ALL RIGHTS RESERVED.
-------------------------------------------------------------------------------
version 3.31 of 12 December, 1987.
With Bob Hartman's kind consent, copying for the purpose of technological
research and advancement is allowed.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
WHAT IS THE CONFERENCE MAIL SYSTEM?
Conference Mail is a technique to permit several nodes on a
network to share a message base, similar in concept to the
conferences available on many of the computer services, but it is
most closely related to the Usenet system consisting of more than
8,000 systems world wide. All systems sharing a given conference
see any messages entered into the conference by any of the
participating systems. This can be implemented in such a way as
to be totally transparent to the users of a particular node. In
fact, they may not even be aware of the network being used to
move their messages about from node to node! Unfortunately, this
has its disadvantages also - most users who are not educated
about Conference Mail do not realize the messages transmitted
cost MANY sysops (system operators) money, not just the local
sysop. This is an important consideration in Conference Mail and
should not be taken lightly. In a conference with 100 systems as
participants the cost per message can get quite high.
The Conference Mail System is designed to operate in conjunction
with a FidoNet compatible mail server. The currently supported
mail servers are Fido(tm), SEAdog(tm), Opus, and Dutchie. Since
the mail server is a prerequisite to using the Conference Mail
System, it will be assumed you already have your mail server
operating correctly on your system, and you are connected into
FidoNet or a compatible network.
HISTORY OF THE CONFERENCE MAIL SYSTEM
In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a
convenient means of sharing ideas with the other Dallas sysops.
He created a system of programs he called Echomail, and the
Dallas sysops' Conference was born.
Within a short time sysops in other areas began hearing of this
marvelous new gadget and Echomail took on a life of its own.
Today, a scant year and a half later, the FidoNet public network
boasts a myriad of conferences varying in size from the dozen-or-
so participants in the FidoNet Technical Standards Committee
Conference to the Sysops' Conference with several hundred
participants. It is not uncommon for a node to carry 30 or more
conferences and share those conferences with 10 or more nodes.
HOW IT WORKS
The Conference Mail System is functionally compatible with the
original Echomail utilities. In general, the process is:
1. A message is entered into a designated area on a FidoNet
compatible system.
2. This message is "Exported" along with some control information
to each system "linked" to the conference through the originating
system.
3. Each of the receiving systems "Import" the message into the
proper Conference Mail area.
4. The receiving systems then "Export" these messages, along with
additional control information, to each of their conference
links.
5. Return to step 3.
As you can see, the method is quite simple - in general. Of
course, following the steps literally would mean messages would
never stop being Exported and transmitted to other systems. This
obviously would not be desired or the network would quickly
become overburdened. The information contained in the 'control
information' section is used to prevent transmitting the same
message more than once to a single system.
CONFERENCE MAIL MESSAGE CONTROL INFORMATION
There are five pieces of control information associated with a
Conference Mail message. Some are optional, some are not.
Normally this information is never entered by the person creating
the message. The following control fields determine how
Conference Mail is handled:
1. Area line
This is the first line of a conference mail message. Its
actual appearance is:
AREA:CONFERENCE
Where CONFERENCE is the name of the conference. This line is
added when a conference is being "Exported" to another
system. It is based upon information found in the AREAS.BBS
(configuration) File for the designated message area. This
field is REQUIRED by the receiving system to "Import" a
message into the correct Conference Mail area.
2. Tear Line
This line is near the end of a message and consists of three
dashes (---) followed by an optional program specifier.
This is used to show the first program used to add Echomail
compatible control information to the message. The tear line
generated by Conference Mail looks like:
--- &lt;a small product-specific banner&gt;
This field is optional for most Echomail compatible
processors, and is added by the Conference Mail System to
ensure complete compatibility. Some systems will place this
line in the message when it is first created, but it is
normally added when the message is first "exported."
3. Origin line
This line appears near the bottom of a message and gives a
small amount of information about the system where it
originated. It looks like:
* Origin: The Conference Mail BBS (1:132/101)
The " * Origin: " part of the line is a constant field.
This is followed by the name of the system as taken from the
AREAS.BBS file or a file named ORIGIN located in the DOS
directory of the designated message area. The complete
network address (1:132/101 in this case) is added by the
program inserting the line. This field is generated at the
same time as the tear line, and therefore may either be
generated at the time of creation or during the first
"export" processing. Although the Origin line is not
required by all Echomail processors, it is added by the
Conference Mail System to ensure complete compatibility.
4. Seen-by Lines
There can be many seen-by lines at the end of Conference
Mail messages, and they are the real "meat" of the control
information. They are used to determine the systems to
receive the exported messages. The format of the line is:
SEEN-BY: 132/101 113 136/601 1014/1
The net/node numbers correspond to the net/node numbers of
the systems having already received the message. In this way
a message is never sent to a system twice. In a conference
with many participants the number of seen-by lines can be
very large. This line is added if it is not already a part
of the message, or added to if it already exists, each time
a message is exported to other systems. This is a REQUIRED
field, and Conference Mail will not function correctly if
this field is not put in place by other Echomail compatible
programs.
5. PATH Lines
These are the last lines in a Conference Mail message and
are a new addition, and therefore is not supported by all
Echomail processors. It appears as follows:
^aPATH: 132/101 1014/1
Where the ^a stands for Control-A (ASCII character 1) and
the net/nodes listed correspond to those systems having
processed the message before it reached the current system.
This is not the same as the seen-by lines, because those
lines list all systems the message has been sent to, while
the path line contains all systems having actually processed
the message. This is not a required field, and few echomail
processors currently support it, however it can be used
safely with any other system, since the line(s) will be
ignored. For a discussion on how the path line can be
helpful, see the "Advanced Features" section of this manual.
METHODS OF SENDING CONFERENCE MAIL
To this point the issue of how Conference Mail is actually sent
has been glossed over entirely. The phrase has been, "the message
is exported to another system." What exactly does this mean?
Well, for starters lets show what is called the "basic" setup:
In this setup exported mail is placed into the FidoNet mail area.
Each message exported from a Conference Mail area has one
message generated for each receiving system. This mail is then
sent the same as any other network mail. When Echomail was first
created this was the only way mail could be sent.
The "basic" method has some disadvantages. First, since Echomail
has grown so large it is not uncommon to get 200 new messages per
day imported into various message bases. It is also not uncommon
for a system to be exporting messages to 4 or 5 other systems.
Simple arithmetic shows 800-1000 messages per day would be sent
in normal netmail! This puts a tremendous strain on any netmail
system, not to mention transmission time and the resultant phone
charges. When this limitation of Echomail was first noticed a lot
of people started scratching their heads wondering what to do. If
a solution could not be found it appeared Echomail would
certainly overrun the capabilities of FidoNet.
Thom Henderson (from System Enhancement Associates) came up with
the original ARCmail program. Having previously written the ARC
file archiving and compression program, he knew the savings
achievable by having all of the netmail messages placed in .ARC
format for transmission. As a byproduct, the messages no longer
appeared in the netmail area, but were included in a file
attached to a message (see your FidoNet mailer manual for file
attaches). In this way the tremendous number of messages
generated, and the phone bill problems were both solved.
Unfortunately, ARCmail required the messages to first be placed
into the netmail area before it could be run. In effect, it
caused the messages to be scanned once when they were exported,
once during the ARCmail phase, once when ARCmail was run at the
other end to get the messages out of .ARC format, and once when
those messages were later imported into a message base on the
receiving system. The Conference Mail System solves this problem
by eliminating the ARCmail program. Conference Mail builds the
ARCmail files during Export, and unpacks them during Import. This
way messages are exported directly to ARCmail style file
attaches, and imported directly from ARCmail style file attaches.
The scanning phases between importing and exporting messages are
totally removed and processing time is proportionally reduced.
This is now the most common method for sending Conference Mail
between systems. The overhead involved in doing it during the
importing and exporting phases is much less than what is involved
if ARCmailing is not utilized. This was a primary consideration
in the design and implementation of the Conference Mail System,
and as a result the entire system is optimized for this type of
use. Please refer to the Import and Export functions for
specifics on how to use the ARCmailing feature.
CONFERENCE TOPOLOGY
The way in which systems link together for a particular
conference is called the "conference topology." It is important
to know this structure for two reasons: 1) It is important to
have a topology which is efficient in the transfer of the
Conference Mail messages, and 2) It is important to have a
topology which will not cause systems to see the same messages
more than once.
Efficiency can be measured in a number of ways; least time
involved for all systems to receive a message, least cost for all
systems to receive a message, and fewest phone calls required for
all systems to receive a message are all valid indicators of
efficiency. Users of Echomail compatible systems have determined
(through trial and error) the best measure of efficiency is a
combination of all three of the measurements given above.
Balancing the equation is not trivial, but some guidelines can be
given:
1. Never have two systems attempting to send Conference mail
to each other at the same time. This results in "collisions"
that will cause both systems to fail. To avoid this, one
system should be responsible for polling while the other
system is holding mail. This arrangement can alternate based
upon various criteria, but both systems should never be
attempting to call each other at the same time.
2. Have nodes form "stars" for distribution of Conference
Mail. This arrangement has several nodes all receiving their
Conference Mail from the same system. In general the systems
on the "outside" of the star poll the system on the
"inside". The system on the "inside" in turn polls other
systems to receive the Conference Mail that is being passed
on to the "outside" systems.
3. Utilize fully connected polygons with a few vertices.
Nodes can be connected in a triangle (A sends to B and C, B
sends to A and C, C sends to A and B) or a fully connected
square (all corners of the square send to all of the other
corners). This method is useful for getting Conference Mail
messages to each node as quickly as possible.
All of these efficiency guidelines have to be tempered with the
guidelines dealing with keeping duplicate messages from being
exported. Duplicates will occur in any topology that forms a
closed polygon that is not fully connected. Take for example the
following configuration:
A ----- B
| |
| |
C ----- D
This square is a closed polygon that is not fully connected. It
is capable of generating duplicates as follows:
1. A message is entered on node A.
2. Node A exports the message to node B and node C placing
the seen-by for A, B, and C in the message as it does so.
3. Node B sees that node D is not listed in the seen-by and
exports the message to node D.
4. Node C sees that node D is not listed in the seen-by and
exports the message to node D.
At this point node D has received the same message twice - a
duplicate was generated. Normally a "dup-ring" will not be as
simple as a square. Generally it will be caused by a system on
one end of a long chain accidentally connecting to a system on
the other end of the chain. This causes the two ends of the chain
to become connected, forming a polygon.
In FidoNet this problem is reduced somewhat by having "Regional
Echomail Coordinators" (RECS) that try to keep track of Echomail
connections within their regions of the world. A further rule
which is followed is that only the RECS are allowed to make
inter-regional connections for the larger conferences. In return,
the RECS have established a very efficient topology which gets
messages from coast to coast, and onto over 200 systems in less
than 24 hours. If no one were willing to follow the rules, then
this system would collapse, but due to the excellent efficiency
it has remained intact for over a year.
Why a PATH line?
As was previously mentioned, the PATH line is a new concept in
Echomail. It stores the net/node numbers of each system having
actually processed a message. This information is useful in
correcting the biggest problem encountered by nodes running an
Echomail compatible system - the problem of finding the cause of
duplicate messages. How does the PATH line help solve this
problem? Take the following path line as an example:
^aPATH: 107/6 107/312 132/101
This shows the message was processed by system 107/6 and
transferred to system 107/312. It further shows system 107/312
transferred the message to 132/101, and 132/101 processed it
again. Now take the following path line as the example:
^aPATH: 107/6 107/312 107/528 107/312 132/101
This shows the message having been processed by node 107/312 on
more than one occasion. Based upon the earlier description of the
'information control' fields in Echomail messages, this clearly
is an error in processing (see the section entitled "How it
Works"). This further shows node 107/528 as the node which
apparently processed the message incorrectly. In this case the
path line can be used to quickly locate the source of duplicate
messages.
In a conference with many participants it becomes almost
impossible to determine the exact topology used. In these cases
the use of the path line can help a coordinator of the conference
track any possible breakdowns in the overall topology, while not
substantially increasing the amount of information transmitted.
Having this small amount of information added to the end of each
message pays for itself very quickly when it can be used to help
detect a topology problem causing duplicate messages to be
transmitted to each system.
-30-
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

618
html/ftsc/fts-0005.html
View File

@ -1,618 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>The Distribution Nodelist.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FTS-0005
| Version: 003
| Date: February 7, 1996
| Maintainer: David Nugent, 3:632/348@fidonet
The Distribution Nodelist
Originally by Ben Baker
Amended by Rick Moore, 1:115/333@FidoNet, February 5, 1989
Amended by David Nugent, 3:632/348@FidoNet, February 27, 1996
| Copyright 1986-1996 by the FidoNet Technical Standards Committee.
All rights reserved. Duplication and/or distribution permitted
for non-commercial purposes only.
This document supersedes and replaces the document known under
| the names of FSC002, FSC-0002, and FTS-0002. Significant changes,
| which excludes mere formatting changes, to the previous version
| of this document have been "redlined" (marked with a vertical
| bar in the leftmost column).
This document defines the format and content of the nodelist for
the Public FidoNet Network (PFN) as published on Friday of each
| week. This format is historically known as the "St. Louis nodelist
| format".
The PFN is an international network of independently owned
electronic mail systems, most with interlocking electronic
bulletin board systems. The distribution nodelist, or simply
"nodelist", is the glue which holds the network together. It is
the PFN's "phone book" and it defines the top-level network
| structure and is the means by which FidoNet retains its integrity
| as a point-to-point mail network.
| THE NODELIST
The nodelist is published as an ASCII text file named
NODELIST.nnn, where nnn is a three digit number representing the
| day-of-year of the Friday publication date, with zeros filling
| positions to the left if necessary. This file is packed into a
| archive file named NODELIST.?nn, where 'nn' are the last two
| digits of day-of-year, and the character at the position of the
| '?' indicating the type of compression used. Conventions as to
| which compression method is used for the distributed nodelist is
| a matter of local policy and is usually determined by each zone's
| Zone Coordinator.
As stated above, NODELIST.nnn is an ASCII text file. It contains
two kinds of lines; comment lines and data lines. Each line is
terminated with an ASCII carriage return and line feed character
sequence, and contains no trailing white-space (spaces, tabs,
| etc.). The file is terminated with a DOS end-of-file character
| (character value 26 decimal, or "control-Z").
Comment lines contain a semicolon (;) in the first character
position followed by zero or more alphabetic characters called
"interest flags". A program which processes the nodelist may use
comment interest flags to determine the disposition of a comment
line. The remainder of a comment line (with one exception,
| treated below) is free-form ASCII text. There are five types of
| comments flags:
| ;S This is of particular interest to Sysops
| ;U This is of particular interest to BBS users
| ;F This should appear in any formatted "Fido List"
| ;A This is of general interest (shorthand for ;SUF)
| ;E This is an error message inserted by the nodelist generator
| ; This comment may be ignored by a nodelist processor
The first line of a nodelist is a special comment line containing
identification data for the particular edition of the nodelist.
The following is an example of the first line of a nodelist:
;A FidoNet Nodelist for Friday, July 3, 1987 -- Day number 184 : 15943
This line contains the general interest flag, the day, date, and
| three-digit (zero-filled) day-of-year number of publication, and
ends with a 5 digit decimal number with leading zeros, if
necessary. This number is the decimal representation of a check
value derived as follows:
Beginning with the first character of the second line, a
16 bit cyclic redundancy check (CRC) is calculated for the
entire file, including carriage return and line feed
characters, but not including the terminating EOF
character. The check polynomial used is the same one used
for many file transfer protocols:
2**16 + 2**12 + 2**5 + 2**0
The CRC may be used to verify that the file has not been edited.
The importance of this will become evident in the discussion of
NODEDIFF, below. CRC calculation techniques are well documented
| in various technical references, and will not be treated further
here.
The content of the remaining comments in the nodelist are
intended to be informative. Beyond the use of interest flags for
distribution, a processing program need not have any interest in
them.
A nodelist data line contains eight variable length "fields"
separated by commas (,). No space characters are allowed in a
data line, and underscore characters are used in lieu of spaces.
The term "alphanumeric character" is defined as the portion of
the ASCII character set from 20 hex through 7E hex, inclusive.
The following discussion defines the contents of each field in a
data line.
Field 1: Keyword
The keyword field may be empty, or may contain one of the
following:
Zone
Begins the definition of a geographic zone and define its
coordinator. All the data lines following a line with the
"Zone" keyword down to, but not including, the next
occurrence of a "Zone" keyword, are regions, networks, and
| nodes within the defined zone. Node entries defined
| immediately after the "Zone" keyword and before the next
| region or host entry are known as zone adminstrative nodes.
| These are allocated by the Zone Coordinator for use by nodes
| in the entire zone; for example, mail gateways between
| FidoNet zones.
Region
Begins the definition of a geographic region and defines
its coordinator. All the data lines following a line with
the "Region" keyword down to, but not including, the
next occurrence of a "Zone", "Region", or "Host"
keyword, are independent nodes within the defined region.
Host
Begins the definition of a local network and defines its
| network coordinator. All the data lines following a line
with the Host keyword down to, but not including, the
next occurrence of a "Zone", "Region", or "Host" keyword,
are local nodes, members of the defined local network.
Hub
Begins the definition of a routing sub-unit within a
multi-level local network. The hub is the routing focal
point for nodes listed below it until the next occurrence
of a "Zone", "Region", "Host", or "Hub" keyword. The hub
entry MUST be a redundant entry, with a unique number, for
one of the nodes listed below it, within its hub segment.
This is necessary because some nodelist processors
eliminate these entries in all but the local network.
Pvt
Defines a private node with unlisted number. Private nodes
are only allowed as members of local networks.
Hold
Defines a node which is temporarily down. Mail may be sent
to it and is held by its host or coordinator.
Down
Defines a node which is not operational. Mail may NOT be
sent to it. This keyword may not be used for longer than
two weeks on any single node, at which point the "down"
node is to be removed from the nodelist.
<empty>
| The field contains no text (not the sequence "<empty>"),
| and defines a normal node entry.
| Only one of these may be used in any individual data line.
Field 2: Zone/Region/Net/Node number
This field contains only numeric digits and is a number in the
range of 0 to 32767. If the line had the "Zone", "Region", or
"Host" keyword, the number is the zone, net, or region number,
and the node has an implied node number of 0. Otherwise, the
number is the node number. The zone number, region or net number,
and the node number, taken together, constitute a node's FidoNet
address.
Zone numbers must be unique. Region or net numbers must be unique
within their zone, hub numbers unique be within their net, node
| numbers unique within their net (and region, for regional
| independent nodes, zone for zone administrative entries). Duplicate
node numbers under different hubs within the same net are not
allowed.
Field 3: Node name
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces, and
a comma delimits the end of the field. This is the name by which
the node is known, usually as determined by the node or the
coordinator responsible for compiling the segment.
Field 4: Location
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces. This
field contains the location of the node. It is usually expressed
as the primary local location (town, suburb, city, etc.) plus the
identifier of the regional geopolitical administrative district
(state, province, department, county, etc.). Wherever possible,
standard postal abbreviations for the major regional district
should be used (IL, BC, NSW, etc.).
Field 5: Sysop name
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces. This
is the name of the system operator.
Field 6: Phone number
This field contains at least three and usually four numeric
sub-fields separated by dashes (-). The fields are country code,
city or area code, exchange code, and number. The various parts
of the phone number are frequently used to derive cost and
routing information, as well as what number is to be dialed. A
typical example of the data in a phone number field is
1-800-555-1212, corresponding to country 1 (USA), area 800
(inbound WATS), exchange 555, and number 1212.
Alternatively, this field may contain the notation
"-Unpublished-" in the case of a private node. In this case, the
| keyword "Pvt" must appear at the start of the line.
Field 7: Baud rate
This field contains one of the values: 300, 1200, 2400, 9600,
| 19200, or 38400.
| This baud rate is indicative only of the maximum baud rate that
| may be expected when connecting to a node and is generally of use
| only where a calling node needs to adjust the baud rate used to
| dial to the caller's modem speed in order to achieve a
| connection, a requirement that with modem technology available in
| 1996 is rarely if ever needed. This information is largely
| superseded by modem protocol flags (see next section) where any
| two nodes using a common protocol may have other expectations
| with regards to actual transfer rates. Use of the baud rate field
| alone is therefore depreciated.
Field 8 - Flags
This optional field contains data about the specific operation of
the node, such as file requests, modem protocol supported, etc.
Any text following the seventh comma on a data line is taken
collectively to be the flags field. The required format is zero
or more sub-fields, separated by commas. Each sub-field consists
of a flag, possibly followed by a value.
The following flags define special operating conditions:
Flag Meaning
CM Node accepts mail 24 hours a day
MO Node does not accept human callers
| LO Node accepts calls only from valid listed node
| numbers in the current FidoNet nodelist
The following flags define modem protocols supported:
Flag Meaning
| V21 ITU-T V21 300 bps full duplex
| V22 ITU-T V22 1200 bps full duplex
| V29 ITU-T V29 9600 bps half duplex
| V32 ITU-T V32 9600 bps full duplex
| V32b ITU-T V32bis 14400 bps full duplex
| V33 ITU-T V33
| V34 ITU-T V34 28800 bps full duplex
H96 Hayes V9600
HST USR Courier HST up to 9600
| H14 USR Courier HST up to 14400
| H16 USR Courier HST up to 16800
MAX Microcom AX/96xx series
PEP Packet Ensemble Protocol
| CSP Compucom Speedmodem
| ZYX Zyxel series
| VFC V.Fast Class
| V32T V.32 Terbo
NOTE: Many V22 modems also support Bell 212A.
If no modem flag is given, Bell 212A is assumed for 1200 bps
systems, ITU-T V22bis is assumed for 2400 bps systems.
The following flags define type of error correction available. A
separate error correction flag should not be used when the error
correction type can be determined by the modem flag. For
| instance, a modem flag of HST implies MNP, V32b implies V32 and
| V42b implies V42. Therefore MNP+HST, H14+MNP, H16+MNP, V32+V32b
| and V42+V42b flag pairs are redundant and should not be used.
Flag Meaning
MNP Microcom Networking Protocol error correction
| V42 ITU-T LAP-M error correction w/fallback to MNP 1-4
| V42b ITU-T LAP-M error correction w/fallback to MNP 1-5
The following flags define the type(s) of compression of mail
packets supported.
Flag Meaning
MN No compression supported
| NOTE: While FidoNet nodes usually exchange mail
| using a variety of different file compression
| formats negotiated between individual systems, the
| presence of this flag indicates the INABILITY TO
| RECEIVE MAIL compressed using the SEA ARC version 5
| compression format and/or named according to the
| ARCmail 0.6 mail bundle naming method. This is, by
| convention, the most common mail compression format
| in use within FidoNet. The presence of this flag
| would normally indicate that all mail should be sent
| uncompressed unless there is some overriding
| arrangement with the receiving system.
The following flags indicate the types of file and file update
requests supported.
Flag Meaning
XA Bark and WaZOO file/update requests
XB Bark file/update requests, WaZOO file requests
| XC Bark file requests, WaZOO file file/update
XP Bark file/update requests
XR Bark and WaZOO file requests
XW WaZOO file requests
| XX WaZOO file/update requests
The following flag defines gateways to other domains (mail
networks).
Flag Meaning
Gx..x Gateway to domain 'x..x', where 'x..x` is a string
of alphanumeric characters.
NOTE: Valid values for 'x..x' are assigned by the FidoNet
| International Coordinator or the person appointed as
| Internetworking Coordinator by the FidoNet
| International Coordinator. Current valid values of
'x..x' may usually be found in the notes at the end
| of the current FidoNet nodelist. The most common
| gateway flag is "GUUCP", to denote a gateway to the
| Internet mail system that gates on behalf of the
| fidonet.org internet domain.
The following flags define the dedicated mail periods supported.
They have the form "#nn" or "!nn" where nn is the UTC hour the mail
period begins, '#' indicates Bell 212A compatibility, and '!'
indicates incompatibility with Bell 212A.
Flag Meaning
| #01 Zone 5 mail hour (01:00 - 02:00 UTC)
#02 Zone 2 mail hour (02:30 - 03:30 UTC)
| #03 Zone 4 mail hour (08:00 - 09:00 UTC)
#09 Zone 1 mail hour (09:00 - 10:00 UTC)
#18 Zone 3 mail hour (18:00 - 19:00 UTC)
| #20 Zone 6 mail hour (20:00 - 21:00 UTC)
NOTE: When applicable, the mail period flags may be strung
together with no intervening commas, e.g.. "#02#09"
| or "!02!09". Only mail hours other than that
standard within a node's zone should be given. Since
observance of mail hour within one's zone is
mandatory, it should not be indicated.
The following flag defines user-specific values. If present,
this flag MUST be the last flag present in a nodelist entry.
Flag Meaning
Ux..x A user-specified string, which may contain any
alphanumeric character except blanks. This string
may contain one to thirty-two characters of
information that may be used to add user-defined
data to a specific nodelist entry.
| NOTE: Ux..x flags are the mechanism by which new flags may
| be experimentally introduced into the nodelist for a
| trial period to assess their worth. They are
| therefore of a temporary nature, and after their
| introduction they are eventually either promoted
| to a non-U flag or dropped from use altogether.
The FTSC recognizes that the FidoNet International Coordinator is
the ultimate authority over what appears in the FidoNet nodelist.
Also, FTSC is by definition a deliberative body, and adding or
changing a flag may take a considerable amount of time.
Therefore, the FidoNet International Coordinator may temporarily
make changes or additions to the flags as defined in this
document. The FidoNet International Coordinator will then consult
with FTSC over the changes needed to this document to reflect
these temporary changes.
The following are examples of nodelist data lines:
Host,102,SOCALNET,Los_Angeles_CA,Richard_Martz,1-213-874-9484,2400,XP
,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,
| THE NODEDIFF
| With more than thirty-five thousand nodes as of this date (1996),
| the nodelist, even in archive form, is a document of substantial
| size. Since distribution of the nodelist occurs via electronic
file transfer, this file is NOT routinely distributed. Instead,
| when a new nodelist is prepared weekly, it is compared with the
previous week's nodelist, and a file containing only the
differences is created and distributed.
| The distribution difference file, called NODEDIFF.nnn, where nnn
is the day-of-year of publication, is actually an editing script
which will transform the previous week's nodelist into the
current nodelist. A definition of its format follows:
The first line of NODEDIFF.nnn is an exact copy of the first line
| of LAST WEEK'S nodelist (i.e. the first line of the nodelist to
| which the current difference file applies). This is used as a
first-level confidence check to insure that the correct file is
being edited. The second and subsequent lines are editing
commands and data.
There are three editing commands and all have the same format:
&lt;command&gt;&lt;number&gt;
&lt;command&gt; is a 1 letter command, one of A, C, or D.
&lt;number&gt; is a decimal number greater than zero, and defines the
number of lines to be operated on by the command. Each command
appears on a line by itself. The commands have the following
meanings:
Ann Add the following nn lines to the output file.
Cnn Copy nn unchanged lines from the input to the output
file.
Dnn Delete (or skip) nn lines from the input file.
The following illustrate how the first few lines of a
| hypothetical NODEDIFF.213 might look:
;A Friday, July 25, 1986 -- Day number 206 : 27712
D2
A2
;A Friday, August 1, 1986 -- Day number 213 : 05060
;A
C5
This fragment illustrates all three editing commands. The first
line is the first line from the previous nodelist, NODELIST.206.
The next line says "delete the first two lines" from
NODELIST.206. These are the identification line and the line
following it. The next command says "add the next two lines" to
NODELIST.213 at the "current" location. The two data lines are
followed by a command which says "copy five unchanged lines" from
NODELIST.206 to NODELIST.213. Notice that the first line added
| will ALWAYS contain the new nodelist CRC, so that the software
| applying the changes to the old nodelist may check the result of
| its editing.
Since only the differences will be distributed, it is important
to insure the accuracy of the newly created nodelist. This is the
function of the CRC mentioned above. It is sufficient for a
program designed to perform the above edits to pick the CRC value
from the first line added to the output file, then compute the
CRC of the rest of the output file. If the two CRCs do not agree,
one of the input files has been corrupted. If they do agree, the
probability is very high (but not 100%) that the output file is
accurate.
For actual distribution, NODEDIFF.nnn is packed into an archive
| file named NODEDIFF.?nn, where 'nn' are the last two digits of
| day-of-year, and '?' indicates the compression format used.
| NODELIST COMPILATION
| This section is included for tutorial reasons and is not intended
| as a definition of any specific method by which FidoNet MUST
| compile its weekly nodelist. It merely represents an attempt to
| document the method by which it currently does so. It is intended
| to be explanatory, and seeks to answer commonly asked questions,
| such as how the nodelist is compiled and where the information
| comes from, why the nodelists used in different FidoNet zones are
| not the same document, and why the difference file generated for
| use in one FidoNet zone cannot be applied to the nodelist
| generated for use in a different zone, even though the week
| numbers match.
| Nodelists are compiled via a distributed method, which follows
| the same structure as the FidoNet coordinator hierarchy. At the
| lowest level, network coordinators maintain a list of the nodes
| in their network and are responsible for the addition, removal
| and correction of individual node's listings in their "segment"
| (as portions of the full nodelist are called). In some larger
| networks, it is common for this job to be shared with hub
| coordinators appointed by the net coordinator, though the
| responsibility for those hub segments still remains with the
| network coordinator.
| At a nominated day during the week, before the regional level
| segment is submitted to the zone coordinator, individual net
| coordinators submit their segments to the regional coordinator
| who subsequently compiles these segments and transmits the merged
| copy to the zone coordinator. These are combined by the zone
| coordinator with the separate segments of other zones and
| compiled into that zone's version of the world nodelist. This
| world nodelist is then compared with the previous week's version,
| a difference file is generated and subsequently distributed
| throughout the zone.
| In some cases, in the interest of saving in transmission times
| and therefore costs, the compilation process itself may be better
| served by the submission of DIFFERENCE FILES rather than full
| net- or region-level segments. Each coordinator therefore retains
| a copy of the previously submitted segments and applies
| difference files to those to derive the new one. This process is
| exactly identical to the NODEDIFF/NODELIST scenario described
| earlier in this document, with the same first line and CRC
| validation method used to guard the integrity of the nodelist
| segments.
| For a number of reasons, it is important that publication of the
| nodelist be as timely as possible. These reasons include: the
| nodelist is a definitive list of valid FidoNet addresses that may
| receive mail, and must therefore be as correct and up-to-date as
| possible to save nodes the unnecessary expense of mail routed to
| possibly non-existing addresses; the nodelist contains the list
| of telephone numbers that may be called by any user of the
| FidoNet nodelist and should therefore be accurate so as not to
| unduly annoy owners of those phone numbers should a listed node
| go down and an unsuspecting telephone subscriber inherit the same
| telephone number.
| Given this constraint, the expense of international calls and the
| fact that FidoNet is a worldwide network that exists in many time
| zones, it may be unreasonable to expect the compilation of the
| nodelist to be delayed until each zone coordinator can transmit
| their most up-to-date zone segment to a central authority for
| compilation and subsequent redistribution in any week. For the
| sake of expedience, each zone instead maintains its own separate
| world nodelist which contains a compilation of the current zone's
| latest segments and including the most current copy to hand of
| all other FidoNet zone's segments. The zone level nodelist
| generated each week by each zone coordinator is then transmitted
| to all other zone coordinators for inclusion into their separate
| world nodelist as timing permits.
| In theory, then, the only difference between nodelists
| distributed in each zone in any week are accounted for by timing
| differences in the exchange of each zone's separate segment. In
| practice, other constraints may interfere with timeliness, such
| as the difficulty and expense of international telephonic
| communications. Also, another point of variance is introduced by
| the fact that each zone usually includes its own zone segment
| first into its world nodelist to assist - amongst other things -
| software that uses the nodelist for index generation. Some
| software in common use in FidoNet indexes the nodelist according
| to its sequential order (e.g. version 5 and 6 compiled nodelist
| formats), and including the current zone first before others will
| have a beneficial effect on software performance.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

871
html/ftsc/fts-0006.html
View File

@ -1,871 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>YOOHOO and YOOHOO/2U2.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FTS-0006
Version: 002
Date: 30-Nov-1991
YOOHOO and YOOHOO/2U2
The netmail handshake used by Opus-CBCS
and other intelligent Fidonet mail handling packages
Vince Perriello
FidoNet 1:2343/491
Status of this document:
This FTS (FidoNet(r) Technical Standard) specifies an optional
standard for the FidoNet community. Implementation of the
protocols defined in this document is not mandatory, but all
implementations of these protocols are expected to adhere to this
standard. Distribution of this document is subject to the
restrictions listed below.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software
LEGAL STUFF
-----------
The original protocol and documentation are by Wynn Wagner III. Updates
have been made to this document by Vince Perriello, who also is
responsible for most of the sample routine included with this document.
They are released to the public for any use whatsoever as long as you
don't modify any transmitted structure or try to make money hawking
either the sample code or this document as if you owned them.
If you choose to use the method or the sample routines, you do so
entirely at your own risk. It is possible that the routines will cause
physical damage to your equipment, an invasion of fire ants, the plague,
or an extended visit from in-laws. If any of that stuff (or anything
else) happens, you accept the consequences totally.
CREDITS
-------
Fido and Fidonet are registered trademarks of Tom Jennings and Fido
Software.
ARCmail was originated by System Enhancement Associates.
The ZModem protocol was designed by Chuck Forsberg. The SEAlink / SEAlink
Overdrive protocols are copyrighted by System Enhancment Associates. The
TeLink protocol was designed and first implemented by Tom Jennings.
The state charts in this document were done by Vince Perriello.
Rick Huebner designed and implemented the basic WaZOO file request
method. Update request functionality was added by Vince Perriello. Bob
Hartman is responsible for the addition of Domain support.
FTS-0001, describing the base FidoNet protocol, was created by Randy Bush.
FTS-0007, describing enhancement to FTS-0001 using SEAlink and/or SEAlink
Overdrive, was created by Phil Becker.
YooHoo and YooHoo/2u2 Page 2
Overview
UPFRONT
-------
YOOHOO and YOOHOO/2U2 are the initial handshakes for the WaZOO e-mail
protocol. They are designed to let two systems establish a common ground
for a netmail session while making sure that non-WaZOO software doesn't
get upset by material it can't understand.
The YOOHOO procedure begins as a single byte (0xf1). If the system on
the other end doesn't reply to that byte, no further YOOHOO or WaZOO
transmissions are attempted. To a non-WaZOO netmail system, the YOOHOO
byte will simply seem like a byte of debris.
The calling system initiates the YOOHOO by sending the attention
character. If the receiving system seems interested, the calling system
sends a 128 byte packet containing such information as system and sysop
names as well as a "capability mask." A 16-bit CRC protects the integrity
of the 128-byte packet.
In response, the receiving system prepares a 128 byte packet to send
back. This is the YOOHOO/2U2 procedure.
FEATURES
--------
The features of YOOHOO and YOOHOO/2U2 include
* non-interference with systems that don't understand the
handshake
* almost foolproof method for identifying a remote system
and establishing a common ground for transmission
* built-in room to expand the capabilities of WaZOO without
having to resort to a kludge
USAGE
-----
A calling system simply uses a routine that transmits both YooHoo and
TSYNC handshake initiating characters to the called system. If the
called system responds with an XMODEM 'NAK', an FTS-0001 session will be
initiated. If an 'ENQ' is received, the `YooHoo_Sender()' routine will
be invoked to handle the session negotiation.
A receiving system can call a routine like `YooHoo_Receiver()' if it
detects the YOOHOO character, or just drop into the FTS-0001 logic if it
sees a TSYNC.
This simple method allows a mailer to take care of both the TSYNC and the
YOOHOO handshakes.
YooHoo and YooHoo/2u2 Page 3
WaZOO Protocols
PROTOCOLS
---------
Currently there are four WaZOO methods in use:
1. ZedZap
------
a Zmodem variant. The originator does a batch send then goes into a
receive batch mode. The called system does receive then send. In
the event of a file request (see description below) made by the
called system, one more turnaround is made to service the request.
* Unlike the "True" Zmodem protocol described by Chuck Forsberg,
ZedZap routines must be able to handle a batch mode that has no
actual files. In other words, it is possible for there to be a
init sequence followed immediately by a ZFIN.
* The maximum packet size is 8192. This is usually varied based on
the baud rate. For example, at 2400 it might be 2048 bytes, then
for 9600 baud and above the maximum of 8192 could apply. Note that
THIS IS A SIGNIFICANT VARIATION FROM STRICT ZMODEM IMPLEMENTATION.
(There's another WaZOO capability bit for those systems which
can not handle this block size)
* Netmail packets are transmitted as files with names in the form
"12345678.PKT". Because of this, multiple packets may be sent in
a single session.
* If the calling system transmits a .REQ file for file requests, the
receiving system can respond to it. See "WaZOO File Requests"
(below) for information on the .REQ file.
2. ZedZip
------
This capability is identical to ZedZap, but does not use buffers
greater than 1K in size (like "True" Zmodem). It is also
permissible to send a "null" packet in a ZedZip session. This
allows a system which must use a strict Zmodem implementation to
participate in a WaZOO session using Zmodem.
3. DietIFNA
--------
The session operates like FTS-0001/FTS-0007. The notable exceptions
are as follows:
* The same packet naming convention as ZedZap applies, allowing more
than one packet to be transmitted in a single session.
YooHoo and YooHoo/2u2 Page 4
WaZOO Protocols
* Telink file transfers don't even attempt to exchange file names
using modem7. The receiving system extracts the file name from the
Telink or SEAlink header block.
* If SEAlink is used, run-ahead (the number of blocks to slide) is
based on the baud rate: BlocksToSlide = BaudRate / 400, up to a
max of 24 blocks.
* When there is nothing to send, a system should remain quiet. In
other words, the end of a session can be determined by a timeout.
* Under no circumstances should "BARK" file request logic be active
during a DietIFNA session. File requests, if any, should be
transmitted using a .REQ file.
Many implementations of DietIfna have been accomplished by the mere
exchange of packets, followed by straight FTS-0001/0007 code. This
is incorrect but probably not easily remedied at this point. We have
made an effort to document this change in "reality" in this revision
of the document.
4. Janus
-----
Janus is a full-duplex simultaneous bidirectional file transfer
protocol. In other words, it can send and receive files at the same
time. It's very loosely derived from ZModem and HDLC/X.25 protocol
technology, in that it uses variable length data-typed packets, and
that transmission of file data does not require ACKs.
The protocol is documented elsewhere; it is beyond the scope of this
document to do so.
YooHoo and YooHoo/2u2 Page 5
Choosing WaZOO Methods
How to decide which WaZOO method to use
---------------------------------------
Since the called system has all the information necessary to decide what
WaZOO method to employ, the best way to implement the process is for the
calling system to send, in its capability mask, all the bits which
correspond to methods it can use (or wants to use) in communicating with
the called system. The called system then looks at these bits and sends
back only the bit which corresponds to the method it wants to use.
If the called system sends back a mask which contains more than one
capability of the calling system, it can create a problem situation if
one system arrives at its choice of methods differently from the other.
Thus, when the called system doesn't make the choice, both systems should
choose as follows:
1. Janus
2. ZedZap
3. ZedZip
4. DietIFNA
The capability highest on the list which both systems indicate ability to
execute should be the one employed.
YooHoo and YooHoo/2u2 Page 6
WaZOO Filename conventions
WaZOO FILENAMES
---------------
1. MESSAGE PACKETS ... xxxxxxxx.PKT
Normal (unarchived) messages are sent in a file name that has a tag
of .PKT. The "x" characters should be hex digits.
2. ARCmail ... xxxxxxxx.{MO|TU|WE|TH|FR|SA|SU}#
Message packets are often shipped in an archive that has been
compressed with some LZ utility.
The file name consists of a name with hex digits. The tag is one of
seven two-character prefixes ("MO", "TU", "WE", "TH", "FR", "SA" or
"SU") and a number (0-9).
This particular naming convention was established by ARCmail version
0.60, which is a defacto standard in FidoNet.
3. FILE REQUESTS ... xxxxxxxx.REQ
This is explained below.
In a nutshell, the file name consists of the receiving system's
Fidonet address expressed as two 4-digit hex numbers. The file tag
is .REQ.
In a Janus session, the .REQ file isn't actually sent. Janus has
a transaction system which sends the .REQ file one line at a time
and then accepts the file(s) which the request generates.
YooHoo and YooHoo/2u2 Page 7
Flow of a ZedZap or ZedZip Session
FLOW OF A ZEDZAP OR ZEDZIP SESSION
----------------------------------
The calling system:
* Send YooHoo
* Receive YooHoo/2u2
* In a single batch, send bundles, files, file request (.REQ) files
(in that order)
* In a single batch, receive bundles, files, file requests, and
requested files (in that order)
* If a file request (.REQ) file came in, send all requested files
in a single batch.
Receiving system:
* Receive YooHoo
* Send YooHoo/2u2
* In a single batch, receive bundles, files, file requests
* In a single batch, send bundles, files, our file requests, and
respond to file requests that arrived from the remote system.
* If we sent a .REQ file in the preceding step, receive all files
in a single batch.
YooHoo and YooHoo/2u2 Page 8
WaZOO File Requests
WAZOO FILE REQUESTS
-------------------
Rick Huebner, who adapted the ZModem routines for Opus, and the architect of
the Janus file transfer protocol, designed the ".REQ file"-based file request
system.
REQ FILE:
A WaZOO file request is based on a request file. The name of a request file
is similar to the .OUT and .FLO files used by Opus-CBCS and similar mail
products (such as BinkleyTerm).
TEMPLATE: netnode.REQ
EXAMPLE: 00010002.REQ ... a request being sent to 1/2
The .REQ file is simply a text file that contains the files we want from the
remote system. Those file names can include wildcards, but should not contain
a path. Optionally, there can be a password if the sending system requires one.
The "netnode" part of the file name is built from the remote systems net and
node numbers. Both numbers become 4-character hex numbers in the file name.
Let's say we're requesting THIS.ARC and all node lists from 12/2. The file
name would be 000C0002.REQ. The contents would look like this:
this.arc
nodelist.*
If the sysop of 12/2 requires a password of THAT to get the file THIS.ARC, the
REQ file contents would have to change:
this.arc !that
nodelist.*
Transaction-level passwords (of 6 or fewer characters) follow the file name:
&lt;filename&gt;&lt;single-space-character&gt;!&lt;password&gt;&lt;cr&gt;
YooHoo and YooHoo/2u2 Page 9
WaZOO File Requests
If the request is of the "update" genre, the type of update and the time,
expressed as a UNIX-style long decimal ASCII number, follows the name, or in
the event that there is a transaction-level password, the password. For
example, an update request for file NEWOPUS.*, where you already have a file
dated 1-January 1989, 00:00 and you live on the East Coast (GMT+06) would be:
NEWOPUS.* +599634000
The sign is required, it indicates the type of update request. A '+' means
that all files matching the filespec "NEWOPUS.*" newer than the shown time
will be sent, a '-' means that all matching files with dates up to and
including the indicated time will be sent.
The complete format of an action line in an REQ file is, then:
&lt;filename&gt;[&lt;space&gt;!&lt;password&gt;][&lt;space&gt;&lt;+/-&gt;&lt;time&gt;]&lt;cr&gt;
MECHANISM:
In a ZedZap or DietIfna session, the .REQ file is simply transmitted to the
other system. It goes "as is" like any other file. In a Janus session, the
.REQ file will be sent one line at a time and individually serviced by the
other end.
The other system can ignore the request, send some of the files, or send all
of the files. There is no accounting or responsibilities on the part of the
remote system.
If your implementation is unable to process the update information for any
reason, then you should process the line as a "regular" file request.
NOTE:
In the YooHoo packet, there's a bit that lets you know if the remote system
currently accepts .REQ files. This will be a clue as to whether a .REQ file
would be a waste of time or not. Procedurally, you just should not send a .REQ
file to a system which indicates that it won't process it.
YooHoo and YooHoo/2u2 Page 10
Structures and Definitions
STRUCTURES AND DECLARATIONS
---------------------------
#define ACK 0x06
#define NAK 0x15
#define ENQ 0x05
#define YOOHOO 0xf1
#define TSYNC 0xae
struct _Hello
{
word signal; /* always 'o' (0x6f) */
word hello_version; /* currently 1 (0x01) */
word product; /* product code */
word product_maj; /* major revision of the product */
word product_min; /* minor revision of the product */
char my_name[60]; /* Other end's name, will include domain */
/* if DO_DOMAIN is set in capabilities mask*/
char sysop[20]; /* sysop's name */
word my_zone; /* 0== not supported */
word my_net; /* out primary net number */
word my_node; /* our primary node number */
word my_point; /* 0 == not supported */
byte my_password[8]; /* This is not necessarily null-terminated */
byte reserved2[8]; /* reserved by Opus */
word capabilities; /* see below */
byte reserved3[12]; /* for non-Opus systems with "approval" */
}; /* total size 128 bytes */
/*------------------------------------------------------------------------*/
/* YOOHOO&lt;tm&gt; CAPABILITY VALUES */
/*------------------------------------------------------------------------*/
#define Y_DIETIFNA 0x0001 /* Can do fast "FTS-0001" 0000 0000 0000 0001 */
#define FTB_USER 0x0002 /* Reserved by Opus-CBCS 0000 0000 0000 0010 */
#define ZED_ZIPPER 0x0004 /* Does ZModem, 1K blocks 0000 0000 0000 0100 */
#define ZED_ZAPPER 0x0008 /* Can do ZModem variant 0000 0000 0000 1000 */
#define DOES_IANUS 0x0010 /* Can do Janus 0000 0000 0001 0000 */
#define Bit_5 0x0020 /* reserved by FTSC 0000 0000 0010 0000 */
#define Bit_6 0x0040 /* reserved by FTSC 0000 0000 0100 0000 */
#define Bit_7 0x0080 /* reserved by FTSC 0000 0000 1000 0000 */
#define Bit_8 0x0100 /* reserved by FTSC 0000 0001 0000 0000 */
#define Bit_9 0x0200 /* reserved by FTSC 0000 0010 0000 0000 */
#define Bit_a 0x0400 /* reserved by FTSC 0000 0100 0000 0000 */
#define Bit_b 0x0800 /* reserved by FTSC 0000 1000 0000 0000 */
#define Bit_c 0x1000 /* reserved by FTSC 0001 0000 0000 0000 */
#define Bit_d 0x2000 /* reserved by FTSC 0010 0000 0000 0000 */
#define DO_DOMAIN 0x4000 /* Packet contains domain 0100 0000 0000 0000 */
#define WZ_FREQ 0x8000 /* WZ file req. ok 1000 0000 0000 0000 */
YooHoo and YooHoo/2u2 Page 11
Domain addressing in Hello Packet
Since the invention of the WaZOO handshake, nearly every change in the
FidoNet transport has been accessible by defining bits for new protocols,
using the point number field in the structure, etc.
With the advent of Domain addressing in FidoNet, this was no longer the
case. There was no place set aside in the hello packet where domain info
could be passed from one system to another.
We have addressed this requirement by using some of the space set aside
in the system name field for the domain. It is backward-compatible with
all systems which determine the end of a string by use of a null.
WaZOO systems that support domains communicate that fact by setting the
DO_DOMAIN bit (hex 2000) in the capabilities mask. This tells the other
side that they can expect to find a domain address in the packet.
The domain name is stored at the end of the 'my_name' field. It is stored
in its entirety (no abbreviations as in FSC-0045) after the system name.
If the length of the system name plus the null terminator plus the length
of the domain name plus terminator exceeds 60, the system name will be
truncated (right to left) to make it fit.
So, for a system named "FUBAR" at address 1:234/567@fidonet.org, the
address and name fields in the header would look like this:
hello.my_zone = 1
hello.my_net = 234
hello.my_node = 567
hello.my_point = 0
hello.my_name = 'F','U','B','A','R', 0, 'f','i','d','o','n','e','t',
'.','o','r','g',0
hello.capabilities will contain the usual capabilities plus DO_DOMAIN.
A remote system receiving this packet should look past the null in
my_name to get the domain name.
YooHoo and YooHoo/2u2 Page 12
Caller State Tables
Calling System:
The parts of FTS-0001 and FTS-0007 which deal with synchronization of calling
and called system must be modified to deal with the reception and processing
of the YooHoo character and exchange of Hello packets. The following state
table may be used to initiate an FTS-0001 or a WaZOO session by the calling
system. It replaces state S3 in the FTS-0001 table.
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| SS0 | SyncInit | | Prepare 3 sec Sync timer| |
| | | | Prepare .5 sec NAK tmr | |
| | | | Init NAK Count | |
| | | | Start 60 sec master tmr | SS1 |
|-----+----------+-------------------------+-------------------------+-----|
| SS1 | SendSync | 1. Over 60 seconds | | |
| | | or carrier lost | no response | exit|
| | +-------------------------+-------------------------+-----|
| | | 2. 3 sec elapsed | Clear Inbound buffer | |
| | | or timer not started | Send YOOHOO, then TSYNC | |
| | | | Start 3 sec Sync timer | SS2 |
| | +-------------------------+-------------------------+-----|
| | | 3. not elapsed | | SS2 |
|-----+----------+-------------------------+-------------------------+-----|
| SS2 | WaitResp | 1. Nothing received | require a response | SS1 |
| | +-------------------------+-------------------------+-----|
| | | 2. ENQ received | WaZOO Protocol selected | exit|
| | +-------------------------+-------------------------+-----|
| | | 3. 'C' received | probable FTS-0001 | SS3 |
| | +-------------------------+-------------------------+-----|
| | | 4. NAK received | probable FTS-0001 | SS3 |
| | +-------------------------+-------------------------+-----|
| | | 5. Debris (might include| Reset NAK timer | |
| | | (YOOHOO|TSYNC) &amp; 127)| if started | SS1 |
|-----+----------+-------------------------+-------------------------+-----|
| SS3 | NAKTmr | 1. Timer not expired | Zero NAK count | |
| | | or timer not started | Start .5 sec NAK timer | SS1 |
| | +-------------------------+-------------------------+-----|
| | | 2. Timer expired | Bump NAK count | SS4 |
|-----+----------+-------------------------+-------------------------+-----|
| SS4 | NAKCount | 1. Count &gt;= 2? | assume FTS-0001 | exit|
| | +-------------------------+-------------------------+-----|
| | | 2. Count &lt; 2 | Keep looking | SS1 |
`-----+----------+-------------------------+-------------------------+-----'
YooHoo and YooHoo/2u2 Page 13
Caller State Tables
Calling System (continued):
The FTS-0001 exits from the above table should operate using the FTS-0001
state tables, starting at state S4. The "WaZOO detected" case should proceed
using the following state table:
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| YS1 | SndHello | Successful | Looks like WaZOO | YS2 |
| | (state +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | SH1) | Not successful | Repeat whole thing | exit|
|-----+----------+-------------------------+-------------------------+-----|
| YS2 | WaitResp | 30 sec timer expires | repeat whole thing | exit|
| | | or lost carrier | | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received YOOHOO | Another WaZOO, go | YS3 |
| | | | process receive | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received debris | Repeat whole thing | YS2 |
|-----+----------+-------------------------+-------------------------+-----|
| YS3 | GetHello | Information | Report Success | exit|
| | (state | Successfully | | |
| | RH1) | Exchanged | | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Failure | Repeat whole thing | exit|
`-----+----------+-------------------------+-------------------------+-----'
The failure cases in this table may be retried. The retry should be from
the point of synchronization. This means redoing the process in the SendSync
table on Page 11. A really smart mailer could therefore do a YooHoo, exchange
information, decide that it doesn't want to do WaZOO, fail out, and attempt
an FTS-0001 session.
If the packet exchange is successful, session method selection proceeds and
then the chosen session method should be employed to exchange mail and files.
YooHoo and YooHoo/2u2 Page 14
Called System State Tables
The following state table may be used to initiate an FTS-0001 or a WaZOO
session by the called system. It replaces states R1 and R2 in the FTS-0001
table.
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| RS0 | SyncInit | | Start 5 second idle tmr | RS1 |
|-----+----------+-------------------------+-------------------------+-----|
| RS1 | IdleWait | 1. 5 sec tmr expired | Take the initiative | RS2 |
| | +-------------------------+-------------------------+-----|
| | | 2. Carrier lost | Session aborted | exit|
| | +-------------------------+-------------------------+-----|
| | | 3. Peek = YOOHOO | Looks like a live WaZOO | RS3 |
| | +-------------------------+-------------------------+-----|
| | | 4. Peek = TSYNC | Live FTS-0001, we think | RS3 |
| | +-------------------------+-------------------------+-----|
| | | 5. Peek = CR, LF, space | He looks alive | RS2 |
| | +-------------------------+-------------------------+-----|
| | | 6. Other character | Eat it | RS1 |
|-----+----------+-------------------------+-------------------------+-----|
| RS2 |SendBanner| 1. Error returned | Session aborted | exit|
| | +-------------------------+-------------------------+-----|
| | | 2. Banner sent OK | | RS3 |
|-----+----------+-------------------------+-------------------------+-----|
| RS3 |RecvInit | | Start 20 sec timer | RS4 |
| | | | Init 10 sec timer | |
|-----+----------+-------------------------+-------------------------+-----|
| RS4 |SendSync | 1. Error returned | Session aborted | exit|
| |(xmit sync+-------------------------+-------------------------+-----|
| |string) | 2. String sent OK | Watch for sender sync | RS5 |
|-----+----------+-------------------------+-------------------------+-----|
| RS5 | WaitSync | 1. Carrier lost | Session aborted | exit|
| | +-------------------------+-------------------------+-----|
| | | 2. YOOHOO received | WaZOO session selected | exit|
| | +-------------------------+-------------------------+-----|
| | | 3. TSYNC received | probable FTS-0001 | RS6 |
| | +-------------------------+-------------------------+-----|
| | | 4. CR received | Still sync'ing | RS4 |
| | +-------------------------+-------------------------+-----|
| | | 5. Other character rcvd | Get next input character| RS5 |
| | +-------------------------+-------------------------+-----|
| | | 6. 10 sec timer elapsed | FTS-0001 selected | exit|
| | +-------------------------+-------------------------+-----|
| | | 7. 20 sec timer elapsed | Not a mail session | exit|
|-----+----------+-------------------------+-------------------------+-----|
| RS6 | TsyncTmr | 1. Timer not running | Start 10 second timer | RS5 |
| | | | Reset 20 sec timer | |
| | +-------------------------+-------------------------+-----|
| | | 2. Timer running | Two TSYNCS = FTS-0001 | exit|
`-----+----------+-------------------------+-------------------------+-----'
YooHoo and YooHoo/2u2 Page 15
Called System State Tables
The FTS-0001 exits from the above table should operate using the FTS-0001
state tables, starting at state R3. The "WaZOO detected" case should proceed
using the following state table:
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| YR1 | GetHello | Information | Start 20 sec timer | YR2 |
| | (state | Successfully | Initialize retry count | |
| | RH1) | Exchanged | Send YooHoo | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Failure | Repeat whole thing | exit|
|-----+----------+-------------------------+-------------------------+-----|
| YR2 | WaitResp | 20 sec timeout | try again | YR3 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Lost carrier | Failure | exit|
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received ENQ | Go send hello | YR4 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received debris | Keep looking | YR2 |
|-----+----------+-------------------------+-------------------------+-----|
| YR3 | PollPeer | More than 3 retries | Give it up | exit|
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Less than 3 retries | Bump retry count | YR2 |
| | | | Clear input buffer | |
| | | | Send YOOHOO | |
| | | | Restart 20 sec timer | |
|-----+----------+-------------------------+-------------------------+-----|
| YR4 | SndHello | Successful | All done, report success| exit|
| | (state +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | SH1) | Not successful | Repeat whole thing | exit|
`-----+----------+-------------------------+-------------------------+-----'
The failure cases in states YR1, YR3 and YR4 of this table may be retried.
The retry should be from the point of synchronization. This means redoing the
process in the RecvSync table on Page 13, beginning at state RS3. A really
smart mailer could therefore do a YooHoo, exchange information, decide that
it doesn't want to (or cannot) do a WaZOO session, fail out, and attempt
an FTS-0001 session.
If the packet exchange is successful, session method selection proceeds and
then the chosen session method should be employed to exchange mail and files.
YooHoo and YooHoo/2u2 Page 16
Packet Exchange State Tables
The following state table describes the transmission of the "Hello" packet
from one system to its partner:
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| SH1 | InitSend | | Disable XON/XOFF | SH2 |
| | | | Set retry count to 0 | |
|-----+----------+-------------------------+-------------------------+-----|
| SH2 | SendHedr | | Send Hex 1f, then | SH3 |
| | | | Send HELLO struct | |
|-----+----------+-------------------------+-------------------------+-----|
| SH3 | SendCRC | | Clear Input Buffer | SH4 |
| | | | Send two-byte CRC of pkt| |
| | | | MSB followed by LSB | |
| | | | Start 40 second timer | |
|-----+----------+-------------------------+-------------------------+-----|
| SH4 | GetResp | 40 second timer expires | Failed to send packet | exit|
| | | or carrier lost | | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | ACK received | Successful transmission | exit|
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | '?' received | Error, try retransmit | SH2 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | ENQ received | Out of sync? | SH2 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | other character recvd | Debris, keep watching | SH4 |
`-----+----------+-------------------------+-------------------------+-----'
YooHoo and YooHoo/2u2 Page 17
Packet Exchange State Tables
The following state table describes the reception of the "Hello" packet sent
to a system by its partner:
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| RH1 | SendENQ | | Start 2 minute timer | RH2 |
| | | | Send an ENQ character | |
|-----+----------+-------------------------+-------------------------+-----|
| RH2 | WaitHedr | 2 minute timer expires | Report failure | exit|
| | | or carrier lost | | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received Hex 1f | Got header, get packet | RH5 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received other char | Debris, throw away | RH3 |
| | | | Start 10 sec timer | |
|-----+----------+-------------------------+-------------------------+-----|
| RH3 | TossJunk | 10 sec timer expires | Too much noise | RH4 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received Hex 1f | Got header, get packet | RH5 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Input buffer empty | Try to resynch | RH4 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Carrier lost | Report failure | exit|
|-----+----------+-------------------------+-------------------------+-----|
| RH4 | ReSynch | | Clear input buffer | RH2 |
| | | | Send ENQ | |
|-----+----------+-------------------------+-------------------------+-----|
| RH5 | HdrSetup | | Initialize CRC | |
| | | | Set 30 second timer | RH6 |
|-----+----------+-------------------------+-------------------------+-----|
| RH6 | GetHChar | 30 sec timer expires or | | |
| | | carrier lost | Report failure | exit|
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Character received | Process character | RH7 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | 10 seconds with no char | Error, try resync | RH9 |
|-----+----------+-------------------------+-------------------------+-----|
| RH7 | StoHChar | Buffer and CRC filled | Compare CRC | RH8 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | More characters needed | Reset 30 sec timer | RH6 |
|-----+----------+-------------------------+-------------------------+-----|
| RH8 | CheckCRC | CRC matches | Finish Receive | RH10|
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | CRC doesn't match | Handle error | RH9 |
|-----+----------+-------------------------+-------------------------+-----|
| RH9 | CountERR | Less than 10 errors | Send '?' (0x3f) | RH2 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | 10 errors | Hang up, report failure | exit|
|-----+----------+-------------------------+-------------------------+-----|
| RH10| HelloOK | | Clear inbound buffer | exit|
| | | | Send ACK | |
`-----+----------+-------------------------+-------------------------+-----'
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

1645
html/ftsc/fts-0007.html
View File

File diff suppressed because it is too large Load Diff

491
html/ftsc/fts-0008.html
View File

@ -1,491 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Bark file-request protocol extension.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FTS-0008
Version: 003
Date: 15-Oct-1990
Updates: FTS-0001
An Enhanced FidoNet(r) Technical Standard
Extending FTS-0001 to include Bark requests
October 15, 1990
Status of this document:
This document specifies an optional standard for the FidoNet community.
Implementation of the protocols defined in this document is not mandatory,
but all implementations of these protocols are expected to adhere to this
standard. Distribution of this document is subject to the limitations of
the copyright notice displayed below.
Copyright 1989-90 by Philip L. Becker. Portions of this document are
copyright 1986-90 by Randy Bush and are incorporated with his consent.
All rights reserved. A right to distribute only without modification and
only at no charge is granted. Under no circumstances is this document to
be reproduced or distributed as part of or packaged with any product or
other sales transaction for which any fee is charged. Any and all other
reproduction or excerpting requires the explicit written consent of the
copyright holders.
A. Introduction
1. This Document
This document describes the standard for "Bark" type FidoNet file
request operation. Bark file requests are an extension to the basic
FTS-0001 mail session, and this document presents these requests as a
modification to that document.
2. What are File Requests?
File Requests are a way of requesting that a specific file be sent during
a FidoNet mail session. This has many advantages over simply logging on to
a BBS and downloading a file:
o You need not be a validated user
o You don't have to spend time searching for the file on the BBS
o You can schedule the file request to take place at any time without
your being near your computer.
There are two commonly used types of file requests on FidoNet today, WaZOO
and Bark requests. WaZOO requests are used by Opus and BinkleyTerm, and
are not documented here. See the document FTS-0006 by V. Perriello for a
description of these. Bark requests were the first file request extension
to the FTS-0001 protocol, and are supported (at least partially) by many
mailers, including SEAdog, Dutchie, BinkleyTerm, and to a certain extent
Opus. This document describes how to implement Bark-type file requests.
B. Terms Used in this Document
1. The diagrams and notations used in this document are the same as those used
in the FTS-0001 document. Please see FTS-0001 for a description of these.
This document should be considered as an extension to the FTS-0001 session
layer protocol, and you will require FTS-0001 in addition to this document
to fully understand what is presented here.
In addition to the data description language described in FTS-0001 section
A.4, one extra terminal used in this notation:
(* terminals *)
someName&lt;max&gt; - String of up to max chars, NOT null terminated
C. Performing File Requests
1. Introduction
A Bark request consists of transmitting a special Bark Request packet which
contains a filename, a date (used for update requests), and optionally a
password. The system receiving the request then decides if it can send the
requested file or not, and if it can does so using the same protocol used
to send attached files. Bark request handling is always controlled by the
answering system, and consists of two phases. In phase one, the receiving
system asks the calling system to honor requests it may have to ask for
files from the caller. In phase two, the receiving system allows the
calling system to request files from it.
Update file requests are the same as normal file requests, with one
exception. If the date in the Bark Request packet (described below) is
greater than or equal to the date of the actual file requested, the file
will not be sent. The requestor should set the date to the date of the
the actual file on its own end if an update request is desired.
D. The Bark Request Packet
1. Data Link Layer Data Definition.
The Bark Request packet is a variable-sized packet containing a header, a
filename, a date (which is used only for update requests - in a normal file
request it's 0) and an optional password. When receiving a Bark Request
packet, the ETX may be used to determine the end of the data portion. Note
that the CRC is sent in the reverse byte order of a normal CRC XMODEM data
block (see FTS-0001 section G.1).
Note: some systems will send a password in the data block even if none is
needed. Incoming passwords should be ignored unless the other system is
trying to request a passworded file.
Bark File Request Packet
Offset
dec hex
.-----------------------------------------------.
0 0 | ACK - Start of Bark Request - 06H |
+-----------------------------------------------+
1 1 | Filename - Packed DOS file format |
+-----------------------------------------------+
n n | SPACE - 20H |
+-----------------------------------------------+
n n | Date (0 if not Update Request) |
+-----------------------------------------------+
n n | SPACE - 20H (only if pswd follows) |
+-----------------------------------------------+
n n | Password (optional) |
+-----------------------------------------------+
n n | ETX - End of RESYNC packet - 03H |
+-----------------------------------------------+
n n | (*1) CRC low order byte |
+-----------------------------------------------+
n n | (*1) CRC high order byte |
`-----------------------------------------------'
*1 - CRC does not include the ACK or ETX and is
in the reverse byte order from the CRC in a
normal XMODEM data packet.
2. Data Description Notation of Bark Request Packet
DataBlock (no password) = ACK
Filename&lt;12&gt;
Space
Date&lt;11&gt;
ETX
CRC
DataBlock (with password) = ACK
Filename&lt;12&gt;
Space
Date&lt;11&gt;
Space
Password&lt;6|8&gt;
ETX
CRC
ACK = 06H (* Header for file request block *)
Space = 20H (* Space character *)
ETX = 03H (* End of block *)
Filename (* Name of file requested *)
Date (* ASCII string; the number of seconds
since midnight, January 1, 1970 *)
Password (* The password needed to request this
file, if any. Maximum length is 6 for
BinkleyTerm and Opus, 8 for SEAdog
and Dutchie. *)
CRC = crc[2] (* CCITT Cyclic Redundancy Check. The
same algorithm as used for XModem
CRCs. The CRC is calculated on
all data in the block between but
not including the ACK and the ETX *)
E. Session Layer Protocol:
This section describes the modified FTS-0001 session layer protocol. This
is the only area of FTS-0001 which is modified to implement Bark style file
requests. File Requests are performed at the end of the normal FidoNet
mail session, after any mail pickup is performed.
The diagrams below desribe the session level protocol with Bark file
requests implemented. The state tables have been broken into subroutines
but the FTS-0001 portion is not functionally changed. FTS-0001 sender
states S4 through S7 are now table "Send Mail SM0". FTS-0001 receiver
states R3 through R6 are now table "Receive Mail RM0". They are not
functionally changed in any way from FTS-0001, they are just broken out
to allow them to be used as subroutines. Finally Sender states S0 through
S3 are unchanged, as are Receiver states R0 through R2.
The remaining FTS-0001 states are enhanced to implement the Bark file
request protocol. In addition, the subroutine state tables "Send Bark SB0"
and "Receive Bark RB0" have been added to handle the actual file requests.
The following diagrams fully replace the Session Layer protocol state
tables in FTS-0001. No other changes to FTS-0001 are required to implement
the Bark File request feature.
Sender (Top level)
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-------------------------+-------------------------+-----+
| S0 | SendInit | | dial modem | S1 |
+-----+----------+-+-----------------------+-------------------------+-----+
| S1 | WaitCxD |1| carrier detected | delay 1-5 seconds | S2 |
| | (*1) | | | Set SLO if &gt; 2400bps, | |
| | | | | Reset SLO if &lt;= 2400bps | |
| | +-+-----------------------+-------------------------+-----+
| | |2| busy, etc. | report no connection | exit|
| | +-+-----------------------+-------------------------+-----+
| | |3| voice | report no carrier | exit|
| | +-+-----------------------+-------------------------+-----+
| | |4| carrier not detected | report no connection | exit|
| | | | within 60 seconds | | |
+-----+----------+-+-----------------------+-------------------------+-----+
| S2 | WhackCRs |1| over 30 seconds | report no response &lt;cr&gt; | exit|
| | +-+-----------------------+-------------------------+-----+
| | |2| ?? &lt;cr&gt;s received | delay 1 sec | S3 |
| | +-+-----------------------+-------------------------+-----+
| | |3| &lt;cr&gt;s not received | send &lt;cr&gt; &lt;sp&gt; &lt;cr&gt; &lt;sp&gt;| S2 |
| | | | | delay ??? secs | |
+-----+----------+-+-----------------------+-------------------------+-----+
| S3 | WaitClear|1| no input for 0.5 secs | send TSYNCH = AEH | S4 |
| | +-+-----------------------+-------------------------+-----+
| | |2| over 60 seconds | hang up, report garbage | exit|
| | | | and line not clear | | |
+-----+----------+-+-----------------------+-------------------------+-----+
| S4 | SendMail | | (Send Mail SM0) | S5 |
+-----+----------+-+-----------------------+-------------------------+-----+
| S5 | TryPickup|1| Rcv TSYNC | (Receive Mail RM0) | S5 |
| | (*2) +-+-----------------------+-------------------------+-----+
| | |2| Rcv SYN | (Receive Bark Req RB0) | S5 |
| | +-+-----------------------+-------------------------+-----+
| | |3| Rcv ENQ | (Do Bark Requests SB0) | S5 |
| | +-+-----------------------+-------------------------+-----+
| | |4| Rcv 'C' or NAK | Send EOT | S5 |
| | +-+-----------------------+-------------------------+-----+
| | |5| Rcv Other Char | Send SUB | S5 |
| | +-+-----------------------+-------------------------+-----+
| | |6| No Data for 45 secs | Hang Up | exit|
`-----+----------+-+-----------------------+-------------------------+-----'
*1 - This state is shown for the extended SEAlink protocol. Omit the
set/reset SLO actions if adding Bark to a strict FTS-0001 protocol
implementation, or if not implementing overdrive in SEAdog.
*2 - To refuse to pickup mail (S5.1) may send a CAN and stay in (S5).
Note: Although the above shows the sender emitting only one TSYNCH, it is
recommended that a timeout of 5-20 seconds should initiate another TSYNCH.
The receiver should tolerate multiple TSYNCHs.
Receiver (Top Level)
The receiving FSM is given an external timer, the expiration of which
will cause termination with a result of 'no calls' (R0.2).
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-+-----------------------+-------------------------+-----+
| R0 | WaitCxD |1| carrier detected | | R1 |
| | +-+-----------------------+-------------------------+-----+
| | |2| external timer expires| report no calls | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| R1 | WaitBaud |1| baud rate detected | send signon with <cr>s | R2 |
| | +-+-----------------------+-------------------------+-----+
| | |2| no detect in ?? secs | hang up, report no baud | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| R2 | WaitTsync|1| TSYNCH received | ignore input not TSYNCH | R3 |
| | +-+-----------------------+-------------------------+-----+
| | |2| 60 seconds timeout | hang up, report not Fido| exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| R3 | RecMail | | (Receive Mail RM0) | R4 |
+-----+----------+-+-----------------------+-------------------------+-----+
| R4 | AllowPkup|1| Have pickup for sender| Send Tsync, | R5 |
| | | | | Set T1=1 sec | |
| | +-+-----------------------+-------------------------+-----+
| | |2| No pickup for sender | | R6 |
+-----+----------+-+-----------------------+-------------------------+-----+
| R5 | WtPickup |1| Rcv NAK or 'C' | (Send Mail SM0) | R6 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Rcv SUB | Send Tsync, | R5 |
| | | | | Set T1=1 sec | |
| | +-+-----------------------+-------------------------+-----+
| | |3| Rcv CAN | Report Mail Refused | R6 |
| | +-+-----------------------+-------------------------+-----+
| | |4| T1 expired | Send Tsync, | R5 |
| | | | | Set T1=1 sec | |
| | +-+-----------------------+-------------------------+-----+
| | |5| 45 secs in R5 | Hang Up, report error | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| R6 | AskBark |1| Wish to make requests | Send SYN | R7 |
| | (*1) +-+-----------------------+-------------------------+-----+
| | |2| No requests to make | | R8 |
+-----+----------+-+-----------------------+-------------------------+-----+
| R7 | DoRequest|1| Rcv CAN | Report Requests Refused | R8 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Rcv ENQ | (Send Bark SB0) | R8 |
| | +-+-----------------------+-------------------------+-----+
| | |3| Rcv SUB | Send SYN | R7 |
| | +-+-----------------------+-------------------------+-----+
| | |4| Rcv NAK or 'C' | Send EOT | R6 |
| | +-+-----------------------+-------------------------+-----+
| | |5| Rcv Other | eat character | R7 |
| | +-+-----------------------+-------------------------+-----+
| | |6| 5 sec, no input | Send SYN | R7 |
| | +-+-----------------------+-------------------------+-----+
| | |7| 45 secs in R7 | | R8 |
+-----+----------+-+-----------------------+-------------------------+-----+
| R8 | WtPickup |1| Allow File Request | (Receive Bark RB0), | exit|
| | | | | Hang Up | |
| | +-+-----------------------+-------------------------+-----+
| | |2| Disallow Requests | Hang Up | exit|
`-----+----------+-+-----------------------+-------------------------+-----'
*1 - Some implementations always do (R6.1) even if they have no requests.
Sender - Send Mail
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-------------------------+-------------------------+-----+
| SM0 | SendMail | | (XMODEM send packet XS0)| SM1 |
+-----+----------+-+-----------------------+-------------------------+-----+
| SM1 | CheckMail|1| XMODEM successful | (Fido registers success)| SM2 |
| | +-+-----------------------+-------------------------+-----+
| | |2| XMODEM fail or timeout| hang up, report mail bad| exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| SM2 | SendFiles| | (BATCH send files BS0) | SM3 |
+-----+----------+-+-----------------------+-------------------------+-----+
| SM3 | CheckFile|1| BATCH send successful | report success | exit|
| | +-+-----------------------+-------------------------+-----+
| | |2| BATCH send failed | hang up, rept files fail| exit|
`-----+----------+-+-----------------------+-------------------------+-----'
Sender - Send Bark
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-+-----------------------+-------------------------+-----+
| SB0 | SendBark |1| File to request | Build Bark Request Pkt, | SB1 |
| | | | | Set tries = 0 | |
| | +-+-----------------------+-------------------------+-----+
| | |2| No more files to req | Send ETB | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| SB1 | AskFile | | Send Bark Packet | SB2 |
+-----+----------+-+-----------------------+-------------------------+-----+
| SB2 | RcvFile |1| Rcv ACK | (Batch Receive BR0) | SB3 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Tries &gt; 5 | Send ETB, report failed | exit|
| | +-+-----------------------+-------------------------+-----+
| | |3| Rcv Other | Purge input, Incr tries | SB1 |
| | +-+-----------------------+-------------------------+-----+
| | |4| 10 sec w/o ACK | Incr tries | SB1 |
+-----+----------+-+-----------------------+-------------------------+-----+
| SB3 | NxtFile |1| Rcv ENQ | | SB0 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Rcv Other | Purge Input | SB3 |
| | +-+-----------------------+-------------------------+-----+
| | |3| 5 sec, no input | Send SUB | SB3 |
| | +-+-----------------------+-------------------------+-----+
| | |4| 45 sec in SB3 | Hang up, report error | exit|
`-----+----------+-+-----------------------+-------------------------+-----'
Sender &amp; Receiver - Receive Mail
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-------------------------+-------------------------+-----+
| RM0 | RecMail | | (XMODEM rec packet XR0) | RM1 |
+-----+----------+-+-----------------------+-------------------------+-----+
| RM1 | XRecEnd |1| XMODEM successful | delay 1 second | RM2 |
| | | | | flush input | |
| | +-+-----------------------+-------------------------+-----+
| | |2| XMODEM failed | hang up, rept mail fail | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| RM2 | RecFiles | | (BATCH rec files BR0) | RM3 |
+-----+----------+-+-----------------------+-------------------------+-----+
| RM3 | ChkFiles |1| BATCH recv successful | delay 2 secs, rprt good | exit|
| | +-+-----------------------+-------------------------+-----+
| | |2| BATCH recv failed | hang up, report bad file| exit|
`-----+----------+-+-----------------------+-------------------------+-----'
Sender &amp; Receiver - Receive Bark
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-+-----------------------+-------------------------+-----+
| RB0 | HonorReq |1| Ok to honor request | Purge Input, Send ENQ, | RB1 |
| | | | | Set T1 = 2 seconds | |
| | +-+-----------------------+-------------------------+-----+
| | |2| Don't wish to honor | Send CAN | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| RB1 | WaitBark |1| Got ACK | Rcv Bark Packet (*1) | RB2 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Got ETB | Report done | exit|
| | +-+-----------------------+-------------------------+-----+
| | |3| Got ENQ | Send ETB | RB0 |
| | +-+-----------------------+-------------------------+-----+
| | |4| T1 expired | Purge Input, Send ENQ, | RB1 |
| | | | | Set T1 = 2 seconds | |
| | +-+-----------------------+-------------------------+-----+
| | |5| 20 seconds in RB1 | Hang Up, Report error | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| RB2 | AckBark |1| Bark Pkt Rcvd Good | Send ACK | RB3 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Bark Pkt Rcv Error | Send NAK | RB1 |
+-----+----------+-+-----------------------+-------------------------+-----+
| RB3 | WaitStrt |1| Got 'C' or NAK | | RB4 |
| | +-+-----------------------+-------------------------+-----+
| | |2| No data for 3 seconds | Send ACK | RB3 |
| | +-+-----------------------+-------------------------+-----+
| | |3| 15 seconds in RB3 | Hang Up, Report Error | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| RB4 | SendFile |1| Can snd requested file| (Batch Send File BS0) | RB0 |
| | (*2) +-+-----------------------+-------------------------+-----+
| | |2| Can't send file | Send EOT | RB0 |
`-----+----------+-+-----------------------+-------------------------+-----'
*1 - If SUB (16H) received before ETX go to RB0 to resync bark receive
*2 - While deciding if file exists, and if the password allows it to be
sent etc., a NUL may be sent to buy 20 seconds more on the timeout
on the other end if it is using the SEAlink extended FTS-0001
specification protocol. Sending a NUL is harmless for a strict
FTS-0001 session, but will not buy more time.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

105
html/ftsc/fts-0009.html
View File

@ -1,105 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Message identification and reply linkage.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FTS-0009
Version: 001
Date: 17-Dec-91
MSGID / REPLY
A standard for unique message identifiers
and reply chain linkage
17 December, 1991
jim nutt
1:114/30@fidonet
Status of this document:
This FTS (FidoNet(r) Technical Standard) specifies an optional
standard for the FidoNet community. Implementation of the
protocols defined in this document is not mandatory, but all
implementations of these protocols are expected to adhere to this
standard. Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
MSGID
A MSGID line consists of the string "^AMSGID:" (where ^A is a
control-A (hex 01) and the double-quotes are not part of the
string), followed by a space, the address of the originating
system, and a serial number unique to that message on the
originating system, i.e.:
^AMSGID: origaddr serialno
The originating address should be specified in a form that
constitutes a valid return address for the originating network.
If the originating address is enclosed in double-quotes, the
entire string between the beginning and ending double-quotes is
considered to be the orginating address. A double-quote character
within a quoted address is represented by by two consecutive
double-quote characters. The serial number may be any eight
character hexadecimal number, as long as it is unique - no two
messages from a given system may have the same serial number
within a three years. The manner in which this serial number is
generated is left to the implementor.
REPLY
A REPLY line consists of the string "^AREPLY:" (where ^A is a
control-A (hex 01) and the double-quotes are not part of the
string), followed by a space, and the origaddr and serialno
fields of the MSGID line of the message to which this message is a
reply, i.e.:
^AREPLY: origaddr serialno
The origaddr and serialno fields must be identical to the
corresponding fields in the MSGID of the message to which this
message is a reply. A REPLY line is never generated in a
message that is a reply to a message that does not contain a
MSGID line.
GENERAL
MSGID and REPLY lines should be placed before the text body of the
message in which they appear.
Finally, a MSGID is generated only at the time of message
creation. An existing MSGID and/or REPLY should never be stripped
from a message passing through an intermediate system. No system
should ever add an MSGID and/or REPLY to, or modify an existing
MSGID / REPLY contained in, a message not originating on that
system.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

193
html/ftsc/fts-4001.html
View File

@ -1,193 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Addessing Control Paragraphs.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FTS-4001
Revision: 1
Title: ADDRESSING CONTROL PARAGRAPHS
Author(s): FTSC
Revision Date: 1 October 2000
Expiry Date: 1 October 2002
----------------------------------------------------------------------
Contents:
1. Credits
2. General
3. FMPT
4. TOPT
5. INTL
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standard (FTS).
This document specifies a Fidonet standard for the Fidonet
community.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
1. Credits
----------
This document is based on the work of Randy Bush and many others.
2. General
----------
The general control paragraph format is specified in separate FTSC
documents.
The addressing control paragraphs specified in this document are
normally only used in netmail messages and not in echomail messages.
While it would be technically correct to use them also in echomail,
it is known that certain programs will misbehave if they are present
there. It is therefore recommended that they should not be used in
echomail at the present time.
If a program processing messages detects these control paragraphs in
an echomail message it is recommended that they are disregarded and
deleted from any copies of that message exported to other systems.
Addressing of and address resolution for echomail messages should
instead be done with the help of packet and message header
information. See separate FTSC documents.
To determine the address of the original sender of an echomail
message, the information in the Origin line should be used. See
separate FTSC documents.
3. FMPT
-------
The FMPT control paragraph shall be used to give information about
the point number of the original sender of a message if that point
number is not 0. If the point number of the original sender of a
message is 0 that message should not contain any FMPT control
paragraph.
The format of a FMPT control paragraph shall be:
&lt;SOH&gt;"FMPT &lt;point number&gt;"&lt;CR&gt;
where &lt;point number&gt; is the ASCII representation of the point number
of the sender. The point number shall be an unsigned integer in the
range 1-65535.
E.g. a message from point number 1 of a certain node shall contain
the following FMPT control paragraph
&lt;SOH&gt;"FMPT 1"&lt;CR&gt;
Note that the format of a FMPT control paragraph deviates from the
general format specified in separate FTSC documents in that it does
not contain any colon after the control tag.
4. TOPT
-------
The TOPT control paragraph shall be used to give information about
the point number of the ultimate addressee of a message if that
point number is not 0. If the point number of the ultimate addressee
of a message is 0 that message should not contain any TOPT control
paragraph.
The format of a TOPT control paragraph shall be:
&lt;SOH&gt;"TOPT "&lt;point number&gt;&lt;CR&gt;
where &lt;point number&gt; is the ASCII representation of the point number
of the addressee. The point number shall be an unsigned integer in
the range 1-65535.
E.g. a message to point number 1 of a certain node shall contain the
following TOPT control paragraph
&lt;SOH&gt;"TOPT 1"&lt;CR&gt;
Note that the format of a TOPT control paragraph deviates from the
general format specified in separate FTSC documents in that it does
not contain any colon after the control tag.
5. INTL
-------
The INTL control paragraph shall be used to give information about
the zone numbers of the original sender and the ultimate addressee
of a message.
The format of an INTL control paragraph shall be:
&lt;SOH&gt;"INTL "&lt;destination address&gt;" "&lt;origin address&gt;&lt;CR&gt;
where &lt;destination address&gt; shall be the representation of the
address of ultimate destination and &lt;origin address&gt; is the
representation of the address of the original sender of the message
in question. These addresses shall be given on the form
&lt;zone&gt;:&lt;net&gt;/&lt;node&gt; where &lt;zone&gt; is the ASCII representation of the
zone number, &lt;net&gt; is the ASCII representation of the net number and
&lt;node&gt; is the ASCII representation of the node number. Any point
number information shall be given in FMPT and TOPT control
paragraphs.
E.g. a message from address 1:123/4.5 to 2:345/6.7 shall contain the
following INTL control paragraph
&lt;SOH&gt;"INTL 2:345/6 1:123/4"&lt;CR&gt;
Note that the format of an INTL control paragraph deviates from the
general format specified in separate FTSC documents in that it does
not contain any colon after the control tag.
INTL control paragraphs are also often used even when both the
originating and the destination systems are in the same zone. This
gives both the originating system and the destination system as well
as any intermediate routing systems unambiguous zone information
even in a situation where one system may be active in a number of
different (possibly non-FidoNet) zones.
Although it is known that some programs may route messages
incorrectly if the INTL control paragraph is present in messages
where both the originating and the destination systems are in the
same zone, it is recommended that the INTL control paragraph is
always inserted into netmail messages in packet files.
A. History
----------
Rev.1, 20001001: Initial Release.
Principal author Goran Eriksson.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

191
html/ftsc/fts-4008.html
View File

@ -1,191 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Time zone information (TZUTC).</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FTS-4008
Revision: 2
Title: Time zone information (TZUTC)
Author: FTSC
Issue Date: 16 May 2003
Review Date: 16 May 2005
Obsoletes: FTS-0010.001
----------------------------------------------------------------------
Contents:
1. Introduction
2. Scope
3. Current practice
4. Control paragraph specification
5. Time zone table
6. Examples
A. References
B. History
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Technical Standard (FTS), issued by the
FTSC for the benefit of the Fidonet community.
This document is based on the FSP-1001 proposal by Odinn Sorensen,
2:236/77.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatsoever.
1. Introduction
---------------
Current practice in FidoNet is to transmit message times in local
time. This document specifies a standard for transmission of time
zone information in FidoNet messages, in the form of a control
paragraph (also known as a "control line" or "kludge") named TZUTC.
2. Scope
--------
This standard is specified for the transmission of FidoNet messages
in any form where time zone information is not integrated into the
transport format, specifically any form where the information would
be lost if not transmitted in a control paragraph, eg. Type 2 packed
messages. [1]
3. Current practice
-------------------
Some control paragraphs already exist to specify the time zone of
messages, notably "TZUTC" and "TZUTCINFO". From observations of
these control paragraphs in actual messages, TZUTC and TZUTCINFO are
identical except for the name. TZUTCINFO is probably named after
the JAM message base's [2] subfield of the same name.
This document adopts the TZUTC control paragraph because is the
shortest ("TZUTC" vs "TZUTCINFO"). However, software
implementations should be prepared to read and interpret the
TZUTCINFO control paragraph as well.
The TZUTC control paragraph is inserted before the message body
upon initial message creation, or export from a format containing
time zone information, such as the aforementioned JAM message base.
4. Control paragraph specification
-----------------------------
Messages which conform to this specification must add the following
control paragraph:
^aTZUTC: &lt;current offset from UTC&gt;
Where ^a is ASCII 1, 01h.
The offset has the format &lt;[-]hhmm&gt;, where hhmm is the number of
hours and minutes, zero-padded to two digits each, that local time
is offset from UTC. If local time is WEST of UTC, then the offset
is NEGATIVE. See the table below for typical offsets.
Note that the hh in a time zone offset is not limited to a maximum
of 12. This is because the International Date Line does not run
exactly along the boundary between zone -1200 and +1200. The
minutes part is 00 for most time zones.
All four digits must be present. If the offset is negative, there
must be a minus ('-', ASCII 45, 2Dh) in front of the offset.
Implementations must NOT put a plus ('+', ASCII 43, 2Bh) in front of
the offset for positive numbers, but robust implementations should
be prepared to find (and ignore) a plus if it exists.
If local time changes as a result of, for example, daylight savings
time, then the offset in the TZUTC control paragraph should change
to reflect this.
5. Time zone table
------------------
This table gives examples of typical time zones.
-1000 Alaska-Hawaii Standard Time (United States)
-0900 Hawaii Daylight Time
-0800 Pacific Standard Time
-0700 Pacific Daylight Time
-0700 Mountain Standard Time
-0600 Mountain Daylight Time
-0600 Central Standard Time
-0500 Central Daylight Time
-0500 Eastern Standard Time
-0400 Eastern Daylight Time
-0400 Atlantic Standard Time
-0330 Newfoundland Standard Time
-0300 Atlantic Daylight Time
-0100 West Africa Time
0000 Universal Time Coordinated (UTC)
0000 Greenwich Mean Time
0100 Central European Time
0100 British Summer Time
0200 Central European Summer Time
0200 Eastern European Time
0800 Australian Western Standard Time
0800 China Coast Time
0900 Japan Standard Time
0900 Australian Western Daylight Time
0930 Australian Central Standard Time
1000 Australian Eastern Standard Time
1030 Australian Central Daylight Time
1100 Australian Eastern Daylight Time
1200 New Zealand Standard Time
1300 New Zealand Daylight Time
6. Examples
-----------
^aTZUTC: 0000
^aTZUTC: 0200
^aTZUTC: -0700
A. References
-------------
[1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy Bush.
September 1995.
[2] "The JAM message base proposal", Joaquim Homrighausen, Andrew
Milner, Mats Birch and Mats Wallin. July 1993.
B. History
----------
Rev.1, 20030409: First release (revised from FSP-1001 by FTSC)
Rev.2, 20030516: Corrected status; clarified Section 2 on insertion
position and export practice; fixed terminology.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

245
html/ftsc/fts-4009.html
View File

@ -1,245 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Netmail Tracking (Via)</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FTS-4009
Revision: 1
Title: Netmail tracking (Via)
Author: FTSC
Issue Date: 16 May 2003
Review Date: 16 May 2005
----------------------------------------------------------------------
Contents:
1. Current practice
2. Control paragraph specification
3. Examples
4. Deprecated formats
A. References
B. History
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Technical Standard (FTS), issued by the
FTSC for the benefit of the Fidonet community.
This document is based on the FSP-1010 proposal by Colin Turner,
2:443/13, and Joaquim Homrighausen, 2:201/330.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatsoever.
1. Current practice
-------------------
As Netmail messages are routed through FidoNet, or as they are
processed on a system, Via control paragraphs are added to track
their progress.
The Via control paragraphs are stored in a block which starts after
any message text. New Via lines should be added to the end of the
block separated from the preceding control paragraph by a single
ASCII carriage-return character (0Dh). There is no limit to the
number of Via control paragraphs in each message.
Note that the "Via" tag is in mixed case, not all upper case like
most control tags.
A Via control paragraph is typically added:
when a Netmail packer packs the Netmail for transmission to
another system;
when a netmail tracker inspects a Netmail.
2. Control paragraph specification
----------------------------------
The Via control paragraph is formatted as a number of fields,
separated by single space (20h) characters, as follows
^AVia &lt;FTN Address&gt; @YYYYMMDD.HHMMSS[.Precise][.Time Zone]
&lt;Program Name&gt; &lt;Version&gt; [Serial Number]&lt;CR&gt;
Where ^A denotes the ASCII &lt;SOH&gt; (01h) character, and &lt;CR&gt; is the
carriage-return character (0Dh).
The fields are defined as follows:
FTN Address
-----------
This field is mandatory and is the FidoNet Technology address of
the system inserting the control paragraph, using standard Fidonet
addressing notation, Z:N/F[.P][@domain]
@YYYYMMDD.HHMMSS
----------------
This field is mandatory and consists of a time stamp. This is the
time at which the stamp was placed. The subcomponents are
YYYY, the calendar year, in full four digit, decimal form;
MM, the calendar month, in the range 01 to 12, this must be a
zero padded, two digit decimal number;
DD, the day of the month, in the range 01 to 31, this must be a
zero padded, two digit decimal number;
HH, hours, in the range 00 to 23, this must be a zero padded,
two digit decimal number;
MM, minutes, in the range 00 to 59, this must be a zero padded,
two digit decimal number;
SS. seconds, in the range 00 to 59, this must be a zero padded,
two digit decimal number.
Precise
-------
This field is optional and takes the form of extra precision in the
time stamp.
If this field is present:
it must begin with a single period character;
this period must be followed by one or more decimal digits;
the field has ended when another period or space is encountered;
each decimal digit in the field following this character
represents the time of the via line in fractions of a second,
such that the the first digit represents tenths of a second,
the second digit represents hundreds of a second and so on.
Robust implementations must check to ensure this field is numeric to
avoid confusion with the Time Zone field.
Time Zone
---------
This field is optional, and must be a short, widely accepted
alphabetical abbreviation of the time zone that the time stamp
in the Via line pertains to.
The use of various Time Zone values is deprecated, implementations
should attempt to convert the timestamp in the control paragraph to
Universal Time (GMT or UTC) and use the "UTC" Time Zone indicator,
where possible.
The Time Zone field may only be omitted when it is not possible for
the implementation to determine the correct offset from UTC, and in
this case the time stamp must represent local time on the generating
system.
Robust implementations must check to ensure this field is not
numeric to avoid confusion with the Precise field.
Program Name
------------
This field is a mandatory string field of up to ten (10) characters
naming the product inserting the Via line.
Version
-------
This field is a mandatory string field of up to ten (10) characters
specifying the version of the product inserting the Via line,
including any alpha, beta or gamma status.
Serial Number
-------------
This field is an optional string field of up to ten (10) characters
identifying the specific copy of the product inserting the Via line.
3. Examples
-----------
Example of valid usage are
^AVia 1:2/3 @19990305.043212.UTC O/T-Track+ 2.69
^AVia 1:2/3@fidonet @19980331.231202.UTC FrontDoor 2.32.mL
^AVia 1:2/3.0 @19990101.002102.UTC FastEcho 1.46.1 21321
^AVia 1:2/3 @19990323.230132 FakeMail 1.2
^AVia 1:2/3 @20030403.182824.UTC Gleipner/Java 1.0/pre
^AVia 1:2/3 @20030403.193223.UTC hpt 1.2.2-stable/os2
^AVia D'Bridge 1.58 1:2/3 04/03 20:47
^AVia 1:2/3@fidonet @20030404.030004.UTC O/T-Track+ 2.66b
^AVia Squish/386 1.11 1:2/3, Thu Apr 03 2003 at 23:16 UTC
^AVia 1:2/3 FTrack 3.1/W32 04 Apr 2003 09:33:07 UTC+1000
^AVia ifmail 1:2/3@fidonet, Fri Apr 11 2003 at 06:01 (2.15)
^AVia RTrk+ 1:2/3@fidonet, Apr 22 2003 at 18:25
^AVia BBBS/NT v4.01 Flag-4 1:2/3.0, @030505155114 EDT+5
4. Deprecated formats
---------------------
Some other formats for the Via line are in use today, but these
formats are rather variable and inconsistent in nature, while
the format specified above is both more widespread and more
consistent.
New implementations may need to parse these formats, but must not
generate them.
The formats in use include, but are not limited to
&lt;NAME&gt; [VERSION] [SERIAL] &lt;ADDRESS&gt; &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt;
&lt;NAME&gt; &lt;ADDRESS&gt;, &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt; &lt;VERSION&gt;
Not that the time stamp in the above formats is also widely
variable, and takes forms which include, but may not be limited to
&lt;Day&gt; &lt;Month&gt; &lt;Year&gt; AT &lt;Hour&gt;:&lt;Min&gt;:[Sec]
&lt;Day of Week&gt; &lt;Month&gt; &lt;Day of Month&gt; &lt;Year&gt; &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;
ON &lt;Day of Month&gt; &lt;Month&gt; &lt;Year&gt; &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;
&lt;Month&gt;/&lt;Day&gt; &lt;Hour&gt;:&lt;Min&gt;
@YYMMDDHHMMSS
In the last listed format, observe in particular the two digit year
and lack of period to separate the date from time.
A. References
-------------
[FTS-1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
Bush. September 1995.
[FSC-46] "A Product Identifier for FidoNet Message Handlers",
Joaquim Homrighausen, August 1994.
B. History
----------
Rev.1, 20030516: First release (revised from FSP-1010 by FTSC; note
the lack of a colon after the "Via" tag)
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

453
html/ftsc/fts-5000.html
View File

@ -1,453 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>The Distribution Nodelist.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<TT>
**********************************************************************<BR>
FTSC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FIDONET&nbsp;TECHNICAL&nbsp;STANDARDS&nbsp;COMMITTEE<BR>
**********************************************************************<BR>
<BR>
Publication:&nbsp;&nbsp;&nbsp;&nbsp;FTS-5000<BR>
Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1<BR>
Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;THE&nbsp;DISTRIBUTION&nbsp;NODELIST<BR>
Author(s):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Colin&nbsp;Turner,&nbsp;Andreas&nbsp;Klein,&nbsp;Michael&nbsp;McCabe,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;David&nbsp;Hallford,&nbsp;Odinn&nbsp;Sorensen<BR>
<BR>
Revision&nbsp;Date:&nbsp;&nbsp;27&nbsp;June&nbsp;1999<BR>
Expiry&nbsp;Date:&nbsp;&nbsp;&nbsp;&nbsp;17&nbsp;June&nbsp;2001<BR>
----------------------------------------------------------------------<BR>
Contents:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.&nbsp;Supercessions<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.&nbsp;Purpose<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.&nbsp;Publication&nbsp;and&nbsp;Distribution<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.&nbsp;Contents<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.&nbsp;Nodediff<BR>
----------------------------------------------------------------------<BR>
<BR>
Status&nbsp;of&nbsp;this&nbsp;document<BR>
-----------------------<BR>
<BR>
&nbsp;&nbsp;This&nbsp;document&nbsp;is&nbsp;a&nbsp;Fidonet&nbsp;Standard&nbsp;(FTS).<BR>
<BR>
&nbsp;&nbsp;This&nbsp;document&nbsp;specifies&nbsp;a&nbsp;Fidonet&nbsp;standard&nbsp;for&nbsp;the&nbsp;Fidonet<BR>
&nbsp;&nbsp;community.<BR>
<BR>
&nbsp;&nbsp;This&nbsp;document&nbsp;is&nbsp;released&nbsp;to&nbsp;the&nbsp;public&nbsp;domain,&nbsp;and&nbsp;may&nbsp;be&nbsp;used,<BR>
&nbsp;&nbsp;copied&nbsp;or&nbsp;modified&nbsp;for&nbsp;any&nbsp;purpose&nbsp;whatever.<BR>
<BR>
<BR>
Abstract<BR>
--------<BR>
<BR>
&nbsp;&nbsp;Current&nbsp;practice&nbsp;for&nbsp;Fidonet&nbsp;Technology&nbsp;Networks&nbsp;(FTN)&nbsp;is&nbsp;to<BR>
&nbsp;&nbsp;maintain&nbsp;a&nbsp;nodelist&nbsp;used&nbsp;to&nbsp;store&nbsp;the&nbsp;details&nbsp;of&nbsp;the&nbsp;nodes&nbsp;in<BR>
&nbsp;&nbsp;the&nbsp;network,&nbsp;and&nbsp;the&nbsp;network&nbsp;structure.<BR>
<BR>
<BR>
1.&nbsp;Supercessions<BR>
----------------<BR>
<BR>
&nbsp;&nbsp;FTS-0005&nbsp;superceded&nbsp;and&nbsp;replaced&nbsp;the&nbsp;documents&nbsp;known&nbsp;under&nbsp;the&nbsp;names<BR>
&nbsp;&nbsp;of&nbsp;FSC-0002,&nbsp;and&nbsp;FTS-0002.<BR>
<BR>
&nbsp;&nbsp;This&nbsp;document&nbsp;supercedes&nbsp;and&nbsp;replaces&nbsp;FTS-0005,&nbsp;FSC-0009,&nbsp;FSC-0040,<BR>
&nbsp;&nbsp;FSC-0075,&nbsp;FSC-0091,&nbsp;and&nbsp;FSP-1012.<BR>
<BR>
2.&nbsp;Purpose<BR>
----------<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Along&nbsp;with&nbsp;the&nbsp;companion&nbsp;technical&nbsp;standard&nbsp;(FTS-5001)&nbsp;this&nbsp;document<BR>
&nbsp;&nbsp;defines&nbsp;the&nbsp;format&nbsp;and&nbsp;content&nbsp;of&nbsp;the&nbsp;nodelist&nbsp;for&nbsp;the&nbsp;FidoNet<BR>
&nbsp;&nbsp;International&nbsp;Hobby&nbsp;Network.&nbsp;The&nbsp;FTS-5001&nbsp;is&nbsp;seperated&nbsp;into&nbsp;two<BR>
&nbsp;&nbsp;parts&nbsp;-&nbsp;the&nbsp;first&nbsp;part&nbsp;is&nbsp;a&nbsp;listing&nbsp;of&nbsp;authorized&nbsp;flags&nbsp;and&nbsp;the<BR>
&nbsp;&nbsp;second&nbsp;part&nbsp;is&nbsp;a&nbsp;registry&nbsp;of&nbsp;userflags.&nbsp;The&nbsp;registry&nbsp;is&nbsp;used&nbsp;to<BR>
&nbsp;&nbsp;prevent&nbsp;a&nbsp;userflag&nbsp;from&nbsp;being&nbsp;used&nbsp;for&nbsp;more&nbsp;than&nbsp;one&nbsp;meaning.&nbsp;The<BR>
&nbsp;&nbsp;registry&nbsp;is&nbsp;maintained&nbsp;by&nbsp;the&nbsp;Fidonet&nbsp;Technical&nbsp;Standards&nbsp;Committee<BR>
&nbsp;&nbsp;Working&nbsp;Group&nbsp;D&nbsp;(the&nbsp;Nodelist).<BR>
<BR>
3.&nbsp;Publication&nbsp;and&nbsp;Distribution<BR>
-------------------------------<BR>
<BR>
&nbsp;&nbsp;The&nbsp;nodelist&nbsp;is&nbsp;published&nbsp;as&nbsp;an&nbsp;ASCII&nbsp;text&nbsp;file&nbsp;named&nbsp;NODELIST.nnn,<BR>
&nbsp;&nbsp;where&nbsp;nnn&nbsp;is&nbsp;the&nbsp;day-of-year&nbsp;of&nbsp;the&nbsp;publication&nbsp;date.<BR>
&nbsp;&nbsp;For&nbsp;actual&nbsp;distribution,&nbsp;&nbsp;NODELIST.nnn&nbsp;is&nbsp;packed&nbsp;into&nbsp;an&nbsp;archive<BR>
&nbsp;&nbsp;file&nbsp;named&nbsp;NODELIST.Pnn,&nbsp;&nbsp;where&nbsp;nn&nbsp;are&nbsp;the&nbsp;last&nbsp;two&nbsp;digits&nbsp;of&nbsp;day-of<BR>
&nbsp;&nbsp;-year&nbsp;and&nbsp;P&nbsp;is&nbsp;the&nbsp;compression&nbsp;format&nbsp;used&nbsp;as&nbsp;listed&nbsp;below.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A&nbsp;=&nbsp;.arc<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Z&nbsp;=&nbsp;.zip<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J&nbsp;=&nbsp;.arj<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R&nbsp;=&nbsp;.rar<BR>
&nbsp;&nbsp;Since&nbsp;.zip&nbsp;is&nbsp;useable&nbsp;on&nbsp;most&nbsp;computer&nbsp;platforms,&nbsp;it&nbsp;is&nbsp;recommended<BR>
&nbsp;&nbsp;that&nbsp;this&nbsp;format&nbsp;be&nbsp;used&nbsp;for&nbsp;distribution&nbsp;of&nbsp;the&nbsp;Distribution<BR>
&nbsp;&nbsp;Nodelist.<BR>
<BR>
<BR>
4.&nbsp;Contents<BR>
-----------<BR>
<BR>
&nbsp;&nbsp;As&nbsp;stated&nbsp;above,&nbsp;&nbsp;NODELIST.nnn&nbsp;is&nbsp;an&nbsp;ASCII&nbsp;text&nbsp;file.&nbsp;&nbsp;It&nbsp;contains<BR>
&nbsp;&nbsp;two&nbsp;kinds&nbsp;of&nbsp;lines,&nbsp;&nbsp;comment&nbsp;lines&nbsp;and&nbsp;data&nbsp;lines.&nbsp;&nbsp;Each&nbsp;line&nbsp;is<BR>
&nbsp;&nbsp;terminated&nbsp;with&nbsp;an&nbsp;ASCII&nbsp;carriage&nbsp;return&nbsp;and&nbsp;line&nbsp;feed&nbsp;character<BR>
&nbsp;&nbsp;sequence,&nbsp;and&nbsp;contains&nbsp;no&nbsp;trailing&nbsp;white-space&nbsp;(spaces,&nbsp;tabs,&nbsp;etc.).<BR>
&nbsp;&nbsp;The&nbsp;file&nbsp;is&nbsp;terminated&nbsp;with&nbsp;an&nbsp;end-of-file&nbsp;character,&nbsp;ASCII&nbsp;&lt;EOF&gt;<BR>
&nbsp;&nbsp;(1AH).<BR>
<BR>
&nbsp;&nbsp;Comments&nbsp;lines&nbsp;contain&nbsp;a&nbsp;semicolon&nbsp;(;)&nbsp;in&nbsp;the&nbsp;first&nbsp;character<BR>
&nbsp;&nbsp;position&nbsp;followed&nbsp;by&nbsp;zero&nbsp;or&nbsp;more&nbsp;alphabetic&nbsp;characters&nbsp;called<BR>
&nbsp;&nbsp;&quot;interest&nbsp;flags&quot;.&nbsp;A&nbsp;program&nbsp;which&nbsp;processes&nbsp;the&nbsp;nodelist&nbsp;may&nbsp;use<BR>
&nbsp;&nbsp;comment&nbsp;interest&nbsp;flags&nbsp;to&nbsp;determine&nbsp;the&nbsp;disposition&nbsp;of&nbsp;a&nbsp;comment<BR>
&nbsp;&nbsp;line.&nbsp;&nbsp;The&nbsp;remainder&nbsp;of&nbsp;a&nbsp;comment&nbsp;line&nbsp;(with&nbsp;one&nbsp;exception,&nbsp;treated<BR>
&nbsp;&nbsp;below)&nbsp;is&nbsp;free-form&nbsp;ASCII&nbsp;text.<BR>
<BR>
&nbsp;&nbsp;There&nbsp;are&nbsp;five&nbsp;interest&nbsp;flags&nbsp;defined&nbsp;as&nbsp;follows:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;S&nbsp;This&nbsp;comment&nbsp;is&nbsp;of&nbsp;particular&nbsp;interest&nbsp;to&nbsp;Sysops.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;U&nbsp;This&nbsp;comment&nbsp;is&nbsp;of&nbsp;particular&nbsp;interest&nbsp;to&nbsp;BBS&nbsp;users.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;F&nbsp;This&nbsp;comment&nbsp;should&nbsp;appear&nbsp;in&nbsp;any&nbsp;formatted&nbsp;&quot;Fido&nbsp;List&quot;.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;A&nbsp;This&nbsp;comment&nbsp;is&nbsp;of&nbsp;general&nbsp;interest&nbsp;(shorthand&nbsp;for&nbsp;;SUF).<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;E&nbsp;This&nbsp;comment&nbsp;is&nbsp;an&nbsp;error&nbsp;message&nbsp;inserted&nbsp;by&nbsp;a&nbsp;nodelist<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;generating&nbsp;program.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;&nbsp;&nbsp;This&nbsp;comment&nbsp;may&nbsp;be&nbsp;ignored&nbsp;by&nbsp;a&nbsp;nodelist&nbsp;processor.<BR>
<BR>
&nbsp;&nbsp;The&nbsp;first&nbsp;line&nbsp;of&nbsp;a&nbsp;nodelist&nbsp;is&nbsp;a&nbsp;special&nbsp;comment&nbsp;line&nbsp;containing<BR>
&nbsp;&nbsp;identification&nbsp;data&nbsp;for&nbsp;the&nbsp;particular&nbsp;edition&nbsp;of&nbsp;the&nbsp;nodelist.&nbsp;The<BR>
&nbsp;&nbsp;following&nbsp;is&nbsp;an&nbsp;example&nbsp;of&nbsp;the&nbsp;first&nbsp;line&nbsp;of&nbsp;a&nbsp;nodelist:<BR>
<BR>
&nbsp;&nbsp;;A&nbsp;FidoNet&nbsp;Nodelist&nbsp;for&nbsp;Friday,&nbsp;July&nbsp;3,&nbsp;1987&nbsp;--<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Day&nbsp;number&nbsp;184&nbsp;:&nbsp;15943<BR>
<BR>
&nbsp;&nbsp;This&nbsp;line&nbsp;contains&nbsp;the&nbsp;general&nbsp;interest&nbsp;flag,&nbsp;&nbsp;the&nbsp;day,&nbsp;&nbsp;date,&nbsp;&nbsp;and<BR>
&nbsp;&nbsp;day-of-year&nbsp;number&nbsp;of&nbsp;publication,&nbsp;&nbsp;and&nbsp;ends&nbsp;with&nbsp;a&nbsp;5-digit&nbsp;decimal<BR>
&nbsp;&nbsp;number&nbsp;with&nbsp;leading&nbsp;zeros,&nbsp;if&nbsp;necessary.&nbsp;&nbsp;This&nbsp;number&nbsp;is&nbsp;the&nbsp;decimal<BR>
&nbsp;&nbsp;representation&nbsp;of&nbsp;a&nbsp;check&nbsp;value&nbsp;derived&nbsp;as&nbsp;follows:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Beginning&nbsp;with&nbsp;the&nbsp;first&nbsp;character&nbsp;of&nbsp;the&nbsp;second&nbsp;line,&nbsp;&nbsp;a&nbsp;16-bit<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cyclic&nbsp;redundancy&nbsp;check&nbsp;(CRC)&nbsp;is&nbsp;calculated&nbsp;for&nbsp;the&nbsp;entire&nbsp;file,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;including&nbsp;carriage&nbsp;return&nbsp;and&nbsp;line&nbsp;feed&nbsp;characters,&nbsp;&nbsp;but&nbsp;not<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;including&nbsp;the&nbsp;terminating&nbsp;EOF&nbsp;character.&nbsp;&nbsp;The&nbsp;check&nbsp;polynomial<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;used&nbsp;is&nbsp;the&nbsp;same&nbsp;one&nbsp;used&nbsp;for&nbsp;many&nbsp;file&nbsp;transfer&nbsp;protocols:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2**16&nbsp;+&nbsp;2**12&nbsp;+&nbsp;2**5&nbsp;+&nbsp;2**0<BR>
<BR>
&nbsp;&nbsp;The&nbsp;CRC&nbsp;may&nbsp;be&nbsp;used&nbsp;to&nbsp;verify&nbsp;that&nbsp;the&nbsp;file&nbsp;has&nbsp;not&nbsp;been&nbsp;edited.&nbsp;The<BR>
&nbsp;&nbsp;importance&nbsp;of&nbsp;this&nbsp;will&nbsp;become&nbsp;evident&nbsp;in&nbsp;the&nbsp;discussion&nbsp;of&nbsp;NODEDIFF<BR>
&nbsp;&nbsp;below.&nbsp;&nbsp;CRC&nbsp;calculation&nbsp;techniques&nbsp;are&nbsp;well&nbsp;documented&nbsp;in&nbsp;the<BR>
&nbsp;&nbsp;literature,&nbsp;&nbsp;and&nbsp;will&nbsp;not&nbsp;be&nbsp;treated&nbsp;further&nbsp;here.<BR>
<BR>
&nbsp;&nbsp;The&nbsp;content&nbsp;of&nbsp;the&nbsp;remaining&nbsp;comments&nbsp;in&nbsp;the&nbsp;nodelist&nbsp;are&nbsp;intended<BR>
&nbsp;&nbsp;to&nbsp;be&nbsp;informative.&nbsp;Beyond&nbsp;the&nbsp;use&nbsp;of&nbsp;interest&nbsp;flags&nbsp;for&nbsp;distribution<BR>
&nbsp;&nbsp;,&nbsp;a&nbsp;processing&nbsp;program&nbsp;need&nbsp;not&nbsp;have&nbsp;any&nbsp;interest&nbsp;in&nbsp;them.<BR>
<BR>
&nbsp;&nbsp;A&nbsp;nodelist&nbsp;data&nbsp;line&nbsp;contains&nbsp;eight&nbsp;variable&nbsp;length&nbsp;&quot;fields&quot;<BR>
&nbsp;&nbsp;separated&nbsp;by&nbsp;commas&nbsp;(,).&nbsp;&nbsp;No&nbsp;space&nbsp;characters&nbsp;are&nbsp;allowed&nbsp;in&nbsp;a&nbsp;data<BR>
&nbsp;&nbsp;line,&nbsp;and&nbsp;&nbsp;underscore&nbsp;characters&nbsp;are&nbsp;used&nbsp;in&nbsp;lieu&nbsp;of&nbsp;spaces.&nbsp;&nbsp;The<BR>
&nbsp;&nbsp;term&nbsp;&quot;alphanumeric&nbsp;character&quot;&nbsp;is&nbsp;defined&nbsp;as&nbsp;the&nbsp;portion&nbsp;of&nbsp;the&nbsp;ASCII<BR>
&nbsp;&nbsp;character&nbsp;set&nbsp;from&nbsp;20&nbsp;hex&nbsp;through&nbsp;7E&nbsp;hex,&nbsp;inclusive.&nbsp;&nbsp;The&nbsp;following<BR>
&nbsp;&nbsp;discussion&nbsp;defines&nbsp;the&nbsp;contents&nbsp;of&nbsp;each&nbsp;field&nbsp;in&nbsp;a&nbsp;data&nbsp;line.<BR>
<BR>
<BR>
&nbsp;&nbsp;Field&nbsp;1:&nbsp;Keyword<BR>
<BR>
&nbsp;&nbsp;The&nbsp;keyword&nbsp;field&nbsp;may&nbsp;be&nbsp;empty,&nbsp;or&nbsp;may&nbsp;contain&nbsp;exactly&nbsp;one&nbsp;keyword<BR>
&nbsp;&nbsp;approved&nbsp;by&nbsp;the&nbsp;Zone&nbsp;Coordinator&nbsp;Council.&nbsp;Current&nbsp;approved&nbsp;keywords<BR>
&nbsp;&nbsp;are:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zone&nbsp;&nbsp;--<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Begins&nbsp;the&nbsp;definition&nbsp;of&nbsp;a&nbsp;geographic&nbsp;zone&nbsp;and&nbsp;define&nbsp;its<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;coordinator.&nbsp;&nbsp;All&nbsp;the&nbsp;data&nbsp;lines&nbsp;following&nbsp;a&nbsp;line&nbsp;with&nbsp;the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;Zone&quot;&nbsp;keyword&nbsp;down&nbsp;to,&nbsp;but&nbsp;not&nbsp;including,&nbsp;the&nbsp;next<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;occurrence&nbsp;of&nbsp;a&nbsp;&quot;Zone&quot;&nbsp;keyword,&nbsp;are&nbsp;regions,&nbsp;nets,&nbsp;and<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nodes&nbsp;within&nbsp;the&nbsp;defined&nbsp;zone.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Region&nbsp;--<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Begins&nbsp;the&nbsp;definition&nbsp;of&nbsp;a&nbsp;geographic&nbsp;region&nbsp;and&nbsp;defines&nbsp;its<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;coordinator.&nbsp;&nbsp;All&nbsp;the&nbsp;data&nbsp;lines&nbsp;following&nbsp;a&nbsp;line&nbsp;with&nbsp;the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;Region&quot;&nbsp;keyword&nbsp;down&nbsp;to,&nbsp;but&nbsp;not&nbsp;including,&nbsp;the&nbsp;next<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;occurrence&nbsp;of&nbsp;a&nbsp;&quot;Zone&quot;,&nbsp;&quot;Region&quot;,&nbsp;or&nbsp;&quot;Host&quot;&nbsp;keyword,&nbsp;are<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;independent&nbsp;nodes&nbsp;within&nbsp;the&nbsp;defined&nbsp;region.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Host&nbsp;--<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Begins&nbsp;the&nbsp;definition&nbsp;of&nbsp;a&nbsp;local&nbsp;network&nbsp;and&nbsp;defines&nbsp;its<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;host.&nbsp;All&nbsp;the&nbsp;data&nbsp;lines&nbsp;following&nbsp;a&nbsp;line&nbsp;with&nbsp;the&nbsp;Host<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;keyword&nbsp;down&nbsp;to,&nbsp;but&nbsp;not&nbsp;including,&nbsp;&nbsp;the&nbsp;next&nbsp;occurrence&nbsp;of<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a&nbsp;&quot;Zone&quot;,&nbsp;&quot;Region&quot;,&nbsp;or&nbsp;&quot;Host&quot;&nbsp;keyword,&nbsp;are&nbsp;local&nbsp;nodes,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;members&nbsp;of&nbsp;the&nbsp;defined&nbsp;local&nbsp;network.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Hub&nbsp;--<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Begins&nbsp;the&nbsp;definition&nbsp;of&nbsp;a&nbsp;routing&nbsp;subunit&nbsp;within&nbsp;a<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;multilevel&nbsp;local&nbsp;network.&nbsp;&nbsp;The&nbsp;hub&nbsp;is&nbsp;the&nbsp;routing&nbsp;focal<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;point&nbsp;for&nbsp;nodes&nbsp;listed&nbsp;below&nbsp;it&nbsp;until&nbsp;the&nbsp;next&nbsp;occurrence<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;a&nbsp;&quot;Zone&quot;,&nbsp;&quot;Region&quot;,&nbsp;&quot;Host&quot;,&nbsp;or&nbsp;&quot;Hub&quot;&nbsp;keyword.&nbsp;&nbsp;The&nbsp;hub<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;entry&nbsp;MUST&nbsp;be&nbsp;a&nbsp;redundant&nbsp;entry,&nbsp;&nbsp;with&nbsp;a&nbsp;unique&nbsp;number,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for&nbsp;one&nbsp;of&nbsp;the&nbsp;nodes&nbsp;listed&nbsp;below&nbsp;it.&nbsp;&nbsp;This&nbsp;is&nbsp;necessary<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;because&nbsp;some&nbsp;nodelist&nbsp;processors&nbsp;eliminate&nbsp;these&nbsp;entries<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in&nbsp;all&nbsp;but&nbsp;the&nbsp;local&nbsp;network.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Pvt&nbsp;--<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Defines&nbsp;a&nbsp;private&nbsp;node&nbsp;with&nbsp;unlisted&nbsp;number.&nbsp;&nbsp;Private&nbsp;nodes<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;are&nbsp;only&nbsp;allowed&nbsp;as&nbsp;members&nbsp;of&nbsp;local&nbsp;networks.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Hold&nbsp;--<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Defines&nbsp;a&nbsp;node&nbsp;which&nbsp;is&nbsp;temporarily&nbsp;down,or&nbsp;&nbsp;is&nbsp;a&nbsp;region/zone<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;independent&nbsp;node&nbsp;which&nbsp;is&nbsp;reachable&nbsp;via&nbsp;IP&nbsp;only.&nbsp;Mail&nbsp;may&nbsp;be<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sent&nbsp;to&nbsp;it&nbsp;and&nbsp;is&nbsp;held&nbsp;by&nbsp;its&nbsp;host&nbsp;or&nbsp;coordinator.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Down&nbsp;--<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Defines&nbsp;a&nbsp;node&nbsp;which&nbsp;is&nbsp;not&nbsp;operational.&nbsp;&nbsp;Mail&nbsp;may&nbsp;NOT&nbsp;be<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sent&nbsp;to&nbsp;it.&nbsp;&nbsp;This&nbsp;keyword&nbsp;may&nbsp;not&nbsp;be&nbsp;used&nbsp;for&nbsp;longer&nbsp;than<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;two&nbsp;weeks&nbsp;on&nbsp;any&nbsp;single&nbsp;node,&nbsp;&nbsp;at&nbsp;which&nbsp;point&nbsp;the&nbsp;&quot;down&quot;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;node&nbsp;is&nbsp;to&nbsp;be&nbsp;removed&nbsp;from&nbsp;the&nbsp;nodelist.<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;empty&gt;&nbsp;--<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Defines&nbsp;a&nbsp;normal&nbsp;node&nbsp;entry.<BR>
<BR>
<BR>
<BR>
&nbsp;&nbsp;Field&nbsp;2&nbsp;-&nbsp;Zone/Region/Net/Node&nbsp;number<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;field&nbsp;contains&nbsp;only&nbsp;numeric&nbsp;digits&nbsp;and&nbsp;is&nbsp;a&nbsp;number&nbsp;in&nbsp;the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;range&nbsp;of&nbsp;1&nbsp;to&nbsp;32767.&nbsp;&nbsp;If&nbsp;the&nbsp;line&nbsp;had&nbsp;the&nbsp;&quot;Zone&quot;,&nbsp;&nbsp;&quot;Region&quot;,&nbsp;&nbsp;or<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;Host&quot;&nbsp;keyword,&nbsp;&nbsp;the&nbsp;number&nbsp;is&nbsp;the&nbsp;zone,&nbsp;net,&nbsp;or&nbsp;region&nbsp;number,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and&nbsp;the&nbsp;node&nbsp;has&nbsp;an&nbsp;implied&nbsp;node&nbsp;number&nbsp;of&nbsp;0,&nbsp;therfore&nbsp;the&nbsp;use&nbsp;of<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a&nbsp;0&nbsp;in&nbsp;this&nbsp;field&nbsp;is&nbsp;strictly&nbsp;forbidden.&nbsp;&nbsp;Otherwise,&nbsp;&nbsp;the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;number&nbsp;is&nbsp;the&nbsp;node&nbsp;number.&nbsp;The&nbsp;zone&nbsp;number,&nbsp;region&nbsp;or&nbsp;net&nbsp;number,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and&nbsp;the&nbsp;node&nbsp;number,&nbsp;taken&nbsp;together,&nbsp;constitute&nbsp;a&nbsp;node's&nbsp;FidoNet<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;address.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zone&nbsp;numbers&nbsp;must&nbsp;be&nbsp;unique.&nbsp;&nbsp;Region&nbsp;or&nbsp;net&nbsp;numbers&nbsp;must&nbsp;be<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unique&nbsp;within&nbsp;their&nbsp;zone.&nbsp;&nbsp;Hub&nbsp;numbers&nbsp;must&nbsp;be&nbsp;within&nbsp;their&nbsp;net.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Node&nbsp;numbers&nbsp;must&nbsp;be&nbsp;unique&nbsp;within&nbsp;their&nbsp;region&nbsp;(for&nbsp;regional<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;independents)&nbsp;or&nbsp;net&nbsp;(for&nbsp;members&nbsp;of&nbsp;a&nbsp;local&nbsp;network).&nbsp;&nbsp;Duplicate<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;node&nbsp;numbers&nbsp;under&nbsp;different&nbsp;hubs&nbsp;within&nbsp;the&nbsp;same&nbsp;net&nbsp;are&nbsp;not<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;allowed.<BR>
<BR>
&nbsp;&nbsp;Field&nbsp;3&nbsp;-&nbsp;Node&nbsp;name<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;field&nbsp;may&nbsp;contain&nbsp;any&nbsp;alphanumeric&nbsp;characters&nbsp;other&nbsp;than<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;commas&nbsp;and&nbsp;spaces.&nbsp;&nbsp;Underscores&nbsp;are&nbsp;used&nbsp;to&nbsp;represent&nbsp;spaces.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;is&nbsp;the&nbsp;name&nbsp;by&nbsp;which&nbsp;the&nbsp;node&nbsp;is&nbsp;known.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;For&nbsp;IP&nbsp;nodes&nbsp;this&nbsp;field&nbsp;may&nbsp;alternately&nbsp;contain&nbsp;an&nbsp;ip&nbsp;address&nbsp;or<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;E-Mail&nbsp;address&nbsp;for&nbsp;email&nbsp;tunneling&nbsp;programs.<BR>
<BR>
&nbsp;&nbsp;Field&nbsp;4&nbsp;-&nbsp;Location<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;field&nbsp;may&nbsp;contain&nbsp;any&nbsp;alphanumeric&nbsp;characters&nbsp;other&nbsp;than<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;commas&nbsp;and&nbsp;spaces.&nbsp;&nbsp;Underscores&nbsp;are&nbsp;used&nbsp;to&nbsp;represent&nbsp;spaces.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;field&nbsp;contains&nbsp;the&nbsp;location&nbsp;of&nbsp;the&nbsp;node.&nbsp;&nbsp;It&nbsp;is&nbsp;usually<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;expressed&nbsp;as&nbsp;the&nbsp;primary&nbsp;local&nbsp;location&nbsp;(town,&nbsp;&nbsp;suburb,&nbsp;&nbsp;city,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;etc.)&nbsp;plus&nbsp;the&nbsp;identifier&nbsp;of&nbsp;the&nbsp;regional&nbsp;geopolitical&nbsp;admin-<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;istrative&nbsp;district&nbsp;(state,&nbsp;&nbsp;province,&nbsp;&nbsp;department,&nbsp;&nbsp;county,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;etc.).&nbsp;&nbsp;Wherever&nbsp;possible,&nbsp;&nbsp;standard&nbsp;postal&nbsp;abbreviations&nbsp;for<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;major&nbsp;regional&nbsp;district&nbsp;should&nbsp;be&nbsp;used&nbsp;(IL,&nbsp;BC,&nbsp;NSW,&nbsp;etc.).<BR>
<BR>
&nbsp;&nbsp;Field&nbsp;5&nbsp;-&nbsp;Sysop&nbsp;name<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;field&nbsp;may&nbsp;contain&nbsp;any&nbsp;alphanumeric&nbsp;characters&nbsp;other&nbsp;than<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;commas&nbsp;and&nbsp;spaces.&nbsp;&nbsp;Underscores&nbsp;are&nbsp;used&nbsp;to&nbsp;represent&nbsp;spaces.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;is&nbsp;the&nbsp;name&nbsp;of&nbsp;the&nbsp;system&nbsp;operator.<BR>
<BR>
&nbsp;&nbsp;Field&nbsp;6&nbsp;-&nbsp;Phone&nbsp;number<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;field&nbsp;contains&nbsp;at&nbsp;least&nbsp;three&nbsp;and&nbsp;usually&nbsp;four&nbsp;numeric<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;subfields&nbsp;separated&nbsp;by&nbsp;dashes&nbsp;(-).&nbsp;&nbsp;The&nbsp;fields&nbsp;are&nbsp;country&nbsp;code,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;city&nbsp;or&nbsp;area&nbsp;code,&nbsp;exchange&nbsp;code,&nbsp;and&nbsp;number.&nbsp;&nbsp;The&nbsp;various&nbsp;parts<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;the&nbsp;phone&nbsp;number&nbsp;are&nbsp;frequently&nbsp;used&nbsp;to&nbsp;derive&nbsp;cost&nbsp;and<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;routing&nbsp;information,&nbsp;as&nbsp;well&nbsp;as&nbsp;what&nbsp;number&nbsp;is&nbsp;to&nbsp;be&nbsp;dialed.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A&nbsp;typical&nbsp;example&nbsp;of&nbsp;the&nbsp;data&nbsp;in&nbsp;a&nbsp;phone&nbsp;number&nbsp;field&nbsp;is&nbsp;1-800-<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;555-1212,&nbsp;corresponding&nbsp;to&nbsp;country&nbsp;1&nbsp;(USA),&nbsp;&nbsp;area&nbsp;800&nbsp;(inbound<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WATS),&nbsp;exchange&nbsp;555,&nbsp;and&nbsp;number&nbsp;1212.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Alternatively,&nbsp;this&nbsp;field&nbsp;may&nbsp;contain&nbsp;the&nbsp;notation&nbsp;-Unpublished-<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in&nbsp;the&nbsp;case&nbsp;of&nbsp;a&nbsp;private&nbsp;node.&nbsp;&nbsp;In&nbsp;this&nbsp;case,&nbsp;the&nbsp;keyword&nbsp;&quot;Pvt&quot;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;must&nbsp;appear&nbsp;on&nbsp;the&nbsp;line.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;field&nbsp;may&nbsp;also&nbsp;contain&nbsp;the&nbsp;IP&nbsp;address&nbsp;for&nbsp;an&nbsp;IP&nbsp;node<BR>
&nbsp;&nbsp;&nbsp;&nbsp;utilizing&nbsp;the&nbsp;country&nbsp;code&nbsp;of&nbsp;000.<BR>
<BR>
&nbsp;&nbsp;Field&nbsp;7&nbsp;-&nbsp;Baud&nbsp;rate<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;field&nbsp;contains&nbsp;the&nbsp;maximum&nbsp;baud&nbsp;rate&nbsp;supported&nbsp;by&nbsp;the&nbsp;node.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(eg:&nbsp;9600,&nbsp;14400,&nbsp;38400,&nbsp;etc)<BR>
<BR>
&nbsp;&nbsp;Field&nbsp;8&nbsp;-&nbsp;Flags<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This&nbsp;optional&nbsp;field&nbsp;contains&nbsp;data&nbsp;about&nbsp;the&nbsp;specific&nbsp;operation&nbsp;of<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;node,&nbsp;such&nbsp;as&nbsp;file&nbsp;requests,&nbsp;modem&nbsp;protocol&nbsp;supported,&nbsp;etc.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Any&nbsp;text&nbsp;following&nbsp;the&nbsp;seventh&nbsp;comma&nbsp;on&nbsp;a&nbsp;data&nbsp;line&nbsp;is&nbsp;taken<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;collectively&nbsp;to&nbsp;be&nbsp;the&nbsp;flags&nbsp;field.&nbsp;&nbsp;The&nbsp;required&nbsp;format&nbsp;is&nbsp;zero<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;or&nbsp;more&nbsp;subfields,&nbsp;separated&nbsp;by&nbsp;commas.&nbsp;&nbsp;Each&nbsp;subfield&nbsp;consists<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;a&nbsp;flag,&nbsp;possibly&nbsp;followed&nbsp;by&nbsp;a&nbsp;value.&nbsp;The&nbsp;authorized&nbsp;flags<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for&nbsp;use&nbsp;in&nbsp;the&nbsp;distribution&nbsp;nodelist&nbsp;are&nbsp;distributed&nbsp;as&nbsp;in<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FTS-5001&nbsp;to&nbsp;facilitate&nbsp;additions&nbsp;and&nbsp;deletions&nbsp;of&nbsp;the&nbsp;authorized<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;flags&nbsp;without&nbsp;requiring&nbsp;an&nbsp;amendment&nbsp;to&nbsp;this&nbsp;FTS.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FTSC&nbsp;recognizes&nbsp;that&nbsp;the&nbsp;FidoNet&nbsp;Zone&nbsp;Coordinator&nbsp;Council&nbsp;with<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;International&nbsp;Coordinator&nbsp;as&nbsp;the&nbsp;ZCC&nbsp;Chairman&nbsp;is&nbsp;the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ultimate&nbsp;authority&nbsp;over&nbsp;what&nbsp;appears&nbsp;in&nbsp;the&nbsp;FidoNet&nbsp;nodelist.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Also,&nbsp;FTSC&nbsp;is&nbsp;by&nbsp;definition&nbsp;a&nbsp;deliberative&nbsp;body,&nbsp;&nbsp;and&nbsp;adding&nbsp;or<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;changing&nbsp;a&nbsp;flag&nbsp;may&nbsp;take&nbsp;a&nbsp;considerable&nbsp;amount&nbsp;of&nbsp;time.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Therefore,&nbsp;the&nbsp;&nbsp;FidoNet&nbsp;International&nbsp;Coordinator&nbsp;or&nbsp;Zone<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Coordinators&nbsp;may&nbsp;temporarily&nbsp;&nbsp;make&nbsp;changes&nbsp;or&nbsp;additions&nbsp;to&nbsp;the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;flags&nbsp;as&nbsp;defined&nbsp;in&nbsp;FTS-5001.&nbsp;&nbsp;The&nbsp;FidoNet&nbsp;International<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Coordinator/Zone&nbsp;Coordinators&nbsp;will&nbsp;then&nbsp;consult&nbsp;with&nbsp;FTSC&nbsp;over<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;changes&nbsp;needed&nbsp;to&nbsp;FTS-5001&nbsp;to&nbsp;reflect&nbsp;these&nbsp;temporary<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;changes.<BR>
<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;following&nbsp;are&nbsp;examples&nbsp;of&nbsp;nodelist&nbsp;data&nbsp;lines:<BR>
<BR>
&nbsp;&nbsp;Host,102,SOCALNET,Los_Angeles_CA,Richard_Mart,1-213-874-9484,2400,XP<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;,102,fido.tree.com,Los_Angeles_CA,Bill_Smart,1-213-555-1212,9600,<BR>
&nbsp;&nbsp;CM,IP,ITN<BR>
<BR>
<BR>
5.&nbsp;Nodediff<BR>
-----------<BR>
<BR>
&nbsp;&nbsp;With&nbsp;more&nbsp;than&nbsp;twenty&nbsp;thousand&nbsp;nodes&nbsp;as&nbsp;of&nbsp;this&nbsp;date,&nbsp;&nbsp;the&nbsp;nodelist,<BR>
&nbsp;&nbsp;even&nbsp;in&nbsp;archive&nbsp;form,&nbsp;&nbsp;is&nbsp;a&nbsp;substantial&nbsp;document&nbsp;(or&nbsp;file).&nbsp;&nbsp;Since<BR>
&nbsp;&nbsp;distribution&nbsp;is&nbsp;via&nbsp;electronic&nbsp;file&nbsp;transfer,&nbsp;&nbsp;this&nbsp;file&nbsp;is&nbsp;NOT<BR>
&nbsp;&nbsp;routinely&nbsp;distributed.&nbsp;&nbsp;Instead,&nbsp;when&nbsp;a&nbsp;new&nbsp;nodelist&nbsp;is&nbsp;prepared,&nbsp;it<BR>
&nbsp;&nbsp;is&nbsp;compared&nbsp;with&nbsp;the&nbsp;previous&nbsp;week's&nbsp;nodelist,&nbsp;and&nbsp;a&nbsp;file&nbsp;containing<BR>
&nbsp;&nbsp;only&nbsp;the&nbsp;differences&nbsp;is&nbsp;created&nbsp;and&nbsp;distributed.<BR>
<BR>
&nbsp;&nbsp;The&nbsp;distribution&nbsp;file,&nbsp;&nbsp;called&nbsp;NODEDIFF.nnn,&nbsp;&nbsp;where&nbsp;nnn&nbsp;is&nbsp;the<BR>
&nbsp;&nbsp;day-of-year&nbsp;of&nbsp;publication,&nbsp;is&nbsp;actually&nbsp;an&nbsp;editing&nbsp;script&nbsp;which&nbsp;will<BR>
&nbsp;&nbsp;transform&nbsp;the&nbsp;previous&nbsp;week's&nbsp;nodelist&nbsp;into&nbsp;the&nbsp;current&nbsp;nodelist.&nbsp;&nbsp;A<BR>
&nbsp;&nbsp;definition&nbsp;of&nbsp;its&nbsp;format&nbsp;follows:<BR>
<BR>
&nbsp;&nbsp;The&nbsp;first&nbsp;line&nbsp;of&nbsp;NODEDIFF.nnn&nbsp;is&nbsp;an&nbsp;exact&nbsp;copy&nbsp;of&nbsp;the&nbsp;first&nbsp;line&nbsp;of<BR>
&nbsp;&nbsp;LAST&nbsp;WEEK'S&nbsp;nodelist.&nbsp;This&nbsp;is&nbsp;used&nbsp;as&nbsp;a&nbsp;first-level&nbsp;confidence&nbsp;check<BR>
&nbsp;&nbsp;to&nbsp;insure&nbsp;that&nbsp;the&nbsp;right&nbsp;file&nbsp;is&nbsp;being&nbsp;edited.&nbsp;&nbsp;The&nbsp;second&nbsp;and&nbsp;sub-<BR>
&nbsp;&nbsp;sequent&nbsp;lines&nbsp;are&nbsp;editing&nbsp;commands&nbsp;and&nbsp;editing&nbsp;data.<BR>
<BR>
&nbsp;&nbsp;There&nbsp;are&nbsp;three&nbsp;editing&nbsp;commands&nbsp;and&nbsp;all&nbsp;have&nbsp;the&nbsp;same&nbsp;format:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;command&gt;&lt;number&gt;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;command&gt;&nbsp;is&nbsp;a&nbsp;1-letter&nbsp;command;&nbsp;&nbsp;A,&nbsp;&nbsp;C,&nbsp;&nbsp;or&nbsp;D.&nbsp;&nbsp;&lt;number&gt;&nbsp;is&nbsp;a<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;decimal&nbsp;number&nbsp;greater&nbsp;than&nbsp;zero,&nbsp;&nbsp;and&nbsp;defines&nbsp;the&nbsp;number&nbsp;of<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lines&nbsp;to&nbsp;be&nbsp;operated&nbsp;on&nbsp;by&nbsp;the&nbsp;command.&nbsp;&nbsp;Each&nbsp;command&nbsp;appears&nbsp;on<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a&nbsp;line&nbsp;by&nbsp;itself.&nbsp;&nbsp;The&nbsp;commands&nbsp;have&nbsp;the&nbsp;following&nbsp;meanings:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ann&nbsp;-&nbsp;Add&nbsp;the&nbsp;following&nbsp;nn&nbsp;lines&nbsp;to&nbsp;the&nbsp;output&nbsp;file.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cnn&nbsp;-&nbsp;Copy&nbsp;nn&nbsp;unchanged&nbsp;lines&nbsp;from&nbsp;the&nbsp;input&nbsp;to&nbsp;the&nbsp;output&nbsp;file.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Dnn&nbsp;-&nbsp;Delete&nbsp;&nbsp;nn&nbsp;lines&nbsp;from&nbsp;the&nbsp;input&nbsp;file.<BR>
<BR>
&nbsp;&nbsp;The&nbsp;following&nbsp;illustrate&nbsp;how&nbsp;the&nbsp;first&nbsp;few&nbsp;lines&nbsp;of&nbsp;NODEDIFF.213<BR>
&nbsp;&nbsp;might&nbsp;look:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;A&nbsp;Friday,&nbsp;July&nbsp;25,&nbsp;1986&nbsp;--&nbsp;Day&nbsp;number&nbsp;206&nbsp;:&nbsp;27712<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;D2<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A2<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;A&nbsp;Friday,&nbsp;August&nbsp;1,&nbsp;1986&nbsp;--&nbsp;Day&nbsp;number&nbsp;213&nbsp;:&nbsp;05060<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;A<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;C5<BR>
<BR>
&nbsp;&nbsp;This&nbsp;fragment&nbsp;illustrates&nbsp;all&nbsp;three&nbsp;editing&nbsp;commands.&nbsp;The&nbsp;first&nbsp;line<BR>
&nbsp;&nbsp;is&nbsp;the&nbsp;first&nbsp;line&nbsp;from&nbsp;NODELIST.206.&nbsp;&nbsp;The&nbsp;next&nbsp;line&nbsp;says&nbsp;&quot;delete&nbsp;the<BR>
&nbsp;&nbsp;first&nbsp;two&nbsp;lines&quot;&nbsp;from&nbsp;NODELIST.206.&nbsp;&nbsp;These&nbsp;are&nbsp;the&nbsp;identification<BR>
&nbsp;&nbsp;line&nbsp;and&nbsp;the&nbsp;line&nbsp;following&nbsp;it.&nbsp;&nbsp;The&nbsp;next&nbsp;command&nbsp;says&nbsp;&quot;add&nbsp;the&nbsp;next<BR>
&nbsp;&nbsp;two&nbsp;lines&quot;&nbsp;to&nbsp;NODELIST.213.&nbsp;&nbsp;The&nbsp;two&nbsp;data&nbsp;lines&nbsp;are&nbsp;followed&nbsp;by&nbsp;a<BR>
&nbsp;&nbsp;command&nbsp;which&nbsp;says&nbsp;&quot;copy&nbsp;five&nbsp;unchanged&nbsp;lines&quot;&nbsp;from&nbsp;NODELIST.206&nbsp;to<BR>
&nbsp;&nbsp;NODELIST&nbsp;.213.&nbsp;&nbsp;Notice&nbsp;that&nbsp;the&nbsp;first&nbsp;line&nbsp;added&nbsp;will&nbsp;ALWAYS&nbsp;contain<BR>
&nbsp;&nbsp;the&nbsp;new&nbsp;nodelist's&nbsp;CRC.<BR>
<BR>
&nbsp;&nbsp;Since&nbsp;only&nbsp;the&nbsp;differences&nbsp;will&nbsp;be&nbsp;distributed,&nbsp;&nbsp;it&nbsp;is&nbsp;important&nbsp;to<BR>
&nbsp;&nbsp;insure&nbsp;the&nbsp;accuracy&nbsp;of&nbsp;the&nbsp;newly&nbsp;created&nbsp;nodelist.&nbsp;&nbsp;This&nbsp;is&nbsp;the<BR>
&nbsp;&nbsp;function&nbsp;of&nbsp;the&nbsp;CRC&nbsp;mentioned&nbsp;above.&nbsp;&nbsp;It&nbsp;is&nbsp;sufficient&nbsp;for&nbsp;a&nbsp;program<BR>
&nbsp;&nbsp;designed&nbsp;to&nbsp;perform&nbsp;the&nbsp;above&nbsp;edits&nbsp;to&nbsp;pick&nbsp;the&nbsp;CRC&nbsp;value&nbsp;from&nbsp;the<BR>
&nbsp;&nbsp;first&nbsp;line&nbsp;added&nbsp;to&nbsp;the&nbsp;output&nbsp;file,&nbsp;then&nbsp;compute&nbsp;the&nbsp;CRC&nbsp;of&nbsp;the<BR>
&nbsp;&nbsp;rest&nbsp;of&nbsp;the&nbsp;output&nbsp;file.&nbsp;&nbsp;If&nbsp;the&nbsp;two&nbsp;CRCs&nbsp;do&nbsp;not&nbsp;agree,&nbsp;&nbsp;one&nbsp;of&nbsp;the<BR>
&nbsp;&nbsp;input&nbsp;files&nbsp;has&nbsp;been&nbsp;corrupted.&nbsp;&nbsp;If&nbsp;they&nbsp;do&nbsp;agree,&nbsp;&nbsp;the&nbsp;probability<BR>
&nbsp;&nbsp;is&nbsp;very&nbsp;high&nbsp;(but&nbsp;not&nbsp;100%)&nbsp;that&nbsp;the&nbsp;output&nbsp;file&nbsp;is&nbsp;accurate.<BR>
<BR>
&nbsp;&nbsp;For&nbsp;actual&nbsp;distribution,&nbsp;NODEDIFF.nnn&nbsp;is&nbsp;packed&nbsp;into&nbsp;an&nbsp;archive&nbsp;file<BR>
&nbsp;&nbsp;named&nbsp;NODEDIFF.Pnn,&nbsp;&nbsp;where&nbsp;nn&nbsp;are&nbsp;the&nbsp;last&nbsp;two&nbsp;digits&nbsp;of&nbsp;day-of-year<BR>
&nbsp;&nbsp;and&nbsp;P&nbsp;is&nbsp;the&nbsp;compression&nbsp;format&nbsp;used&nbsp;as&nbsp;listed&nbsp;below.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A&nbsp;=&nbsp;.arc<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Z&nbsp;=&nbsp;.zip<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J&nbsp;=&nbsp;.arj<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R&nbsp;=&nbsp;.rar<BR>
&nbsp;&nbsp;Since&nbsp;.zip&nbsp;is&nbsp;useable&nbsp;on&nbsp;most&nbsp;computer&nbsp;platforms,&nbsp;it&nbsp;is&nbsp;recommended<BR>
&nbsp;&nbsp;that&nbsp;this&nbsp;format&nbsp;be&nbsp;used&nbsp;for&nbsp;distribution&nbsp;of&nbsp;the&nbsp;Distribution<BR>
&nbsp;&nbsp;Nodediff.<BR>
<BR>
A.&nbsp;References<BR>
-------------<BR>
<BR>
&nbsp;&nbsp;[FTS-5]&nbsp;&quot;The&nbsp;distribution&nbsp;nodelist&quot;,&nbsp;Ben&nbsp;Baker,&nbsp;Rick&nbsp;Moore.<BR>
&nbsp;&nbsp;February&nbsp;1989.&nbsp;Obsoleted&nbsp;by&nbsp;this&nbsp;document.<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;[FSC-9]&nbsp;&quot;Nodelist&nbsp;flag&nbsp;Changes&nbsp;draft&nbsp;document&quot;,&nbsp;Ray&nbsp;Gwinn,&nbsp;David<BR>
&nbsp;&nbsp;Dodell.&nbsp;November&nbsp;1987.&nbsp;Obsoleted&nbsp;by&nbsp;this&nbsp;document.<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;[FSC-40]&nbsp;&quot;Extended&nbsp;Modem&nbsp;Handling&quot;,&nbsp;Michael&nbsp;Shiels.&nbsp;February&nbsp;1990.<BR>
&nbsp;&nbsp;Obsoleted&nbsp;by&nbsp;this&nbsp;document.<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;[FSC-75]&nbsp;&quot;ISDN&nbsp;capability&nbsp;flags&nbsp;in&nbsp;the&nbsp;nodelist&quot;,&nbsp;Jan&nbsp;Ceuleers.<BR>
&nbsp;&nbsp;October&nbsp;1993.&nbsp;Obsoleted&nbsp;by&nbsp;this&nbsp;document.<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;[FSC-91]&nbsp;&quot;ISDN&nbsp;nodelist&nbsp;flags&quot;,&nbsp;Arjen&nbsp;Lentz.<BR>
&nbsp;&nbsp;October&nbsp;1995.&nbsp;Obsoleted&nbsp;by&nbsp;this&nbsp;document.<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;[FSP-1012]&nbsp;&quot;Integration&nbsp;of&nbsp;IP&nbsp;Nodes&nbsp;in&nbsp;the&nbsp;nodelist&quot;,&nbsp;Lothar&nbsp;Behet<BR>
&nbsp;&nbsp;June&nbsp;1999.&nbsp;&nbsp;<BR>
<BR>
B.&nbsp;Contact&nbsp;Data<BR>
---------------<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;David&nbsp;Hallford&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Fidonet:&nbsp;1:208/103<BR>
<BR>
&nbsp;&nbsp;Andreas&nbsp;Klein<BR>
&nbsp;&nbsp;Fidonet:&nbsp;2:2480/47<BR>
&nbsp;&nbsp;E-mail:&nbsp;&nbsp;akx@gmx.net<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Michael&nbsp;McCabe<BR>
&nbsp;&nbsp;Fidonet:&nbsp;1:297/11<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Odinn&nbsp;Sorensen<BR>
&nbsp;&nbsp;Fidonet:&nbsp;N/A<BR>
&nbsp;&nbsp;E-mail:&nbsp;&nbsp;odinn@goldware.dk<BR>
&nbsp;&nbsp;WWW:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;http://www.goldware.dk<BR>
<BR>
&nbsp;&nbsp;Colin&nbsp;Turner<BR>
&nbsp;&nbsp;Fidonet:&nbsp;2:443/13<BR>
&nbsp;&nbsp;E-mail:&nbsp;&nbsp;ct@piglets.com<BR>
&nbsp;&nbsp;WWW:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;http://www.piglets.com<BR>
<BR>
C.&nbsp;History<BR>
----------<BR>
<BR>
&nbsp;&nbsp;&nbsp;Rev.1,&nbsp;19990627:&nbsp;Initial&nbsp;Release.&nbsp;Principal&nbsp;Author&nbsp;David&nbsp;Hallford<BR>
<BR>
<BR>
</TT>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

403
html/ftsc/fts-5001.html
View File

@ -1,403 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>The Distribution Nodelist.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<TT>
**********************************************************************<BR>
FTSC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FIDONET&nbsp;TECHNICAL&nbsp;STANDARDS&nbsp;COMMITTEE<BR>
**********************************************************************<BR>
<BR>
Publication:&nbsp;&nbsp;&nbsp;&nbsp;FTS-5001<BR>
Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1<BR>
Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;NODELIST&nbsp;FLAGS&nbsp;AND&nbsp;USERFLAGS<BR>
Author(s):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Colin&nbsp;Turner,&nbsp;Andreas&nbsp;Klein,&nbsp;Michael&nbsp;McCabe,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;David&nbsp;Hallford,&nbsp;Odinn&nbsp;Sorensen<BR>
<BR>
Revision&nbsp;Date:&nbsp;&nbsp;27&nbsp;June&nbsp;1999<BR>
Expiry&nbsp;Date:&nbsp;&nbsp;&nbsp;&nbsp;27&nbsp;June&nbsp;2001&nbsp;<BR>
----------------------------------------------------------------------<BR>
Contents:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.&nbsp;Authorized&nbsp;Flags<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.&nbsp;Userflags<BR>
----------------------------------------------------------------------<BR>
<BR>
Status&nbsp;of&nbsp;this&nbsp;document<BR>
-----------------------<BR>
<BR>
&nbsp;&nbsp;This&nbsp;document&nbsp;is&nbsp;a&nbsp;Fidonet&nbsp;Standard&nbsp;(FTS).<BR>
<BR>
&nbsp;&nbsp;This&nbsp;document&nbsp;specifies&nbsp;a&nbsp;Fidonet&nbsp;standard&nbsp;for&nbsp;the&nbsp;Fidonet<BR>
&nbsp;&nbsp;community.<BR>
<BR>
&nbsp;&nbsp;This&nbsp;document&nbsp;is&nbsp;released&nbsp;to&nbsp;the&nbsp;public&nbsp;domain,&nbsp;and&nbsp;may&nbsp;be&nbsp;used,<BR>
&nbsp;&nbsp;copied&nbsp;or&nbsp;modified&nbsp;for&nbsp;any&nbsp;purpose&nbsp;whatever.<BR>
<BR>
<BR>
Abstract<BR>
--------<BR>
<BR>
&nbsp;&nbsp;Current&nbsp;practice&nbsp;for&nbsp;Fidonet&nbsp;Technology&nbsp;Networks&nbsp;(FTN)&nbsp;is&nbsp;to<BR>
&nbsp;&nbsp;maintain&nbsp;a&nbsp;nodelist&nbsp;used&nbsp;to&nbsp;store&nbsp;the&nbsp;details&nbsp;of&nbsp;the&nbsp;nodes&nbsp;in<BR>
&nbsp;&nbsp;the&nbsp;network,&nbsp;and&nbsp;the&nbsp;network&nbsp;structure.&nbsp;Flags&nbsp;are&nbsp;used&nbsp;in&nbsp;this<BR>
&nbsp;&nbsp;nodelist&nbsp;to&nbsp;aid&nbsp;automatic&nbsp;and&nbsp;manual&nbsp;control&nbsp;of&nbsp;various&nbsp;tasks.<BR>
<BR>
<BR>
1.&nbsp;Authorized&nbsp;flags<BR>
-------------------<BR>
<BR>
&nbsp;Flags&nbsp;authorized&nbsp;for&nbsp;use&nbsp;in&nbsp;the&nbsp;Fidonet&nbsp;nodelist:<BR>
<BR>
&nbsp;&nbsp;A:&nbsp;OPERATING&nbsp;CONDITION&nbsp;FLAGS:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Flag&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Meaning<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Node&nbsp;accepts&nbsp;mail&nbsp;24&nbsp;hours&nbsp;a&nbsp;day<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Node&nbsp;does&nbsp;not&nbsp;accept&nbsp;human&nbsp;callers<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Node&nbsp;accepts&nbsp;calls&nbsp;Only&nbsp;from&nbsp;Listed<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FidoNet&nbsp;addresses<BR>
<BR>
&nbsp;&nbsp;B.&nbsp;MODEM&nbsp;FLAGS:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;following&nbsp;flags&nbsp;define&nbsp;modem&nbsp;protocols&nbsp;supported:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Flag&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Meaning<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V21&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CCITT&nbsp;V.21&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;300&nbsp;bps&nbsp;&nbsp;&nbsp;full&nbsp;duplex<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CCITT&nbsp;V.22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1200&nbsp;bps&nbsp;&nbsp;full&nbsp;duplex<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V29&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CCITT&nbsp;V.29&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;9600&nbsp;bps&nbsp;&nbsp;half&nbsp;duplex<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CCITT&nbsp;V.32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;9600&nbsp;bps&nbsp;&nbsp;full&nbsp;duplex<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V32b&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITU-T&nbsp;V.32&nbsp;bis&nbsp;14400&nbsp;bps&nbsp;full&nbsp;duplex<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V32T&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V.32&nbsp;Terbo<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V33&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CCITT&nbsp;V.33<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V34&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CCITT&nbsp;V.34<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;HST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;USR&nbsp;Courier&nbsp;HST<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;H14&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;USR&nbsp;Courier&nbsp;HST&nbsp;14.4<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;H16&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;USR&nbsp;Courier&nbsp;HST&nbsp;16.8<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;H96&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Hayes&nbsp;V9600<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Microcom&nbsp;AX/96xx&nbsp;series<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PEP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Packet&nbsp;Ensemble&nbsp;Protocol<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CSP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Compucom&nbsp;Speedmodem<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ZYX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zyxel&nbsp;series<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;VFC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V.Fast&nbsp;Class<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Z19&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zyxel&nbsp;19,200&nbsp;modem&nbsp;protocol<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V90C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITU-T&nbsp;V.90&nbsp;modem&nbsp;Client&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V90S&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITU-T&nbsp;V.90&nbsp;Server.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;X2C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;US&nbsp;Robotics&nbsp;x2&nbsp;client.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;X2S&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;US&nbsp;Robotics&nbsp;x2&nbsp;server.&nbsp;<BR>
<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;following&nbsp;flags&nbsp;define&nbsp;type&nbsp;of&nbsp;error&nbsp;correction&nbsp;available.&nbsp;A<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;separate&nbsp;error&nbsp;correction&nbsp;flag&nbsp;should&nbsp;not&nbsp;be&nbsp;used&nbsp;when&nbsp;the&nbsp;error<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;correction&nbsp;type&nbsp;can&nbsp;be&nbsp;determined&nbsp;by&nbsp;the&nbsp;modem&nbsp;flag.&nbsp;For&nbsp;instance<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a&nbsp;modem&nbsp;flag&nbsp;of&nbsp;HST&nbsp;implies&nbsp;MNP.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Flag&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Meaning<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MNP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Microcom&nbsp;Networking&nbsp;Protocol&nbsp;error&nbsp;correction<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;type&nbsp;MNP1&nbsp;to&nbsp;MNP4<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V42&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LAP-M&nbsp;error&nbsp;correction&nbsp;w/fallback&nbsp;to&nbsp;MNP<BR>
<BR>
&nbsp;&nbsp;C:&nbsp;COMPRESSION&nbsp;FLAGS:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;following&nbsp;flags&nbsp;define&nbsp;the&nbsp;type(s)&nbsp;of&nbsp;compression&nbsp;of&nbsp;mail<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;packets&nbsp;supported.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Flag&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Meaning<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;compression&nbsp;supported<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;following&nbsp;flags&nbsp;define&nbsp;the&nbsp;type(s)&nbsp;of&nbsp;data&nbsp;compression<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;available.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V42b&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITU-T&nbsp;V42bis<BR>
<BR>
<BR>
&nbsp;&nbsp;D:&nbsp;FILE/UPDATE&nbsp;REQUEST&nbsp;FLAGS:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;following&nbsp;flags&nbsp;indicate&nbsp;the&nbsp;types&nbsp;of&nbsp;file/update&nbsp;requests<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;supported.<BR>
<BR>
<BR>
&nbsp;&nbsp;|--------------------------------------------------|<BR>
&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Bark&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WaZOO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<BR>
&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|---------------------|---------------------|<BR>
&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;File&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Update&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;File&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Update&nbsp;&nbsp;|<BR>
&nbsp;&nbsp;|&nbsp;Flag&nbsp;|&nbsp;Requests&nbsp;|&nbsp;Requests&nbsp;|&nbsp;Requests&nbsp;|&nbsp;Requests&nbsp;|<BR>
&nbsp;&nbsp;|------|----------|----------|----------|----------|<BR>
&nbsp;&nbsp;|&nbsp;XA&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|<BR>
&nbsp;&nbsp;|&nbsp;XB&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|<BR>
&nbsp;&nbsp;|&nbsp;XC&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|<BR>
&nbsp;&nbsp;|&nbsp;XP&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|<BR>
&nbsp;&nbsp;|&nbsp;XR&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|<BR>
&nbsp;&nbsp;|&nbsp;XW&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|<BR>
&nbsp;&nbsp;|&nbsp;XX&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;No&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Yes&nbsp;&nbsp;&nbsp;|<BR>
&nbsp;&nbsp;|--------------------------------------------------|<BR>
<BR>
&nbsp;&nbsp;E:&nbsp;GATEWAY&nbsp;FLAG:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;following&nbsp;flag&nbsp;defines&nbsp;gateways&nbsp;to&nbsp;other&nbsp;domains&nbsp;(networks).<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Flag&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Meaning<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Gx..x&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Gateway&nbsp;to&nbsp;domain&nbsp;'x..x',&nbsp;where&nbsp;'x..x`&nbsp;is&nbsp;a&nbsp;string<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;alphanumeric&nbsp;characters.&nbsp;Valid&nbsp;values&nbsp;for<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'x..x'&nbsp;are&nbsp;assigned&nbsp;by&nbsp;the&nbsp;FidoNet&nbsp;International<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Coordinator.&nbsp;&nbsp;Current&nbsp;valid&nbsp;values&nbsp;of&nbsp;'x..x'&nbsp;may<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;be&nbsp;found&nbsp;in&nbsp;the&nbsp;notes&nbsp;at&nbsp;the&nbsp;end&nbsp;of&nbsp;the&nbsp;FidoNet<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nodelist.<BR>
<BR>
&nbsp;&nbsp;F:&nbsp;MAIL&nbsp;PERIOD&nbsp;FLAGS:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;following&nbsp;flags&nbsp;define&nbsp;the&nbsp;dedicated&nbsp;mail&nbsp;periods&nbsp;supported.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;They&nbsp;have&nbsp;the&nbsp;form&nbsp;&quot;#nn&quot;&nbsp;or&nbsp;!nn&nbsp;where&nbsp;nn&nbsp;is&nbsp;the&nbsp;UTC&nbsp;hour&nbsp;the&nbsp;mail<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;period&nbsp;begins,&nbsp;&nbsp;#&nbsp;indicates&nbsp;Bell&nbsp;212A&nbsp;compatibility,&nbsp;&nbsp;and&nbsp;!<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;indicates&nbsp;incompatibility&nbsp;with&nbsp;Bell&nbsp;212A.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Flag&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Meaning<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#01&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zone&nbsp;5&nbsp;mail&nbsp;hour&nbsp;(01:00&nbsp;-&nbsp;02:00&nbsp;UTC)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#02&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zone&nbsp;2&nbsp;mail&nbsp;hour&nbsp;(02:30&nbsp;-&nbsp;03:30&nbsp;UTC)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#08&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zone&nbsp;4&nbsp;mail&nbsp;hour&nbsp;(08:00&nbsp;-&nbsp;09:00&nbsp;UTC)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#09&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zone&nbsp;1&nbsp;mail&nbsp;hour&nbsp;(09:00&nbsp;-&nbsp;10:00&nbsp;UTC)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#18&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zone&nbsp;3&nbsp;mail&nbsp;hour&nbsp;(18:00&nbsp;-&nbsp;19:00&nbsp;UTC)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#20&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zone&nbsp;6&nbsp;mail&nbsp;hour&nbsp;(20:00&nbsp;-&nbsp;21:00&nbsp;UTC)<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;NOTE:&nbsp;&nbsp;When&nbsp;applicable,&nbsp;&nbsp;the&nbsp;mail&nbsp;period&nbsp;flags&nbsp;may<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;be&nbsp;strung&nbsp;together&nbsp;with&nbsp;no&nbsp;intervening&nbsp;commas,&nbsp;eg.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;#02#09&quot;.&nbsp;&nbsp;Only&nbsp;mail&nbsp;hours&nbsp;other&nbsp;than&nbsp;that<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;standard&nbsp;within&nbsp;a&nbsp;node's&nbsp;zone&nbsp;should&nbsp;be&nbsp;given.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Since&nbsp;observance&nbsp;of&nbsp;mail&nbsp;hour&nbsp;within&nbsp;one's&nbsp;zone&nbsp;is<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mandatory,&nbsp;&nbsp;it&nbsp;should&nbsp;not&nbsp;be&nbsp;indicated.<BR>
<BR>
&nbsp;&nbsp;G:&nbsp;ISDN&nbsp;CAPABILTY&nbsp;FLAGS:<BR>
<BR>
&nbsp;&nbsp;&nbsp;Nodelist&nbsp;&nbsp;Specification&nbsp;of&nbsp;minimal&nbsp;support&nbsp;required&nbsp;for&nbsp;this&nbsp;flag;<BR>
&nbsp;&nbsp;&nbsp;flag&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;any&nbsp;additional&nbsp;support&nbsp;to&nbsp;be&nbsp;arranged&nbsp;via&nbsp;agreement&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;between&nbsp;users<BR>
<BR>
&nbsp;&nbsp;&nbsp;V110L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITU-T&nbsp;V.110&nbsp;19k2&nbsp;async&nbsp;('low').<BR>
&nbsp;&nbsp;&nbsp;V110H&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITU-T&nbsp;V.110&nbsp;38k4&nbsp;async&nbsp;('high').<BR>
&nbsp;&nbsp;&nbsp;V120L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITU-T&nbsp;V.120&nbsp;56k&nbsp;async,&nbsp;layer&nbsp;2&nbsp;framesize&nbsp;259,&nbsp;window&nbsp;7,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;modulo&nbsp;8.<BR>
&nbsp;&nbsp;&nbsp;V120H&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITU-T&nbsp;V.120&nbsp;64k&nbsp;async,&nbsp;layer&nbsp;2&nbsp;framesize&nbsp;259,&nbsp;window&nbsp;7,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;modulo&nbsp;8.<BR>
&nbsp;&nbsp;&nbsp;X75&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITU-T&nbsp;X.75&nbsp;SLP&nbsp;(single&nbsp;link&nbsp;procedure)&nbsp;with&nbsp;64kbit/s&nbsp;B<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;channel;&nbsp;layer&nbsp;2&nbsp;max.framesize&nbsp;2048,&nbsp;window&nbsp;2,&nbsp;non-ext.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mode&nbsp;(modulo&nbsp;8);&nbsp;layer&nbsp;3&nbsp;transparent&nbsp;(no&nbsp;packet&nbsp;layer).<BR>
&nbsp;&nbsp;&nbsp;ISDN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Other&nbsp;configurations.&nbsp;Use&nbsp;only&nbsp;if&nbsp;none&nbsp;of&nbsp;the&nbsp;above<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;fits.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;NOTE:&nbsp;No&nbsp;flag&nbsp;implies&nbsp;another.&nbsp;Each&nbsp;capability&nbsp;MUST&nbsp;be&nbsp;specifically<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;listed.<BR>
&nbsp;&nbsp;&nbsp;If&nbsp;no&nbsp;modem&nbsp;connects&nbsp;are&nbsp;supported,&nbsp;the&nbsp;nodelist&nbsp;speed&nbsp;field&nbsp;should<BR>
&nbsp;&nbsp;&nbsp;be&nbsp;300.<BR>
<BR>
&nbsp;&nbsp;&nbsp;Conversion&nbsp;from&nbsp;old&nbsp;to&nbsp;new&nbsp;ISDN&nbsp;capability&nbsp;flags:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISDNA&nbsp;-&gt;&nbsp;V110L<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISDNB&nbsp;-&gt;&nbsp;V110H<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISDNC&nbsp;-&gt;&nbsp;X75<BR>
<BR>
&nbsp;&nbsp;H:&nbsp;INTERNET&nbsp;CAPABILITY&nbsp;FLAGS:&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;FLAG&nbsp;&nbsp;&nbsp;MEANING<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;IBN&nbsp;-&nbsp;denotes&nbsp;a&nbsp;system&nbsp;that&nbsp;does&nbsp;BINKP&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;IFC&nbsp;-&nbsp;denotes&nbsp;a&nbsp;system&nbsp;that&nbsp;is&nbsp;capable&nbsp;of&nbsp;RAW&nbsp;or&nbsp;IFCICO&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;ITN&nbsp;-&nbsp;denote&nbsp;a&nbsp;system&nbsp;that&nbsp;does&nbsp;TELNET&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;IVM&nbsp;-&nbsp;denotes&nbsp;a&nbsp;system&nbsp;that&nbsp;is&nbsp;capable&nbsp;of&nbsp;VMODEM&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;IFT&nbsp;-&nbsp;denotes&nbsp;a&nbsp;system&nbsp;that&nbsp;allows&nbsp;FTP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;ITX&nbsp;-&nbsp;denotes&nbsp;a&nbsp;system&nbsp;that&nbsp;uses&nbsp;TransX&nbsp;encoding&nbsp;for&nbsp;email<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;tunneling<BR>
&nbsp;&nbsp;&nbsp;&nbsp;IUC&nbsp;-&nbsp;denotes&nbsp;a&nbsp;system&nbsp;that&nbsp;uses&nbsp;UUEncode&nbsp;for&nbsp;email&nbsp;tunneling&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;IMI&nbsp;-&nbsp;denotes&nbsp;a&nbsp;system&nbsp;which&nbsp;uses&nbsp;MIME&nbsp;encoding&nbsp;for&nbsp;email<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;tunneling<BR>
&nbsp;&nbsp;&nbsp;&nbsp;ISE&nbsp;-&nbsp;denotes&nbsp;a&nbsp;system&nbsp;which&nbsp;supports&nbsp;SEAT&nbsp;receipts&nbsp;for&nbsp;anonymous<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mail<BR>
&nbsp;&nbsp;&nbsp;&nbsp;IP&nbsp;&nbsp;-&nbsp;denotes&nbsp;a&nbsp;system&nbsp;that&nbsp;can&nbsp;receive&nbsp;TCP/IP&nbsp;connects&nbsp;using&nbsp;a<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;protocol&nbsp;that&nbsp;is&nbsp;not&nbsp;covered&nbsp;by&nbsp;any&nbsp;other&nbsp;flag.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;IEM&nbsp;-&nbsp;is&nbsp;a&nbsp;deprecated&nbsp;flag,&nbsp;and&nbsp;new&nbsp;implementations&nbsp;must&nbsp;not<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;write&nbsp;it&nbsp;in&nbsp;nodelist&nbsp;entries.&nbsp;This&nbsp;was&nbsp;used&nbsp;as&nbsp;a&nbsp;single<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;placeholder&nbsp;for&nbsp;the&nbsp;InterNet&nbsp;address&nbsp;of&nbsp;the&nbsp;system&nbsp;if&nbsp;it<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;supported&nbsp;several&nbsp;transport&nbsp;methods.&nbsp;Instead&nbsp;of&nbsp;placing<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;system&nbsp;address&nbsp;in&nbsp;the&nbsp;deprecated&nbsp;form&nbsp;specified&nbsp;below<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in&nbsp;each&nbsp;flag,&nbsp;the&nbsp;address&nbsp;would&nbsp;be&nbsp;placed&nbsp;once&nbsp;only&nbsp;in&nbsp;this<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;flag.&nbsp;Implementations&nbsp;may&nbsp;need&nbsp;to&nbsp;parse&nbsp;this&nbsp;information<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from&nbsp;nodelists&nbsp;created&nbsp;with&nbsp;older&nbsp;programs.<BR>
<BR>
&nbsp;&nbsp;Conversion&nbsp;from&nbsp;old&nbsp;Internet&nbsp;capabilty&nbsp;flags&nbsp;to&nbsp;the&nbsp;new&nbsp;flags:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;BND&nbsp;-&gt;&nbsp;IBN<BR>
&nbsp;&nbsp;&nbsp;&nbsp;TEL&nbsp;-&gt;&nbsp;ITN<BR>
&nbsp;&nbsp;&nbsp;&nbsp;TELNET&nbsp;-&gt;&nbsp;ITN<BR>
&nbsp;&nbsp;&nbsp;&nbsp;VMD&nbsp;-&gt;&nbsp;IVM<BR>
&nbsp;&nbsp;&nbsp;&nbsp;TCP&nbsp;-&gt;&nbsp;IP<BR>
<BR>
&nbsp;&nbsp;The&nbsp;Internet&nbsp;Address&nbsp;should&nbsp;be&nbsp;placed&nbsp;in&nbsp;the&nbsp;BBS&nbsp;name&nbsp;field.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Previous&nbsp;usage&nbsp;has&nbsp;placed&nbsp;the&nbsp;InterNet&nbsp;address&nbsp;as&nbsp;part&nbsp;of&nbsp;the<BR>
&nbsp;&nbsp;I-flag&nbsp;(for&nbsp;example&nbsp;ITX:r10_tx@thevision.net);&nbsp;in&nbsp;this&nbsp;format&nbsp;the<BR>
&nbsp;&nbsp;flag,&nbsp;colon,&nbsp;and&nbsp;address&nbsp;combined&nbsp;cannot&nbsp;exceed&nbsp;32&nbsp;characters.<BR>
&nbsp;&nbsp;However,&nbsp;this&nbsp;practice&nbsp;is&nbsp;deprecated,&nbsp;and&nbsp;new&nbsp;implementations&nbsp;must<BR>
&nbsp;&nbsp;not&nbsp;place&nbsp;address&nbsp;data&nbsp;in&nbsp;the&nbsp;flag&nbsp;section&nbsp;of&nbsp;the&nbsp;nodelist&nbsp;entry,<BR>
&nbsp;&nbsp;implementations&nbsp;may&nbsp;however&nbsp;be&nbsp;required&nbsp;to&nbsp;read&nbsp;this&nbsp;data&nbsp;from&nbsp;the<BR>
&nbsp;&nbsp;flag&nbsp;section.<BR>
<BR>
&nbsp;&nbsp;Telnet&nbsp;default&nbsp;port&nbsp;is&nbsp;23.&nbsp;If&nbsp;the&nbsp;port&nbsp;is&nbsp;not&nbsp;23&nbsp;then&nbsp;the&nbsp;port<BR>
&nbsp;&nbsp;number&nbsp;must&nbsp;be&nbsp;placed&nbsp;after&nbsp;the&nbsp;ITN&nbsp;flag&nbsp;(eg&nbsp;ITN:60177)&nbsp;if&nbsp;the<BR>
&nbsp;&nbsp;Telnet&nbsp;address&nbsp;is&nbsp;part&nbsp;of&nbsp;the&nbsp;ITN&nbsp;flag&nbsp;(eg&nbsp;ITN:farsi.dynip.com)&nbsp;then<BR>
&nbsp;&nbsp;the&nbsp;port&nbsp;number&nbsp;should&nbsp;be&nbsp;last&nbsp;(eg&nbsp;ITN:farsi.dynip.com:60177)&nbsp;always<BR>
&nbsp;&nbsp;remember&nbsp;that&nbsp;the&nbsp;flag&nbsp;cannot&nbsp;exceed&nbsp;32&nbsp;characters&nbsp;total.<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;The&nbsp;default&nbsp;ports&nbsp;for&nbsp;other&nbsp;protocols&nbsp;are&nbsp;shown&nbsp;below,&nbsp;and&nbsp;changes<BR>
&nbsp;&nbsp;from&nbsp;the&nbsp;default&nbsp;port&nbsp;must&nbsp;be&nbsp;flagged&nbsp;in&nbsp;a&nbsp;similar&nbsp;way.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Flag&nbsp;&nbsp;&nbsp;&nbsp;Default&nbsp;Port<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;FTP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IFT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;21<BR>
&nbsp;&nbsp;BINKP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IBN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;24554<BR>
&nbsp;&nbsp;RAW/IFCICO&nbsp;&nbsp;&nbsp;&nbsp;IFC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;60179<BR>
&nbsp;&nbsp;VMODEM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IVM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3141<BR>
<BR>
&nbsp;&nbsp;Actual&nbsp;IP&nbsp;addresses&nbsp;can&nbsp;also&nbsp;be&nbsp;placed&nbsp;in&nbsp;the&nbsp;phone&nbsp;number&nbsp;field<BR>
&nbsp;&nbsp;using&nbsp;&nbsp;the&nbsp;country&nbsp;code&nbsp;of&nbsp;000.<BR>
<BR>
&nbsp;&nbsp;I:&nbsp;SYSTEM&nbsp;ONLINE&nbsp;USERFLAGS<BR>
<BR>
&nbsp;&nbsp;&nbsp;The&nbsp;flag&nbsp;Tyz&nbsp;is&nbsp;used&nbsp;by&nbsp;non-CM&nbsp;nodes&nbsp;online&nbsp;not&nbsp;only&nbsp;during&nbsp;ZMH,<BR>
&nbsp;&nbsp;&nbsp;y&nbsp;is&nbsp;a&nbsp;letter&nbsp;indicating&nbsp;the&nbsp;start&nbsp;and&nbsp;z&nbsp;a&nbsp;letter&nbsp;indicating&nbsp;the<BR>
&nbsp;&nbsp;&nbsp;end&nbsp;of&nbsp;the&nbsp;online&nbsp;period&nbsp;as&nbsp;defined&nbsp;below&nbsp;(times&nbsp;in&nbsp;UTC):<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A&nbsp;&nbsp;0:00,&nbsp;&nbsp;a&nbsp;&nbsp;0:30,&nbsp;&nbsp;&nbsp;B&nbsp;&nbsp;1:00,&nbsp;&nbsp;b&nbsp;&nbsp;1:30,&nbsp;&nbsp;&nbsp;C&nbsp;&nbsp;2:00,&nbsp;&nbsp;c&nbsp;&nbsp;2:30,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;D&nbsp;&nbsp;3:00,&nbsp;&nbsp;d&nbsp;&nbsp;3:30,&nbsp;&nbsp;&nbsp;E&nbsp;&nbsp;4:00,&nbsp;&nbsp;e&nbsp;&nbsp;4:30,&nbsp;&nbsp;&nbsp;F&nbsp;&nbsp;5:00,&nbsp;&nbsp;f&nbsp;&nbsp;5:30,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;&nbsp;6:00,&nbsp;&nbsp;g&nbsp;&nbsp;6:30,&nbsp;&nbsp;&nbsp;H&nbsp;&nbsp;7:00,&nbsp;&nbsp;h&nbsp;&nbsp;7:30,&nbsp;&nbsp;&nbsp;I&nbsp;&nbsp;8:00,&nbsp;&nbsp;i&nbsp;&nbsp;8:30,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J&nbsp;&nbsp;9:00,&nbsp;&nbsp;j&nbsp;&nbsp;9:30,&nbsp;&nbsp;&nbsp;K&nbsp;10:00,&nbsp;&nbsp;k&nbsp;10:30,&nbsp;&nbsp;&nbsp;L&nbsp;11:00,&nbsp;&nbsp;l&nbsp;11:30,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M&nbsp;12:00,&nbsp;&nbsp;m&nbsp;12:30,&nbsp;&nbsp;&nbsp;N&nbsp;13:00,&nbsp;&nbsp;n&nbsp;13:30,&nbsp;&nbsp;&nbsp;O&nbsp;14:00,&nbsp;&nbsp;o&nbsp;14:30,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;P&nbsp;15:00,&nbsp;&nbsp;p&nbsp;15:30,&nbsp;&nbsp;&nbsp;Q&nbsp;16:00,&nbsp;&nbsp;q&nbsp;16:30,&nbsp;&nbsp;&nbsp;R&nbsp;17:00,&nbsp;&nbsp;r&nbsp;17:30,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S&nbsp;18:00,&nbsp;&nbsp;s&nbsp;18:30,&nbsp;&nbsp;&nbsp;T&nbsp;19:00,&nbsp;&nbsp;t&nbsp;19:30,&nbsp;&nbsp;&nbsp;U&nbsp;20:00,&nbsp;&nbsp;u&nbsp;20:30,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V&nbsp;21:00,&nbsp;&nbsp;v&nbsp;21:30,&nbsp;&nbsp;&nbsp;W&nbsp;22:00,&nbsp;&nbsp;w&nbsp;22:30,&nbsp;&nbsp;&nbsp;X&nbsp;23:00,&nbsp;&nbsp;x&nbsp;23:30.<BR>
<BR>
&nbsp;&nbsp;&nbsp;For&nbsp;example&nbsp;TuB&nbsp;shows&nbsp;an&nbsp;online&nbsp;period&nbsp;from&nbsp;20:30&nbsp;until&nbsp;1:00&nbsp;UTC.<BR>
<BR>
&nbsp;&nbsp;&nbsp;Daylight&nbsp;saving&nbsp;time<BR>
<BR>
&nbsp;&nbsp;&nbsp;If&nbsp;a&nbsp;node&nbsp;changes&nbsp;online&nbsp;times&nbsp;with&nbsp;respect&nbsp;to&nbsp;UTC&nbsp;when&nbsp;daylight<BR>
&nbsp;&nbsp;&nbsp;saving&nbsp;time&nbsp;becomes&nbsp;effective&nbsp;(which&nbsp;would&nbsp;be&nbsp;the&nbsp;case&nbsp;with&nbsp;most<BR>
&nbsp;&nbsp;&nbsp;part&nbsp;time&nbsp;nodes),&nbsp;then&nbsp;this&nbsp;is&nbsp;to&nbsp;be&nbsp;taken&nbsp;into&nbsp;account&nbsp;when<BR>
&nbsp;&nbsp;&nbsp;assigning&nbsp;this&nbsp;flag.&nbsp;An&nbsp;online&nbsp;times&nbsp;flag&nbsp;assigned&nbsp;to&nbsp;a&nbsp;node&nbsp;should<BR>
&nbsp;&nbsp;&nbsp;not&nbsp;be&nbsp;altered&nbsp;for&nbsp;the&nbsp;specific&nbsp;purpose&nbsp;of&nbsp;adjusting&nbsp;due&nbsp;to<BR>
&nbsp;&nbsp;&nbsp;daylight&nbsp;saving&nbsp;time,&nbsp;since&nbsp;large&nbsp;difference&nbsp;files&nbsp;(NODEDIFF's)<BR>
&nbsp;&nbsp;&nbsp;would&nbsp;result&nbsp;if&nbsp;every&nbsp;node&nbsp;was&nbsp;allowed&nbsp;to&nbsp;do&nbsp;this,&nbsp;e.g.&nbsp;my&nbsp;node<BR>
&nbsp;&nbsp;&nbsp;used&nbsp;to&nbsp;be&nbsp;online&nbsp;from&nbsp;2300&nbsp;to&nbsp;0800&nbsp;in&nbsp;local&nbsp;time,&nbsp;which&nbsp;in&nbsp;winter<BR>
&nbsp;&nbsp;&nbsp;is&nbsp;UTC,&nbsp;but&nbsp;in&nbsp;the&nbsp;summer&nbsp;it&nbsp;becomes&nbsp;BST&nbsp;(British&nbsp;Summer&nbsp;Time).<BR>
&nbsp;&nbsp;&nbsp;This&nbsp;is&nbsp;one&nbsp;hour&nbsp;ahead&nbsp;of&nbsp;UTC,&nbsp;and&nbsp;the&nbsp;corresponding&nbsp;availability<BR>
&nbsp;&nbsp;&nbsp;times&nbsp;of&nbsp;my&nbsp;node&nbsp;during&nbsp;the&nbsp;summer&nbsp;period&nbsp;were&nbsp;2200&nbsp;to&nbsp;0700&nbsp;UTC.<BR>
&nbsp;&nbsp;&nbsp;Therefore&nbsp;my&nbsp;online&nbsp;times&nbsp;flag&nbsp;would&nbsp;have&nbsp;indicated&nbsp;availability<BR>
&nbsp;&nbsp;&nbsp;between&nbsp;the&nbsp;hours&nbsp;of&nbsp;2300&nbsp;and&nbsp;0700&nbsp;UTC,&nbsp;the&nbsp;daily&nbsp;time&nbsp;period<BR>
&nbsp;&nbsp;&nbsp;encompassing&nbsp;both&nbsp;times,&nbsp;so&nbsp;the&nbsp;flag&nbsp;would&nbsp;be&nbsp;TXH.<BR>
<BR>
2.&nbsp;Userflags<BR>
------------<BR>
<BR>
&nbsp;&nbsp;Registry&nbsp;of&nbsp;Userflags<BR>
<BR>
&nbsp;&nbsp;A.&nbsp;FORMAT&nbsp;OF&nbsp;USER&nbsp;FLAGS<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;U,x..x<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A&nbsp;user-specified&nbsp;string,&nbsp;which&nbsp;may&nbsp;contain&nbsp;any<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;alphanumeric&nbsp;character&nbsp;except&nbsp;blanks.&nbsp;&nbsp;This&nbsp;string&nbsp;may<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;contain&nbsp;one&nbsp;to&nbsp;thirty-two&nbsp;characters&nbsp;of&nbsp;information<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;that&nbsp;may&nbsp;be&nbsp;used&nbsp;to&nbsp;add&nbsp;user-defined&nbsp;data&nbsp;to&nbsp;a&nbsp;specific<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nodelist&nbsp;entry.&nbsp;&nbsp;The&nbsp;character&nbsp;&quot;U&quot;&nbsp;must&nbsp;not&nbsp;be<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;repeated,&nbsp;eg,&nbsp;&quot;,U,XXX,YYY,ZZZ&quot;&nbsp;not&nbsp;&quot;,U,XXX,U,YYY,UZZZ&quot;.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;32&nbsp;character&nbsp;limitation&nbsp;is&nbsp;per&nbsp;userflag,&nbsp;not&nbsp;for<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;total&nbsp;of&nbsp;all&nbsp;userflags.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;New&nbsp;implementations&nbsp;must&nbsp;place&nbsp;a&nbsp;comma&nbsp;after&nbsp;the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;initial&nbsp;&quot;U&quot;&nbsp;before&nbsp;the&nbsp;user&nbsp;flags.&nbsp;Some<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implementations&nbsp;will&nbsp;not&nbsp;place&nbsp;a&nbsp;separating&nbsp;comma<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;betweent&nbsp;the&nbsp;&quot;U&quot;&nbsp;and&nbsp;the&nbsp;first&nbsp;user&nbsp;flag,&nbsp;but&nbsp;this<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;practice&nbsp;is&nbsp;deprecated.&nbsp;Implementations&nbsp;should&nbsp;be<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;prepared&nbsp;to&nbsp;read&nbsp;flags&nbsp;in&nbsp;this&nbsp;format,&nbsp;and&nbsp;must&nbsp;strip<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;&quot;U&quot;&nbsp;from&nbsp;the&nbsp;flag&nbsp;before&nbsp;analysis&nbsp;in&nbsp;this&nbsp;case.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Entries&nbsp;following&nbsp;the&nbsp;&quot;U&quot;&nbsp;flag&nbsp;must&nbsp;be&nbsp;of&nbsp;a&nbsp;technical<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;or&nbsp;administrative&nbsp;nature.&nbsp;&nbsp;While&nbsp;experimentation&nbsp;of&nbsp;new<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;software&nbsp;functions&nbsp;using&nbsp;this&nbsp;flag&nbsp;is&nbsp;encouraged,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;advertisement&nbsp;is&nbsp;strictly&nbsp;prohibited.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;For&nbsp;applications&nbsp;other&nbsp;than&nbsp;those&nbsp;shown,&nbsp;or&nbsp;if&nbsp;you<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;have&nbsp;questions&nbsp;concerning&nbsp;the&nbsp;use&nbsp;of&nbsp;this&nbsp;field,&nbsp;please<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;contact&nbsp;your&nbsp;Regional&nbsp;or&nbsp;Zone&nbsp;Coordinator.<BR>
<BR>
<BR>
&nbsp;&nbsp;B:&nbsp;MAIL&nbsp;ORIENTED&nbsp;USER&nbsp;FLAGS:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ZEC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zone&nbsp;EchoMail&nbsp;Coordinator.&nbsp;Not&nbsp;more&nbsp;than&nbsp;one&nbsp;entry<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in&nbsp;the&nbsp;zone&nbsp;&nbsp;segment&nbsp;may&nbsp;carry&nbsp;this&nbsp;flag&nbsp;and&nbsp;that&nbsp;entry<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;must&nbsp;be&nbsp;the&nbsp;current&nbsp;Zone&nbsp;EchoMail&nbsp;Coordinator.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;REC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Regional&nbsp;EchoMail&nbsp;Coordinator.&nbsp;Not&nbsp;more&nbsp;than&nbsp;one<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;entry&nbsp;in&nbsp;any&nbsp;region&nbsp;may&nbsp;carry&nbsp;this&nbsp;flag&nbsp;and&nbsp;that&nbsp;entry<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;must&nbsp;be&nbsp;the&nbsp;current&nbsp;Regional&nbsp;EchoMail&nbsp;Coordinator.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;NEC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Network&nbsp;EchoMail&nbsp;coordinator.&nbsp;Not&nbsp;more&nbsp;than&nbsp;one&nbsp;entry<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in&nbsp;any&nbsp;net&nbsp;may&nbsp;carry&nbsp;this&nbsp;flag&nbsp;and&nbsp;that&nbsp;entry&nbsp;must&nbsp;be<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;current&nbsp;Network&nbsp;EchoMail&nbsp;Coordinator&nbsp;of&nbsp;that&nbsp;Net.<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SDS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Software&nbsp;Distribution&nbsp;System<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SMH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Secure&nbsp;Mail&nbsp;Hub<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;NC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Network&nbsp;Coordinator.&nbsp;This&nbsp;flag&nbsp;is&nbsp;ONLY&nbsp;to&nbsp;be&nbsp;used&nbsp;by<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;Network&nbsp;Coordinator&nbsp;of&nbsp;a&nbsp;net&nbsp;which&nbsp;has&nbsp;split&nbsp;the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;duties&nbsp;of&nbsp;NC&nbsp;and&nbsp;Host&nbsp;and&nbsp;the&nbsp;NC&nbsp;does&nbsp;NOT&nbsp;occupy&nbsp;the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Net/0&nbsp;position&nbsp;in&nbsp;the&nbsp;nodelist.<BR>
<BR>
<BR>
A.&nbsp;Contact&nbsp;Data<BR>
---------------<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;David&nbsp;Hallford&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Fidonet:&nbsp;1:208/103<BR>
<BR>
&nbsp;&nbsp;Andreas&nbsp;Klein<BR>
&nbsp;&nbsp;Fidonet:&nbsp;2:2480/47<BR>
&nbsp;&nbsp;E-mail:&nbsp;&nbsp;akx@gmx.net<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Michael&nbsp;McCabe<BR>
&nbsp;&nbsp;Fidonet:&nbsp;1:297/11<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Odinn&nbsp;Sorensen<BR>
&nbsp;&nbsp;Fidonet:&nbsp;N/A<BR>
&nbsp;&nbsp;E-mail:&nbsp;&nbsp;odinn@goldware.dk<BR>
&nbsp;&nbsp;WWW:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;http://www.goldware.dk<BR>
<BR>
&nbsp;&nbsp;Colin&nbsp;Turner<BR>
&nbsp;&nbsp;Fidonet:&nbsp;2:443/13<BR>
&nbsp;&nbsp;E-mail:&nbsp;&nbsp;ct@piglets.com<BR>
&nbsp;&nbsp;WWW:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;http://www.piglets.com<BR>
<BR>
<BR>
B.&nbsp;History<BR>
----------<BR>
<BR>
&nbsp;&nbsp;&nbsp;Rev.1,&nbsp;19990627:&nbsp;Initial&nbsp;Release.&nbsp;Principal&nbsp;Author&nbsp;David&nbsp;Hallford<BR>
<BR>
<BR>
</TT>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

312
html/ftsc/ftscprod.html
View File

@ -1,312 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>FTSC Product ID List.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<H2><DIV align=center>FTSC Product codes 22 jan 2000</DIV></H2><P>
<PRE>
0000,Fido,MS-DOS,Packer/mailer,Tom_Jennings,1:125/111
0001,Rover,MS-DOS,Packer/mailer,Bob_Hartman,1:104/501
0002,SEAdog,MS-DOS,Packer/mailer,Thom_Henderson,1:107/542.1
0003,WinDog,MS-DOS,Mailer,Solar_Wind_Computing,1:115/333
0004,Slick-150,HP-150,Packer/mailer,Jerry_Bain,????
0005,Opus,MS-DOS,Packer/mailer,Doug_Boone,1:124/4227
0006,Dutchie,MS-DOS,Packer/mailer,Henk_Wevers,2:500/1
0007,WPL_Library,Amiga,Mailer,Russell_McOrmand,1:163/109
0008,Tabby,Macintosh,Packer/mailer,Michael_Connick,1:107/412
0009,SWMail,OS/2,Mailer,Solar_Wind_Computing,1:115/333
000A,Wolf-68k,CPM-68k,Packer/mailer,Robert_Heller,1:321/153
000B,QMM,QNX,Packer/mailer,Rick_Duff,1:167/201
000C,FrontDoor,MS-DOS,Packer/mailer,Joaquim_Homrighausen,2:270/17
000D,GOmail,MS-DOS,Packer,Scott_Green,????
000E,FFGate,MS-DOS,Packer,Ruedi_Kneubuehler,2:301/580
000F,FileMgr,MS-DOS,Packer,Erik_van_Emmerik,2:281/611
0010,FIDZERCP,MS-DOS,Packer,Thorsten_Seidel,2:242/55
0011,MailMan,MS-DOS,Packer,Ron_Bemis,1:124/1113
0012,OOPS,MS-DOS,Packer,Tom_Kashuba,1:322/379
0013,GS-Point,Atari_ST,Packer/mailer,Harry_Lee,1:124/4230
0014,BGMail,????,????,Ray_Gwinn,1:265/104
0015,ComMotion/2,OS/2,Packer/mailer,Michael_Buenter,2:301/602
0016,OurBBS_Fidomailer,MS-DOS/Unix/Coherent,Packer/mailer,Brian_Keahl,1:133/524
0017,FidoPcb,MS-DOS,Packer,Matjaz_Koce,2:380/100
0018,WimpLink,Archimedes,Packer/mailer,Remco_de_Vreugd,2:283/307
0019,BinkScan,MS-DOS,Packer,Shawn_Stoddard,1:362/101
001A,D'Bridge,MS-DOS,Packer/mailer,Chris_Irwin,1:18/68
001B,BinkleyTerm,MS-DOS,Mailer,Vince_Perriello,1:343/491
001C,Yankee,MS-DOS,Packer,Randy_Edwards,????
001D,uuGate,MS-DOS,Packer,Geoff_Watts,3:690/710
001E,Daisy,Apple_][,Packer/mailer,Raymond_&_Ken_Lo,3:700/1
001F,Polar_Bear,????,Packer/mailer,Kenneth_McLeod,1:101/190
0020,The-Box,MS-DOS/Atari_ST,Packer/mailer,Jac_Kersing/Arjen_Lentz,2:283/333
0021,STARgate/2,OS/2,Packer/mailer,Shawn_Stoddard,1:362/101
0022,TMail,MS-DOS,Packer,Larry_Lewis,3:713/600.1701
0023,TCOMMail,MS-DOS,Packer/mailer,Mike_Ratledge,1:372/888
0024,GIGO,MS-DOS,Packer,Jason_Fesler,1:203/7707,,940228
0025,RBBSMail,MS-DOS,Packer,Jan_Terpstra,2:512/10
0026,Apple-Netmail,Apple_][,Packer/mailer,Bill_Fenner,1:129/87
0027,Chameleon,Amiga,Mailer,Juergen_Hermann,2:241/2.12
0028,Majik_Board,MS-DOS,Packer/mailer,Dale_Barnes,1:3601/14.20
0029,QM,MS-DOS,Packer,George_Peace,1:270/101
002A,Point_And_Click,Amiga,Packer,Rob_Tillotson,1:201/40.302
002B,Aurora_Three_Bundler,MS-DOS,Packer,Oliver_McDonald,????
002C,FourDog,MS-DOS,Packer,Shay_Walters,1:376/12
002D,MSG-PACK,MS-DOS,Packer,Tom_Hendricks,1:261/662
002E,AMAX,MS-DOS,Packer,Alan_Applegate,1:104/36
002F,Domain_Communication_System,????,????,Hal_Duprie,1:101/106
0030,LesRobot,????,Packer,Lennart_Svensonn,2:501/2
0031,Rose,MS-DOS,Packer/mailer,Glen_Jackson,1:100/617
0032,Paragon,Amiga,Packer/mailer,Jon_Radoff,1:322/545
0033,BinkleyTerm/oMMM/ST,Atari_ST,Packer/mailer,Bill_Scull,1:363/112,,19951209
0034,StarNet,Atari_ST,Mailer,Eric_Drewry,1:322/566
0035,ZzyZx,MS-DOS,Packer,Jason_Steck,1:124/424
0036,QEcho,MS-DOS,Packer,The_QuickBBS_Group,1:363/1701
0037,BOOM,MS-DOS,Packer,Andrew_Farmer,1:243/1
0038,PBBS,Amiga,Packer/mailer,Todd_Kover,1:261/1028
0039,TrapDoor,Amiga,Mailer,Maximilian_Hantsch,2:310/6
003A,Welmat,Amiga,Mailer,Russell_McOrmand,1:163/109
003B,NetGate,Unix-386,Packer,David_Nugent,3:632/348
003C,Odie,MS-DOS,Mailer,Matt_Farrenkopf,1:105/376
003D,Quick_Gimme,CPM-80/MS-DOS,Packer/mailer,Laeeth_Isaacs,2:254/18
003E,dbLink,MS-DOS,Packer/mailer,Chris_Irwin,1:18/68
003F,TosScan,MS-DOS,Packer,Joaquim_Homrighausen,2:270/17
0040,Beagle,MS-DOS,Mailer,Alexander_Holy,2:310/90
0041,Igor,MS-DOS,Mailer,Harry_Lee,1:124/4230
0042,TIMS,MS-DOS,Packer/mailer,Bit_Bucket_Software,1:104/501
0043,Phoenix,MS-DOS,Packer/mailer,International_Telecommunications,1:296/5,,19930624
0044,FrontDoor_APX,MS-DOS,Packer/mailer,Joaquim_Homrighausen,2:270/17
0045,XRS,MS-DOS,Packer,Mike_Ratledge,1:372/888
0046,Juliet_Mail_System,Amiga,Packer,Gregory_Kritsch,1:163/109.30
0047,Jabberwocky,Macintosh,Packer,Eric_Larson,1:2605/620
0048,XST,MS-DOS,Packer,Wayne_Michaels,1:380/100
0049,MailStorm,Amiga,Packer,Russel_Miranda,1:268/106
004A,BIX-Mail,????,Mailer,Bob_Hartman,1:104/501
004B,IMAIL,MS-DOS,Packer,IMAIL_INC.,2:246/47
004C,FTNGate,MS-DOS,Packer,Jason_Steck,1:104/424
004D,RealMail,MS-DOS,Packer,Taine_Gilliam,1:372/42
004E,Lora-CBIS,MS-DOS,Mailer,Marco_Maccaferri,2:332/402
004F,TDCS,PDP-11,Packer/mailer,Terry_Ebdon,2:254/6
0050,InterMail,MS-DOS,Packer/mailer,Peter_Stewart,1:369/35
0051,RFD,MS-DOS,Packer,Doug_Belkofer,1:234/10
0052,Yuppie!,MS-DOS,Packer,Leo_Moll,2:242/2
0053,EMMA,MS-DOS,Packer,Johan_Zwiekhorst,2:292/100
0054,QBoxMail,QDOS,Packer/mailer,Jan_Bredenbeek,2:283/500
0055,Number_4,MS-DOS,Packer/mailer,Ola_Garstad,2:502/15
0056,Number_5,MS-DOS,Packer/mailer,Ola_Garstad,2:502/15
0057,GSBBS,MS-DOS,Packer,Michelangelo_Jones,1:260/244
0058,Merlin,MS-DOS,Packer/mailer,Mark_Lewis,2:258/25
0059,TPCS,MS-DOS,Packer,Mikael_Kjellstrom,2:201/211
005A,Raid,MS-DOS,Packer,George_Peace,1:270/101
005B,Outpost,MS-DOS,Packer/mailer,Mike_Dailor,????
005C,Nizze,MS-DOS,Packer,Tomas_Nielsen,2:205/202
005D,Armadillo,Macintosh,Packer,Erik_Sea,1:221/109
005E,rfmail,Unix,Packer/mailer,Per_Lindqvist,2:201/332
005F,Msgtoss,MS-DOS,Packer,Mike_Zakharoff,1:343/36
0060,InfoTex,MS-DOS,Packer/mailer,Jan_Spooren,2:292/852
0061,GEcho,MS-DOS,Packer,Gerard_van_der_Land,2:283/555,951209
0062,CDEhost,MS-DOS,Packer,Dennis_D'Annunzio,1:379/28
0063,Pktize,MS-DOS,Packer,Joaquim_Homrighausen,2:270/17
0064,PC-RAIN,MS-DOS,Packer/mailer,Ray_Hyder,1:272/40
0065,Truffle,MS-DOS/OS2,Mailer,Mike_Rissa,2:504/59
0066,Foozle,Amiga,Packer,Peer_Hasselmeyer,2:247/4
0067,White_Pointer,Macintosh,Packer/mailer,Alastair_Rakine,3:680/820
0068,GateWorks,MS-DOS,Packer,Jamie_Penner,1:153/1025
0069,Portal_of_Power,MS-DOS,Mailer,Soren_Ager,2:230/12
006A,MacWoof,Macintosh,Packer/mailer,Craig_Vaughan,1:109/342
006B,Mosaic,MS-DOS,Packer,Christopher_King,1:103/315
006C,TPBEcho,MS-DOS,Packer,Gerd_Qualmann,2:242/1
006D,HandyMail,MS-DOS,Packer/mailer,jim_nutt,1:114/30
006E,EchoSmith,MS-DOS,Packer,Noel_Crow,1:170/409
006F,FileHost,MS-DOS,Packer,Mark_Cole,2:252/186
0070,SFTS,MS-DOS,Packer,Bruce_Anderson,1:3402/6
0071,Benjamin,MS-DOS,Packer/mailer,Stefan_Graf,2:245/4.5436
0072,RiBBS,OS9_(COCO),Packer/mailer,Ron_Bihler,1:104/54
0073,MP,MS-DOS,Packer,Ivan_Leong,6:600/28
0074,Ping,MS-DOS,Packer,David_Nugent,3:632/348
0075,Door2Europe,MS-DOS,Packer/mailer,Michaela_Schoebel,2:247/14
0076,SWIFT,MS-DOS,Packer/mailer,Hanno_van_der_Maas,2:500/2
0077,WMAIL,MS-DOS,Packer,Silvan_Calarco,2:334/100.2
0078,RATS,MS-DOS,Packer,Jason_DeCaro,1:260/205
0079,Harry_the_Dirty_Dog,OS2,Mailer/packer,George_Edwards,3:632/340.7
007A,Maximus-CBCS,MS-DOS/OS2,Packer,Scott_Dudley,1:249/106
007B,SwifEcho,MS-DOS,Packer,Dana_Bell,1:3801/8
007C,GCChost,Amiga,Packer,Davide_Massarenti,2:332/505.3
007D,RPX-Mail,MS-DOS,Packer,Joerg_Wirtgen,2:241/4034
007E,Tosser,MS-DOS,Packer,Albert_Ng,6:700/185
007F,TCL,MS-DOS,Packer,Ulf_Hedlund,2:201/602
0080,MsgTrack,MS-DOS,Packer,Andrew_Farmer,1:243/1
0081,FMail,MS-DOS/DOS_DPMI/OS2/WIN32,Packer,Folkert_Wijnstra,2:283/619
0082,Scantoss,MS-DOS,Packer,Michael_Matter,2:243/44.3443
0083,Point_Manager,Amiga,Packer,Pino_Aliberti,2:335/602.2,,19931012
0084,IMBINK,MS-DOS,Packer,Mike_Hartmann,2:246/48
0085,Simplex,MS-DOS/OS2,Packer,Chris_Laforet,1:152/401
0086,UMTP,MS-DOS,Packer,Byron_Copeland,1:272/26
0087,Indaba,MS-DOS,Packer,Pieter_Muller,5:7102/11
0088,Echomail_Engine,MS-DOS,Packer,Joe_Jared,1:103/200
0089,DragonMail,OS2,Packer,Patrick_O'Riva,1:143/37
008A,Prox,MS-DOS,Packer,Gerhard_Hoogterp,2:283/1.2
008B,Tick,MS-DOS/OS2,Packer,Barry_Geller,1:266/12
008C,RA-Echo,MS-DOS,Packer,Roger_Kirchhoff,2:245/4
008D,TrapToss,Amiga,Packer,Maximilian_Hantsch,2:310/6
008E,Babel,MS-DOS/OS2,Packer,Jorgen_Abrahamsen,2:230/100.9
008F,UMS,Amiga,Packer,Martin_Horneffer,2:242/7.9
0090,RWMail,MS-DOS,Packer,Remko_Westrik,2:285/309.5
0091,WildMail,MS-DOS,Packer,Derek_Koopowitz,1:161/502
0092,AlMAIL,MS-DOS,Packer,Alan_Leung,1:348/207
0093,XCS,MS-DOS,Packer,Rudi_Kusters,2:512/34.4
0094,Fone-Link,MS-DOS,Packer/mailer,Chris_Sloyan,1:269/602
0095,Dogfight,MS-DOS,Packer,Chris_Tyson,2:256/36
0096,Ascan,MS-DOS,Packer,Arjen_van_Loon,2:281/1.397
0097,FastMail,MS-DOS,Packer,Jan_Berends,2:282/5
0098,DoorMan,MS-DOS,Mailer,Christopher_Dean,1:105/70
0099,PhaedoZap,Atari_ST,Packer,Jeff_Mitchell,1:229/422
009A,SCREAM,MS-DOS,Packer/mailer,Jem_Miller,1:147/33
009B,MoonMail,MS-DOS,Packer/mailer,Hasse_Wigdahl,2:206/101
009C,Backdoor,Sinclair_QL,Packer,Erik_Slagter,2:283/500.3
009D,MailLink,Archimedes,Packer/mailer,Jan-Jaap_v._d._Geer,2:500/133.1138
009E,Mail_Manager,MS-DOS,Packer,Andreas_Brodowski,2:241/4006
009F,Black_Star,Xenix_386,Packer/mailer,Jac_Kersing,2:283/333
00A0,Bermuda,Atari_ST/MS-DOS,Packer,Jac_Kersing,2:283/333
00A1,PT,MS-DOS,Packer/mailer,Jerry_Andrew,1:109/426
00A2,UltiMail,MS-DOS,Mailer,Brett_Floren,1:363/1000
00A3,GMD,MS-DOS,Packer,John_Souvestre,1:396/1
00A4,FreeMail,MS-DOS,Packer,Chad_Nelson,1:109/536
00A5,Meliora,MS-DOS,Packer,Erik_van_Riper,1:107/230
00A6,Foodo,CPM-80,Packer/mailer,Ron_Murray,3:690/640.7
00A7,MSBBS,CPM-80,Packer,Marc_Newman,1:106/601
00A8,Boston_BBS,MS-DOS,Packer/mailer,Tom_Bradford,1:101/625
00A9,XenoMail,MS-DOS,Packer/mailer,Noah_Wood,1:284/14
00AA,XenoLink,Amiga,Packer/mailer,Jonathan_Forbes,1:250/642
00AB,ObjectMatrix,MS-DOS,Packer,Roberto_Ceccarelli,2:332/305.1
00AC,Milquetoast,Win3/MS-DOS,Mailer,Vince_Perriello,1:343/491
00AD,PipBase,MS-DOS,Packer,Roberto_Piola,2:334/306
00AE,EzyMail,MS-DOS,Packer,Peter_Davies,3:636/204
00AF,FastEcho,MS-DOS,Packer,Tobias_Burchhardt,2:245/39
00B0,IOS,Atari_ST/TT,Packer,Rinaldo_Visscher,2:280/3.1
00B1,Communique,MS-DOS,Packer,Ian_Harris,3:620/251
00B2,PointMail,MS-DOS,Packer,Michele_Clinco,2:331/302.11
00B3,Harvey's_Robot,MS-DOS,Packer,Harvey_Parisien,1:249/114
00B4,2daPoint,MS-DOS,Packer,Ron_Pritchett,1:376/74
00B5,CommLink,MS-DOS,Mailer,Steve_Shapiro,1:382/35
00B6,fronttoss,MS-DOS,Packer,Dirk_Astrath,2:241/5603
00B7,SysopPoint,MS-DOS,Packer,Rudolf_Heeb,2:243/44
00B8,PTMAIL,MS-DOS,Packer,Arturo_Krogulski,2:341/27.7
00B9,MHS,MS-DOS/OS2/WINNT,Packer/mailer,Matthias_Hertzog,2:301/402,,19940310
00BA,DLGMail,Amiga,Packer,Steve_Lewis,1:114/52
00BB,GatePrep,MS-DOS,Packer,Andrew_Allen,1:382/92
00BC,Spoint,MS-DOS,Packer,Conrad_Thompson,1:130/29.106
00BD,TurboMail,MS-DOS,Packer,B._J._Weschke,1:2606/403
00BE,FXMAIL,MS-DOS,Packer,Kenneth_Roach,1:208/401
00BF,NextBBS,MS-DOS,Packer/mailer,Tomas_Hood,1:352/777
00C0,EchoToss,MS-DOS,Packer,Mikel_Beck,1:107/218
00C1,SilverBox,Amiga,Packer,David_Lebel,1:240/516
00C2,MBMail,MS-DOS,Packer,Ruud_Uphoff,2:500/116.1928
00C3,SkyFreq,Amiga,Packer,Luca_Spada,2:331/106
00C4,ProMailer,Amiga,Mailer,Ivan_Pintori,2:335/311.21
00C5,Mega_Mail,MS-DOS,Packer/mailer,Mirko_Mucko,2:242/94
00C6,YaBom,MS-DOS,Packer,Berin_Lautenbach,3:620/248
00C7,TachEcho,MS-DOS,Packer,Tom_Zacios,1:107/376
00C8,XAP,MS-DOS,Packer,Jeroen_Smulders,2:512/1.8
00C9,EZMAIL,MS-DOS,Packer,Torben_Paving,2:234/41
00CA,Arc-Binkley,Archimedes,Mailer,Geoff_Riley,2:250/208
00CB,Roser,MS-DOS,Packer,Chan_Kafai,6:700/158
00CC,UU2,MS-DOS,Packer,Dmitri_Zavalishin,2:5020/32
00CD,NMS,MS-DOS,Packer/mailer,Michiel_de.Bruijn,2:285/505.2
00CE,BBCSCAN,Archimedes,Packer/mailer,E._G._Snel,2:512/222.17
00CF,XBBS,MS-DOS,Packer,Mark_Kimes,1:380/16
00D0,LoTek_Vzrul,,Packer/mailer,Kevin_Gates,gates@sasknet.sk.ca,19951229,20000122
00D1,Private_Point_Project,MS-DOS,Packer,Oliver_von_Bueren,2:301/701
00D2,NoSnail,MS-DOS,Packer,Eddie_Rowe,1:19/124
00D3,SmlNet,MS-DOS,Packer,Steve_T._Gove,1:106/6
00D4,STIR,MS-DOS,Packer,Paul_Martin,2:250/107.3
00D5,RiscBBS,Archimedes,Packer,Carl_Declerck,2:292/500.10
00D6,Hercules,Amiga,Packer/mailer,Andrew_Gray,1:231/590
00D7,AMPRGATE,MS-DOS,Packer/mailer,Mike_Bilow,1:323/120.1
00D8,BinkEMSI,MS-DOS,Mailer,Tobias_Burchhardt,2:245/39
00D9,EditMsg,MS-DOS,Packer,G._K._Pace,1:374/26
00DA,Roof,Amiga,Packer,Robert_Williamson,1:167/104
00DB,QwkPkt,MS-DOS,Packer,Ross_West,1:250/412
00DC,MARISCAN,MS-DOS,Packer,Mario_Elkati,2:341/14.9
00DD,NewsFlash,MS-DOS,Packer,Chris_Lueders,2:241/5306
00DE,Paradise,MS-DOS,Packer/mailer,Kenneth_Wall,1:300/5
00DF,DogMatic-ACB,N/A,Packer/mailer,Martin_Allard,2:245/48
00E0,T-Mail,MS-DOS,Packer/mailer,Andy_Elkin,2:5030/15
00E1,JetMail,Atari_ST/STE/TT,Packer,Daniel_Roesen,2:243/93.8
00E2,MainDoor,MS-DOS,Packer/mailer,Francisco_Sedano,2:341/20
00E3,Starnet_Products,MS-DOS/OS2,Mailer/Packer,Starnet_Software_Development,1:102/925,,19951209
00E4,BMB,Amiga,Packer,Dentato_Remo,2:335/311.33
00E5,BNP,MS-DOS,Packer,Nathan_Moschkin,1:109/427
00E6,MailMaster,MS-DOS,Packer/mailer,Gary_Murphy,1:130/85
00E7,Mail_Manager_+Plus+,MS-DOS,Packer,Chip_Morrow,1:226/1240
00E8,BloufGate,Atari_ST/Unix,Packer,Vincent_Pomey,2:320/100.2
00E9,CrossPoint,MS-DOS,Packer/mailer,Peter_Mandrella,2:2454/97.80,19920713,19960601
00EA,DeltaEcho,MS-DOS,Packer,Mikael_Staldal,2:201/337
00EB,ALLFIX,MS-DOS,Packer,Harald_Harms,2:512/145
00EC,NetWay,Archimedes,Mailer,Steve_Haslam,2:250/116.3
00ED,MARSmail,Atari_ST,Packer,Folkert_val_Heusden,2:285/750.2,,19940122
00EE,ITRACK,MS-DOS/OS2,Packer,Frank_Prade,2:2480/55,,19990119
00EF,GateUtil,MS-DOS,Packer,Michael_Skurka,1:397/2.1
00F0,Bert,MS-DOS,Packer/mailer,Arnim_Wiezer,2:241/2104.9
00F1,Techno,MS-DOS,Packer,Patrik_Holmsten,2:203/133
00F2,AutoMail,MS-DOS,Packer,Mats_Wallin,2:201/239
00F3,April,Amiga,Packer,Nick_de_Jong,2:282/309.3
00F4,Amanda,MS-DOS,Packer,David_Douthitt,1:121/99.14
00F5,NmFwd,MS-DOS,Packer,Alberto_Pasquale,2:332/504
00F6,FileScan,MS-DOS,Packer,Matthias_Duesterhoeft,2:241/4512.2
00F7,FredMail,MS-DOS,Packer,Michael_Butler,3:712/515
00F8,TP_Kom,MS-DOS,Packer/mailer,Per_Sten,2:201/124
00F9,FidoZerb,MS-DOS,Packer,Ulrich_Schlechte,2:241/3410.12
00FA,!!MessageBase,MS-DOS,Packer/mailer,Holger_Lembke,2:240/500.20
00FB,EMFido,Amiga,Packer,Gary_Glendown,2:249/3.999
00FC,GS-Toss,MS-DOS,Packer,Marco_Bungalski,2:241/2021
00FD,QWKDoor,Atari_ST,Packer,Christian_Limpach,2:270/20.1
00FE,No_product_id_allocated,Any,Packer,No_Author,3:3/20
00FF,16-bit_product_id,Any,Packer/Mailer,No_Author,3:3/20
0100,Reserved,None,None,No_Author,3:3/20,19951209
0101,The_Brake!,Mailer,John_Gladkih,2:5051/16,19951209
0102,Zeus_BBS,Amiga,Mailer,Alex_May,2:441/58.0,19951209
0103,XenoPhobe-Mailer,Msdos/Windows/OS2/Linux,Mailer,Peter_Kling,1:374/969.0,19951209
0104,None,None,None,None,0:0/0,
0105,Terminate,Msdos/Os2/Windows,Mailer/Packer,SerWiz_Comm_&_Bo_Bendtsen,2:254/261,19951209
0106,TeleMail,Msdos,Mailer/Packer,Juergen_Weigelt,2:2453/900,19951209
0107,CMBBS,Msdos/Os2,Mailer/Packer,Christof_Engel,2:2490/5110,19951209
0108,Shuttle,Windows,Mailer/Packer,MCH_Development_&_Marvin_Hart,1:106/500,19951209
0109,Quater,Amiga,Mailer,Felice_Murolo,2:335/206,19951209
010A,Windo,Windows,Mailer,Alan_Chavis,1:147/55,19951209
010B,Xenia,Msdos/Os2,Mailer,Arjen_Lentz,2:283/512,19960601
010C,GMS,AmigaOS,Mailer,Mirko_Viviani,2:331/213,19960601
010D,HNET,Msdos,???,Pedro_Jaramillo,1:102/160,19960601
010E,Shotgun_Professional,Msdos,???,Brent_Shellenberg,1:140/146,19960621
010F,SLIPgate,Msdos,???,Kieran_Morrissey,3:634/376,19960723
0110,BBBS,MSDOS/OS2/NT/Amiga/Unix,Mailer/Packer,Kim_Heino,2:22/222,19980216
0111,NewsGate,Windows/NT,Packer/Gateway,Leilo_denna_Pietra,2:335/244,19980216
01FF,BBBS,MSDOS/OS2/NT/Amiga/Unix,Mailer/Packer,Kim_Heino,2:22/222,19980216
02FF,NewsGate,Windows/NT,Packer/Gateway,Leilo_denna_Pietra,2:335/244,19980216
03FF,Ravel,Macintosh,Mailer/Packer,Cyril_Moorzin,2:5030/700,19980310
04FF,Beemail,Windows,Mailer/Packer,Andrius_Cepaitis,2:470/1,19980310
05FF,QuickToss,DOS,Packer,Sandra_Godinez,1:387/601.3,19980310
06FF,SpaceMail,???,Mailer,Andreas_Habicht,2:244/6121,19980710
07FF,Argus,Windows/NT,Mailer,Max_Masyutin,2:469/84,19990216
08FF,Hurricane,Windows/NT/Solaris,Packer,Paul_Walker,2:254/175.44,19990216
09FF,Hub_Mailer,OS2,Mailer,Viatcheslav_Odintsov,2:5020/181,19990216
0AFF,FDInt,MSDOS,Packer,Colin_Turner,2:443/13,19990216
0BFF,GPMail,OS2,Mailer,Igor_Vanin,2:5030/448,19990216
0CFF,FTrack,NT/OS2,Tracker,Fyodor_Ustinov,2:5020/79,19990313
0DFF,Nice_Tosser,DOS/OS2/Win32,Tosser,Robert_Agababyan,2:5020/234.1,19990518
0EFF,LuckyGate,DOS/OS2/Linux,Packer,Pavel_Gulchouck,2:463/68,19990709
0FFF,McMail,DOS,Mailer,Simon_Slater,2:443/777,20000102
</PRE>
<A HREF="./"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

69
html/ftsc/index.htm
View File

@ -12,15 +12,16 @@
</HEAD> </HEAD>
<BODY> <BODY>
<BLOCKQUOTE> <BLOCKQUOTE>
<div align=right><h5>Last update 13-Jul-2003</h5></div> <div align=right><h5>Last update 11-Jan-2004</h5></div>
<div align=center><h1>Fidonet Technical Standards</h1></div> <div align=center><h1>Fidonet Technical Standards</h1></div>
<h3>Introduction</h3> <h3>Introduction</h3>
<P> <P>
This is an overview of used documents for the development of the MBSE BBS This is an overview of used documents for the development of the MBSE BBS
package. Note that there are more documents, but only the relevant and valid package. Note that there are more documents, but only the relevant and valid
documents are present here. Also note that these documents are just imported documents are shown present here. The documents are not available in this
into html documents without any changes. distribution anymore, you can get these from the <a href="http://www.ftsc.org">FTSC</a>
website.
<P> <P>
Michiel Broek. Michiel Broek.
<P> <P>
@ -28,55 +29,55 @@ Michiel Broek.
<hr> <hr>
<h3>FSC Documents</h3> <h3>FSC Documents</h3>
<ul> <ul>
<li><a href="fsc-0035.html">FSC-0035 Transparant Gateways to and from FidoNet, Michael Shiels</a> <li>FSC-0035 Transparant Gateways to and from FidoNet, Michael Shiels
<li><a href="fsc-0039.html">FSC-0039 A type-2 packet extension proposal M.Howard</a> <li>FSC-0039 A type-2 packet extension proposal M.Howard
<li><a href="fsc-0046.html">FSC-0046 A Product Identifier for FidoNet Message Handlers, J.Homrighausen</a> <li>FSC-0046 A Product Identifier for FidoNet Message Handlers, J.Homrighausen
<li><a href="fsc-0048.html">FSC-0048 A Proposed type-2 packet extension, J.Vroonhof</a> <li>FSC-0048 A Proposed type-2 packet extension, J.Vroonhof
<li><a href="fsc-0049.html">FSC-0049 A proposal for passing domain information during FTS-0006 sessions, B.Hartman</a> <li>FSC-0049 A proposal for passing domain information during FTS-0006 sessions, B.Hartman
<li><a href="fsc-0050.html">FSC-0050 A character set identifier for FidoNet message editors, T.Sundblom</a> <li>FSC-0050 A character set identifier for FidoNet message editors, T.Sundblom
<li><a href="fsc-0053.html">FSC-0053 Specifications for the ^aFLAGS field, J.Homrighausen</a> <li>FSC-0053 Specifications for the ^aFLAGS field, J.Homrighausen
<li><a href="fsc-0056.html">FSC-0056 EMSI/IEMSI Protocol Definition, J.Homrighausen</a> <li>FSC-0056 EMSI/IEMSI Protocol Definition, J.Homrighausen
<li><a href="fsc-0057.html">FSC-0057 Conference Managers - Specifications For Requests, F.Fabris, J.Homrighausen</a> <li>FSC-0057 Conference Managers - Specifications For Requests, F.Fabris, J.Homrighausen
<li><a href="fsc-0059.html">FSC-0059 Newsgroup Interchange within FidoNet, J.Decker</a> <li>FSC-0059 Newsgroup Interchange within FidoNet, J.Decker
<li><a href="fsc-0062.html">FSC-0062 Nodelist Flag indicating Online Times, D.Thomas</a> <li>FSC-0062 Nodelist Flag indicating Online Times, D.Thomas
<li><a href="fsc-0070.html">FSC-0070 Improving FidoNet/UseNet Gating and Dupe checking, F.Arnoud</a> <li>FSC-0070 Improving FidoNet/UseNet Gating and Dupe checking, F.Arnoud
<li><a href="fsc-0072.html">FSC-0072 The HYDRA file transfer protocol, J.Homrighausen, A.Lenz</a> <li>FSC-0072 The HYDRA file transfer protocol, J.Homrighausen, A.Lenz
<li><a href="fsc-0087.html">FSC-0087 File forwarding in FidoNet technology networks, R.Williamson</a> <li>FSC-0087 File forwarding in FidoNet technology networks, R.Williamson
<li><a href="fsc-0088.html">FSC-0088 Compatibility and Link Qualifier Extensions for EMSI Sessions, R.Williamson</a> <li>FSC-0088 Compatibility and Link Qualifier Extensions for EMSI Sessions, R.Williamson
<li><a href="fsc-0091.html">FSC-0091 ISDN nodelist flags (rev.002), A.Lenz</a> <li>FSC-0091 ISDN nodelist flags (rev.002), A.Lenz
<li><a href="fsc-0093.html">FSC-0093 Reduced seen-by lines, F.Ellermann</a> <li>FSC-0093 Reduced seen-by lines, F.Ellermann
</ul> </ul>
<P> <P>
<h3>FSP Documents</h3> <h3>FSP Documents</h3>
<ul> <ul>
<li><a href="fsp-1011.html">FSP-1011 BinkP - a protocol for transferring Fidonet mail over reliable connections, Dima Maloff</a> <li>FSP-1011 BinkP - a protocol for transferring Fidonet mail over reliable connections, Dima Maloff
</ul> </ul>
<P> <P>
<h3>FTA Documents</h3> <h3>FTA Documents</h3>
<ul> <ul>
<li><a href="fta-1005.html">FTA-1005 FTSC Product ID</a> <li>FTA-1005 FTSC Product ID
<li><a href="ftscprod.html">FTSC Product codes list</A> <li>FTSC Product codes list
</ul> </ul>
<P> <P>
<h3>FTS Documents</h3> <h3>FTS Documents</h3>
<ul> <ul>
<li><a href="fts-0001.html">FTS-0001 A basic FidoNet(r) technical standard, R.Bush</a> <li>FTS-0001 A basic FidoNet(r) technical standard, R.Bush
<li><a href="fts-0004.html">FTS-0004 Echomail specification, B.Hartman</a> <li>FTS-0004 Echomail specification, B.Hartman
<li><a href="fts-0006.html">FTS-0006 YOOHOO and YOOHOO/2U2, V.Perriello</a> <li>FTS-0006 YOOHOO and YOOHOO/2U2, V.Perriello
<li><a href="fts-0007.html">FTS-0007 SEAlink protocol extension, P.Becker</a> <li>FTS-0007 SEAlink protocol extension, P.Becker
<li><a href="fts-0008.html">FTS-0008 Bark file-request protocol extension, P.Becker</a> <li>FTS-0008 Bark file-request protocol extension, P.Becker
<li><a href="fts-0009.html">FTS-0009 Message identification and reply linkage, J.Nutt</a> <li>FTS-0009 Message identification and reply linkage, J.Nutt
<li><a href="fts-4001.html">FTS-4001 Addressing Control Paragraphs, Goran Eriksson</a> <li>FTS-4001 Addressing Control Paragraphs, Goran Eriksson
<li><a href="fts-4008.html">FTS-4008 Time zone information (TZUTC)</a> <li>FTS-4008 Time zone information (TZUTC)
<li><a href="fts-4009.html">FTS-4009 Netmail tracking (Via)</a> <li>FTS-4009 Netmail tracking (Via)
<li><a href="fts-5000.html">FTS-5000 The distribution nodelist, David Hallford</a> <li>FTS-5000 The distribution nodelist, David Hallford
<li><a href="fts-5001.html">FTS-5001 Nodelist flags and user flags, David Hallford</a> <li>FTS-5001 Nodelist flags and user flags, David Hallford
</ul> </ul>
<HR> <HR>

5
html/known_bugs.html
View File

@ -14,7 +14,7 @@
</HEAD> </HEAD>
<BODY> <BODY>
<BLOCKQUOTE> <BLOCKQUOTE>
<div align='right'><h5>Last update 09-Nov-2003</h5></div> <div align='right'><h5>Last update 11-Jan-2004</h5></div>
<div align='center'><H1>MBSE BBS - Known bugs.</H1></div> <div align='center'><H1>MBSE BBS - Known bugs.</H1></div>
There are always more bugs, but these are known.... There are always more bugs, but these are known....
@ -29,6 +29,9 @@ slow links and over PPP. This is not a MBSE BBS problem.
sessions and you use a session password you <b>must</b> also set a mail password sessions and you use a session password you <b>must</b> also set a mail password
and these passwords must be the same. This is a side effect of the way FTS-0001 and these passwords must be the same. This is a side effect of the way FTS-0001
handshake works, by sending a small mail packet wich contains the password. handshake works, by sending a small mail packet wich contains the password.
<LI>Some Linux distributions have their glibc libraries compiled wrong, that
will cause the <b>mbtask</b> program to do nothing usefull.
</UL> </UL>
<A HREF="index.htm"><IMG SRC="images/b_arrow.png" ALT="Back" Border="0">Go Back</A> <A HREF="index.htm"><IMG SRC="images/b_arrow.png" ALT="Back" Border="0">Go Back</A>

42
html/setup/global.html
View File

@ -14,7 +14,7 @@
</HEAD> </HEAD>
<BODY> <BODY>
<BLOCKQUOTE> <BLOCKQUOTE>
<div align="right"><h5>Last update 28-Dec-2003</h5></div> <div align="right"><h5>Last update 11-Jan-2004</h5></div>
<div align="center"><H1>MBSE BBS Setup - Global Setup</H1></div> <div align="center"><H1>MBSE BBS Setup - Global Setup</H1></div>
In this setup you can edit all global settings for MBSE BBS. All sections will In this setup you can edit all global settings for MBSE BBS. All sections will
@ -368,33 +368,7 @@ XX,CM and TCP/IP systems (internet) should use the XX,CM,IBN,IFC flags.
<strong>Max. MBytes </strong>Maximum MBytes to request, 0 is unlimited <strong>Max. MBytes </strong>Maximum MBytes to request, 0 is unlimited
</pre> </pre>
<h3>1.15. FTPD Settings.</h3> <h3>1.15. Edit HTML pages setup.</h3>
<p>
A new program is <strong>mbftpd</strong>. This is a replacement for the normal
ftp server for GNU/Linux with special futures for MBSE BBS. This is not working
yet and is not included in the distribution. Setting it up is adviced.
<pre>
<strong>Upload pth </strong>Incoming files (ie. /opt/mbse/ftp/incoming).
<strong>Banner msg </strong>The banner file to display before login.
<strong>Path filter </strong>The legal character in upload filenames.
<strong>Path msg </strong>Message to display if illegal characters in upload.
<strong>Email addr </strong>Your email address.
<strong>Shutdown </strong>Shutdown message if FTP server is closed.
<strong>Readme login </strong>Readme to display after login.
<strong>Readme cwd* </strong>Readme to display after chdir.
<strong>Msg login </strong>Welcome message after login.
<strong>Msg cwd* </strong>Message to display in directory.
<strong>Userslimit </strong>Maximum FTP users allowed.
<strong>Loginfails </strong>Maximum login failures.
<strong>Compress </strong>If compress command is allowed.
<strong>Tar </strong>If tar command is allowed.
<strong>Mkdir ok </strong>If users may create directories.
<strong>Log commands </strong>Log user commands.
<strong>Anonymous </strong>If anonymous login is allowed.
<strong>User mbse </strong>If user <strong>mbse</strong> is allowed. Dangerous!
</pre>
<h3>1.16. Edit HTML pages setup.</h3>
<p> <p>
Here you setup the HTML pages that can be created with the <strong> Here you setup the HTML pages that can be created with the <strong>
mbfile web</strong> command. These are HTML pages of your download mbfile web</strong> command. These are HTML pages of your download
@ -411,23 +385,13 @@ there is no user authentication yet available.
<strong>Link to ftp </strong>The link to the ftp directory. <strong>Link to ftp </strong>The link to the ftp directory.
<strong>URL name </strong>The URL of your webserver. <strong>URL name </strong>The URL of your webserver.
<strong>Charset </strong>The default character set, ISO-8859-1. <strong>Charset </strong>The default character set, ISO-8859-1.
<strong>Table color </strong>The tables background color.
<strong>Header color </strong>The tables header background color.
<strong>Author name </strong>The author name you want in the HTTP headers. <strong>Author name </strong>The author name you want in the HTTP headers.
<strong>Convert command </strong>The graphics convert command. (ImageMagick needed). <strong>Convert command </strong>The graphics convert command. (ImageMagick needed).
<strong>Files/page </strong>The number of files to display per web page. <strong>Files/page </strong>The number of files to display per web page.
<strong>Icon Home </strong>The name of the Home icon file.
<strong>Text Home </strong>The text to display for Home.
<strong>Icon Back </strong>The name of the Back icon file.
<strong>Text Back </strong>The text to display for Back.
<strong>Icon Prev. </strong>The name of the Previous page icon file.
<strong>Text Prev. </strong>The text to display for Previous page.
<strong>Icon Next </strong>The name of the Next page icon file.
<strong>Text Next </strong>The text to display for Next page.
</pre> </pre>
<P> <P>
<h3>1.17. Manager flag Descriptions.</h3> <h3>1.16. Manager flag Descriptions.</h3>
<p> <p>
In this menu you can give the 32 area-/filemgr flags a meaningfull description. In this menu you can give the 32 area-/filemgr flags a meaningfull description.
<p> <p>