Updated FTS documentation
This commit is contained in:
Michiel Broek
parent
515a2f3df8
commit
60786db623
452
html/ftsc/fts-5000.html
Normal file
452
html/ftsc/fts-5000.html
Normal file
@ -0,0 +1,452 @@
|
|||||||
|
<HTML>
|
||||||
|
<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 FIDONET TECHNICAL STANDARDS COMMITTEE<BR>
|
||||||
|
**********************************************************************<BR>
|
||||||
|
<BR>
|
||||||
|
Publication: FTS-5000<BR>
|
||||||
|
Revision: 1<BR>
|
||||||
|
Title: THE DISTRIBUTION NODELIST<BR>
|
||||||
|
Author(s): Colin Turner, Andreas Klein, Michael McCabe,<BR>
|
||||||
|
David Hallford, Odinn Sorensen<BR>
|
||||||
|
<BR>
|
||||||
|
Revision Date: 27 June 1999<BR>
|
||||||
|
Expiry Date: 17 June 2001<BR>
|
||||||
|
----------------------------------------------------------------------<BR>
|
||||||
|
Contents:<BR>
|
||||||
|
1. Supercessions<BR>
|
||||||
|
2. Purpose<BR>
|
||||||
|
3. Publication and Distribution<BR>
|
||||||
|
4. Contents<BR>
|
||||||
|
5. Nodediff<BR>
|
||||||
|
----------------------------------------------------------------------<BR>
|
||||||
|
<BR>
|
||||||
|
Status of this document<BR>
|
||||||
|
-----------------------<BR>
|
||||||
|
<BR>
|
||||||
|
This document is a Fidonet Standard (FTS).<BR>
|
||||||
|
<BR>
|
||||||
|
This document specifies a Fidonet standard for the Fidonet<BR>
|
||||||
|
community.<BR>
|
||||||
|
<BR>
|
||||||
|
This document is released to the public domain, and may be used,<BR>
|
||||||
|
copied or modified for any purpose whatever.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
Abstract<BR>
|
||||||
|
--------<BR>
|
||||||
|
<BR>
|
||||||
|
Current practice for Fidonet Technology Networks (FTN) is to<BR>
|
||||||
|
maintain a nodelist used to store the details of the nodes in<BR>
|
||||||
|
the network, and the network structure.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
1. Supercessions<BR>
|
||||||
|
----------------<BR>
|
||||||
|
<BR>
|
||||||
|
FTS-0005 superceded and replaced the documents known under the names<BR>
|
||||||
|
of FSC-0002, and FTS-0002.<BR>
|
||||||
|
<BR>
|
||||||
|
This document supercedes and replaces FTS-0005, FSC-0009, FSC-0040,<BR>
|
||||||
|
FSC-0075, FSC-0091, and FSP-1012.<BR>
|
||||||
|
<BR>
|
||||||
|
2. Purpose<BR>
|
||||||
|
----------<BR>
|
||||||
|
<BR>
|
||||||
|
Along with the companion technical standard (FTS-5001) this document<BR>
|
||||||
|
defines the format and content of the nodelist for the FidoNet<BR>
|
||||||
|
International Hobby Network. The FTS-5001 is seperated into two<BR>
|
||||||
|
parts - the first part is a listing of authorized flags and the<BR>
|
||||||
|
second part is a registry of userflags. The registry is used to<BR>
|
||||||
|
prevent a userflag from being used for more than one meaning. The<BR>
|
||||||
|
registry is maintained by the Fidonet Technical Standards Committee<BR>
|
||||||
|
Working Group D (the Nodelist).<BR>
|
||||||
|
<BR>
|
||||||
|
3. Publication and Distribution<BR>
|
||||||
|
-------------------------------<BR>
|
||||||
|
<BR>
|
||||||
|
The nodelist is published as an ASCII text file named NODELIST.nnn,<BR>
|
||||||
|
where nnn is the day-of-year of the publication date.<BR>
|
||||||
|
For actual distribution, NODELIST.nnn is packed into an archive<BR>
|
||||||
|
file named NODELIST.Pnn, where nn are the last two digits of day-of<BR>
|
||||||
|
-year and P is the compression format used as listed below.<BR>
|
||||||
|
A = .arc<BR>
|
||||||
|
Z = .zip<BR>
|
||||||
|
J = .arj<BR>
|
||||||
|
R = .rar<BR>
|
||||||
|
Since .zip is useable on most computer platforms, it is recommended<BR>
|
||||||
|
that this format be used for distribution of the Distribution<BR>
|
||||||
|
Nodelist.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
4. Contents<BR>
|
||||||
|
-----------<BR>
|
||||||
|
<BR>
|
||||||
|
As stated above, NODELIST.nnn is an ASCII text file. It contains<BR>
|
||||||
|
two kinds of lines, comment lines and data lines. Each line is<BR>
|
||||||
|
terminated with an ASCII carriage return and line feed character<BR>
|
||||||
|
sequence, and contains no trailing white-space (spaces, tabs, etc.).<BR>
|
||||||
|
The file is terminated with an end-of-file character, ASCII <EOF><BR>
|
||||||
|
(1AH).<BR>
|
||||||
|
<BR>
|
||||||
|
Comments lines contain a semicolon (;) in the first character<BR>
|
||||||
|
position followed by zero or more alphabetic characters called<BR>
|
||||||
|
"interest flags". A program which processes the nodelist may use<BR>
|
||||||
|
comment interest flags to determine the disposition of a comment<BR>
|
||||||
|
line. The remainder of a comment line (with one exception, treated<BR>
|
||||||
|
below) is free-form ASCII text.<BR>
|
||||||
|
<BR>
|
||||||
|
There are five interest flags defined as follows:<BR>
|
||||||
|
<BR>
|
||||||
|
;S This comment is of particular interest to Sysops.<BR>
|
||||||
|
<BR>
|
||||||
|
;U This comment is of particular interest to BBS users.<BR>
|
||||||
|
<BR>
|
||||||
|
;F This comment should appear in any formatted "Fido List".<BR>
|
||||||
|
<BR>
|
||||||
|
;A This comment is of general interest (shorthand for ;SUF).<BR>
|
||||||
|
<BR>
|
||||||
|
;E This comment is an error message inserted by a nodelist<BR>
|
||||||
|
generating program.<BR>
|
||||||
|
<BR>
|
||||||
|
; This comment may be ignored by a nodelist processor.<BR>
|
||||||
|
<BR>
|
||||||
|
The first line of a nodelist is a special comment line containing<BR>
|
||||||
|
identification data for the particular edition of the nodelist. The<BR>
|
||||||
|
following is an example of the first line of a nodelist:<BR>
|
||||||
|
<BR>
|
||||||
|
;A FidoNet Nodelist for Friday, July 3, 1987 --<BR>
|
||||||
|
Day number 184 : 15943<BR>
|
||||||
|
<BR>
|
||||||
|
This line contains the general interest flag, the day, date, and<BR>
|
||||||
|
day-of-year number of publication, and ends with a 5-digit decimal<BR>
|
||||||
|
number with leading zeros, if necessary. This number is the decimal<BR>
|
||||||
|
representation of a check value derived as follows:<BR>
|
||||||
|
<BR>
|
||||||
|
Beginning with the first character of the second line, a 16-bit<BR>
|
||||||
|
cyclic redundancy check (CRC) is calculated for the entire file,<BR>
|
||||||
|
including carriage return and line feed characters, but not<BR>
|
||||||
|
including the terminating EOF character. The check polynomial<BR>
|
||||||
|
used is the same one used for many file transfer protocols:<BR>
|
||||||
|
<BR>
|
||||||
|
2**16 + 2**12 + 2**5 + 2**0<BR>
|
||||||
|
<BR>
|
||||||
|
The CRC may be used to verify that the file has not been edited. The<BR>
|
||||||
|
importance of this will become evident in the discussion of NODEDIFF<BR>
|
||||||
|
below. CRC calculation techniques are well documented in the<BR>
|
||||||
|
literature, and will not be treated further here.<BR>
|
||||||
|
<BR>
|
||||||
|
The content of the remaining comments in the nodelist are intended<BR>
|
||||||
|
to be informative. Beyond the use of interest flags for distribution<BR>
|
||||||
|
, a processing program need not have any interest in them.<BR>
|
||||||
|
<BR>
|
||||||
|
A nodelist data line contains eight variable length "fields"<BR>
|
||||||
|
separated by commas (,). No space characters are allowed in a data<BR>
|
||||||
|
line, and underscore characters are used in lieu of spaces. The<BR>
|
||||||
|
term "alphanumeric character" is defined as the portion of the ASCII<BR>
|
||||||
|
character set from 20 hex through 7E hex, inclusive. The following<BR>
|
||||||
|
discussion defines the contents of each field in a data line.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
Field 1: Keyword<BR>
|
||||||
|
<BR>
|
||||||
|
The keyword field may be empty, or may contain exactly one keyword<BR>
|
||||||
|
approved by the Zone Coordinator Council. Current approved keywords<BR>
|
||||||
|
are:<BR>
|
||||||
|
<BR>
|
||||||
|
Zone --<BR>
|
||||||
|
Begins the definition of a geographic zone and define its<BR>
|
||||||
|
coordinator. All the data lines following a line with the<BR>
|
||||||
|
"Zone" keyword down to, but not including, the next<BR>
|
||||||
|
occurrence of a "Zone" keyword, are regions, nets, and<BR>
|
||||||
|
nodes within the defined zone.<BR>
|
||||||
|
<BR>
|
||||||
|
Region --<BR>
|
||||||
|
Begins the definition of a geographic region and defines its<BR>
|
||||||
|
coordinator. All the data lines following a line with the<BR>
|
||||||
|
"Region" keyword down to, but not including, the next<BR>
|
||||||
|
occurrence of a "Zone", "Region", or "Host" keyword, are<BR>
|
||||||
|
independent nodes within the defined region.<BR>
|
||||||
|
<BR>
|
||||||
|
Host --<BR>
|
||||||
|
Begins the definition of a local network and defines its<BR>
|
||||||
|
host. All the data lines following a line with the Host<BR>
|
||||||
|
keyword down to, but not including, the next occurrence of<BR>
|
||||||
|
a "Zone", "Region", or "Host" keyword, are local nodes,<BR>
|
||||||
|
members of the defined local network.<BR>
|
||||||
|
<BR>
|
||||||
|
Hub --<BR>
|
||||||
|
Begins the definition of a routing subunit within a<BR>
|
||||||
|
multilevel local network. The hub is the routing focal<BR>
|
||||||
|
point for nodes listed below it until the next occurrence<BR>
|
||||||
|
of a "Zone", "Region", "Host", or "Hub" keyword. The hub<BR>
|
||||||
|
entry MUST be a redundant entry, with a unique number,<BR>
|
||||||
|
for one of the nodes listed below it. This is necessary<BR>
|
||||||
|
because some nodelist processors eliminate these entries<BR>
|
||||||
|
in all but the local network.<BR>
|
||||||
|
<BR>
|
||||||
|
Pvt --<BR>
|
||||||
|
Defines a private node with unlisted number. Private nodes<BR>
|
||||||
|
are only allowed as members of local networks.<BR>
|
||||||
|
<BR>
|
||||||
|
Hold --<BR>
|
||||||
|
Defines a node which is temporarily down,or is a region/zone<BR>
|
||||||
|
independent node which is reachable via IP only. Mail may be<BR>
|
||||||
|
sent to it and is held by its host or coordinator.<BR>
|
||||||
|
<BR>
|
||||||
|
Down --<BR>
|
||||||
|
Defines a node which is not operational. Mail may NOT be<BR>
|
||||||
|
sent to it. This keyword may not be used for longer than<BR>
|
||||||
|
two weeks on any single node, at which point the "down"<BR>
|
||||||
|
node is to be removed from the nodelist.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
<empty> --<BR>
|
||||||
|
Defines a normal node entry.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
Field 2 - Zone/Region/Net/Node number<BR>
|
||||||
|
<BR>
|
||||||
|
This field contains only numeric digits and is a number in the<BR>
|
||||||
|
range of 1 to 32767. If the line had the "Zone", "Region", or<BR>
|
||||||
|
"Host" keyword, the number is the zone, net, or region number,<BR>
|
||||||
|
and the node has an implied node number of 0, therfore the use of<BR>
|
||||||
|
a 0 in this field is strictly forbidden. Otherwise, the<BR>
|
||||||
|
number is the node number. The zone number, region or net number,<BR>
|
||||||
|
and the node number, taken together, constitute a node's FidoNet<BR>
|
||||||
|
address.<BR>
|
||||||
|
<BR>
|
||||||
|
Zone numbers must be unique. Region or net numbers must be<BR>
|
||||||
|
unique within their zone. Hub numbers must be within their net.<BR>
|
||||||
|
Node numbers must be unique within their region (for regional<BR>
|
||||||
|
independents) or net (for members of a local network). Duplicate<BR>
|
||||||
|
node numbers under different hubs within the same net are not<BR>
|
||||||
|
allowed.<BR>
|
||||||
|
<BR>
|
||||||
|
Field 3 - Node name<BR>
|
||||||
|
<BR>
|
||||||
|
This field may contain any alphanumeric characters other than<BR>
|
||||||
|
commas and spaces. Underscores are used to represent spaces.<BR>
|
||||||
|
This is the name by which the node is known.<BR>
|
||||||
|
For IP nodes this field may alternately contain an ip address or<BR>
|
||||||
|
E-Mail address for email tunneling programs.<BR>
|
||||||
|
<BR>
|
||||||
|
Field 4 - Location<BR>
|
||||||
|
<BR>
|
||||||
|
This field may contain any alphanumeric characters other than<BR>
|
||||||
|
commas and spaces. Underscores are used to represent spaces.<BR>
|
||||||
|
This field contains the location of the node. It is usually<BR>
|
||||||
|
expressed as the primary local location (town, suburb, city,<BR>
|
||||||
|
etc.) plus the identifier of the regional geopolitical admin-<BR>
|
||||||
|
istrative district (state, province, department, county,<BR>
|
||||||
|
etc.). Wherever possible, standard postal abbreviations for<BR>
|
||||||
|
the major regional district should be used (IL, BC, NSW, etc.).<BR>
|
||||||
|
<BR>
|
||||||
|
Field 5 - Sysop name<BR>
|
||||||
|
<BR>
|
||||||
|
This field may contain any alphanumeric characters other than<BR>
|
||||||
|
commas and spaces. Underscores are used to represent spaces.<BR>
|
||||||
|
This is the name of the system operator.<BR>
|
||||||
|
<BR>
|
||||||
|
Field 6 - Phone number<BR>
|
||||||
|
<BR>
|
||||||
|
This field contains at least three and usually four numeric<BR>
|
||||||
|
subfields separated by dashes (-). The fields are country code,<BR>
|
||||||
|
city or area code, exchange code, and number. The various parts<BR>
|
||||||
|
of the phone number are frequently used to derive cost and<BR>
|
||||||
|
routing information, as well as what number is to be dialed.<BR>
|
||||||
|
A typical example of the data in a phone number field is 1-800-<BR>
|
||||||
|
555-1212, corresponding to country 1 (USA), area 800 (inbound<BR>
|
||||||
|
WATS), exchange 555, and number 1212.<BR>
|
||||||
|
<BR>
|
||||||
|
Alternatively, this field may contain the notation -Unpublished-<BR>
|
||||||
|
in the case of a private node. In this case, the keyword "Pvt"<BR>
|
||||||
|
must appear on the line.<BR>
|
||||||
|
<BR>
|
||||||
|
This field may also contain the IP address for an IP node<BR>
|
||||||
|
utilizing the country code of 000.<BR>
|
||||||
|
<BR>
|
||||||
|
Field 7 - Baud rate<BR>
|
||||||
|
<BR>
|
||||||
|
This field contains the maximum baud rate supported by the node.<BR>
|
||||||
|
(eg: 9600, 14400, 38400, etc)<BR>
|
||||||
|
<BR>
|
||||||
|
Field 8 - Flags<BR>
|
||||||
|
<BR>
|
||||||
|
This optional field contains data about the specific operation of<BR>
|
||||||
|
the node, such as file requests, modem protocol supported, etc.<BR>
|
||||||
|
Any text following the seventh comma on a data line is taken<BR>
|
||||||
|
collectively to be the flags field. The required format is zero<BR>
|
||||||
|
or more subfields, separated by commas. Each subfield consists<BR>
|
||||||
|
of a flag, possibly followed by a value. The authorized flags<BR>
|
||||||
|
for use in the distribution nodelist are distributed as in<BR>
|
||||||
|
FTS-5001 to facilitate additions and deletions of the authorized<BR>
|
||||||
|
flags without requiring an amendment to this FTS.<BR>
|
||||||
|
<BR>
|
||||||
|
FTSC recognizes that the FidoNet Zone Coordinator Council with<BR>
|
||||||
|
the International Coordinator as the ZCC Chairman is the<BR>
|
||||||
|
ultimate authority over what appears in the FidoNet nodelist.<BR>
|
||||||
|
Also, FTSC is by definition a deliberative body, and adding or<BR>
|
||||||
|
changing a flag may take a considerable amount of time.<BR>
|
||||||
|
Therefore, the FidoNet International Coordinator or Zone<BR>
|
||||||
|
Coordinators may temporarily make changes or additions to the<BR>
|
||||||
|
flags as defined in FTS-5001. The FidoNet International<BR>
|
||||||
|
Coordinator/Zone Coordinators will then consult with FTSC over<BR>
|
||||||
|
the changes needed to FTS-5001 to reflect these temporary<BR>
|
||||||
|
changes.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
The following are examples of nodelist data lines:<BR>
|
||||||
|
<BR>
|
||||||
|
Host,102,SOCALNET,Los_Angeles_CA,Richard_Mart,1-213-874-9484,2400,XP<BR>
|
||||||
|
<BR>
|
||||||
|
,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,<BR>
|
||||||
|
<BR>
|
||||||
|
,102,fido.tree.com,Los_Angeles_CA,Bill_Smart,1-213-555-1212,9600,<BR>
|
||||||
|
CM,IP,ITN<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
5. Nodediff<BR>
|
||||||
|
-----------<BR>
|
||||||
|
<BR>
|
||||||
|
With more than twenty thousand nodes as of this date, the nodelist,<BR>
|
||||||
|
even in archive form, is a substantial document (or file). Since<BR>
|
||||||
|
distribution is via electronic file transfer, this file is NOT<BR>
|
||||||
|
routinely distributed. Instead, when a new nodelist is prepared, it<BR>
|
||||||
|
is compared with the previous week's nodelist, and a file containing<BR>
|
||||||
|
only the differences is created and distributed.<BR>
|
||||||
|
<BR>
|
||||||
|
The distribution file, called NODEDIFF.nnn, where nnn is the<BR>
|
||||||
|
day-of-year of publication, is actually an editing script which will<BR>
|
||||||
|
transform the previous week's nodelist into the current nodelist. A<BR>
|
||||||
|
definition of its format follows:<BR>
|
||||||
|
<BR>
|
||||||
|
The first line of NODEDIFF.nnn is an exact copy of the first line of<BR>
|
||||||
|
LAST WEEK'S nodelist. This is used as a first-level confidence check<BR>
|
||||||
|
to insure that the right file is being edited. The second and sub-<BR>
|
||||||
|
sequent lines are editing commands and editing data.<BR>
|
||||||
|
<BR>
|
||||||
|
There are three editing commands and all have the same format:<BR>
|
||||||
|
<BR>
|
||||||
|
<command><number><BR>
|
||||||
|
<BR>
|
||||||
|
<command> is a 1-letter command; A, C, or D. <number> is a<BR>
|
||||||
|
decimal number greater than zero, and defines the number of<BR>
|
||||||
|
lines to be operated on by the command. Each command appears on<BR>
|
||||||
|
a line by itself. The commands have the following meanings:<BR>
|
||||||
|
<BR>
|
||||||
|
Ann - Add the following nn lines to the output file.<BR>
|
||||||
|
<BR>
|
||||||
|
Cnn - Copy nn unchanged lines from the input to the output file.<BR>
|
||||||
|
<BR>
|
||||||
|
Dnn - Delete nn lines from the input file.<BR>
|
||||||
|
<BR>
|
||||||
|
The following illustrate how the first few lines of NODEDIFF.213<BR>
|
||||||
|
might look:<BR>
|
||||||
|
<BR>
|
||||||
|
;A Friday, July 25, 1986 -- Day number 206 : 27712<BR>
|
||||||
|
D2<BR>
|
||||||
|
A2<BR>
|
||||||
|
;A Friday, August 1, 1986 -- Day number 213 : 05060<BR>
|
||||||
|
;A<BR>
|
||||||
|
C5<BR>
|
||||||
|
<BR>
|
||||||
|
This fragment illustrates all three editing commands. The first line<BR>
|
||||||
|
is the first line from NODELIST.206. The next line says "delete the<BR>
|
||||||
|
first two lines" from NODELIST.206. These are the identification<BR>
|
||||||
|
line and the line following it. The next command says "add the next<BR>
|
||||||
|
two lines" to NODELIST.213. The two data lines are followed by a<BR>
|
||||||
|
command which says "copy five unchanged lines" from NODELIST.206 to<BR>
|
||||||
|
NODELIST .213. Notice that the first line added will ALWAYS contain<BR>
|
||||||
|
the new nodelist's CRC.<BR>
|
||||||
|
<BR>
|
||||||
|
Since only the differences will be distributed, it is important to<BR>
|
||||||
|
insure the accuracy of the newly created nodelist. This is the<BR>
|
||||||
|
function of the CRC mentioned above. It is sufficient for a program<BR>
|
||||||
|
designed to perform the above edits to pick the CRC value from the<BR>
|
||||||
|
first line added to the output file, then compute the CRC of the<BR>
|
||||||
|
rest of the output file. If the two CRCs do not agree, one of the<BR>
|
||||||
|
input files has been corrupted. If they do agree, the probability<BR>
|
||||||
|
is very high (but not 100%) that the output file is accurate.<BR>
|
||||||
|
<BR>
|
||||||
|
For actual distribution, NODEDIFF.nnn is packed into an archive file<BR>
|
||||||
|
named NODEDIFF.Pnn, where nn are the last two digits of day-of-year<BR>
|
||||||
|
and P is the compression format used as listed below.<BR>
|
||||||
|
A = .arc<BR>
|
||||||
|
Z = .zip<BR>
|
||||||
|
J = .arj<BR>
|
||||||
|
R = .rar<BR>
|
||||||
|
Since .zip is useable on most computer platforms, it is recommended<BR>
|
||||||
|
that this format be used for distribution of the Distribution<BR>
|
||||||
|
Nodediff.<BR>
|
||||||
|
<BR>
|
||||||
|
A. References<BR>
|
||||||
|
-------------<BR>
|
||||||
|
<BR>
|
||||||
|
[FTS-5] "The distribution nodelist", Ben Baker, Rick Moore.<BR>
|
||||||
|
February 1989. Obsoleted by this document.<BR>
|
||||||
|
<BR>
|
||||||
|
[FSC-9] "Nodelist flag Changes draft document", Ray Gwinn, David<BR>
|
||||||
|
Dodell. November 1987. Obsoleted by this document.<BR>
|
||||||
|
<BR>
|
||||||
|
[FSC-40] "Extended Modem Handling", Michael Shiels. February 1990.<BR>
|
||||||
|
Obsoleted by this document.<BR>
|
||||||
|
<BR>
|
||||||
|
[FSC-75] "ISDN capability flags in the nodelist", Jan Ceuleers.<BR>
|
||||||
|
October 1993. Obsoleted by this document.<BR>
|
||||||
|
<BR>
|
||||||
|
[FSC-91] "ISDN nodelist flags", Arjen Lentz.<BR>
|
||||||
|
October 1995. Obsoleted by this document.<BR>
|
||||||
|
<BR>
|
||||||
|
[FSP-1012] "Integration of IP Nodes in the nodelist", Lothar Behet<BR>
|
||||||
|
June 1999. <BR>
|
||||||
|
<BR>
|
||||||
|
B. Contact Data<BR>
|
||||||
|
---------------<BR>
|
||||||
|
<BR>
|
||||||
|
David Hallford <BR>
|
||||||
|
Fidonet: 1:208/103<BR>
|
||||||
|
<BR>
|
||||||
|
Andreas Klein<BR>
|
||||||
|
Fidonet: 2:2480/47<BR>
|
||||||
|
E-mail: akx@gmx.net<BR>
|
||||||
|
<BR>
|
||||||
|
Michael McCabe<BR>
|
||||||
|
Fidonet: 1:297/11<BR>
|
||||||
|
<BR>
|
||||||
|
Odinn Sorensen<BR>
|
||||||
|
Fidonet: N/A<BR>
|
||||||
|
E-mail: odinn@goldware.dk<BR>
|
||||||
|
WWW: http://www.goldware.dk<BR>
|
||||||
|
<BR>
|
||||||
|
Colin Turner<BR>
|
||||||
|
Fidonet: 2:443/13<BR>
|
||||||
|
E-mail: ct@piglets.com<BR>
|
||||||
|
WWW: http://www.piglets.com<BR>
|
||||||
|
<BR>
|
||||||
|
C. History<BR>
|
||||||
|
----------<BR>
|
||||||
|
<BR>
|
||||||
|
Rev.1, 19990627: Initial Release. Principal Author David Hallford<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
</TT>
|
||||||
|
|
||||||
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
||||||
|
|
||||||
|
</BODY>
|
||||||
|
</HTML>
|
||||||
402
html/ftsc/fts-5001.html
Normal file
402
html/ftsc/fts-5001.html
Normal file
@ -0,0 +1,402 @@
|
|||||||
|
<HTML>
|
||||||
|
<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 FIDONET TECHNICAL STANDARDS COMMITTEE<BR>
|
||||||
|
**********************************************************************<BR>
|
||||||
|
<BR>
|
||||||
|
Publication: FTS-5001<BR>
|
||||||
|
Revision: 1<BR>
|
||||||
|
Title: NODELIST FLAGS AND USERFLAGS<BR>
|
||||||
|
Author(s): Colin Turner, Andreas Klein, Michael McCabe,<BR>
|
||||||
|
David Hallford, Odinn Sorensen<BR>
|
||||||
|
<BR>
|
||||||
|
Revision Date: 27 June 1999<BR>
|
||||||
|
Expiry Date: 27 June 2001 <BR>
|
||||||
|
----------------------------------------------------------------------<BR>
|
||||||
|
Contents:<BR>
|
||||||
|
1. Authorized Flags<BR>
|
||||||
|
2. Userflags<BR>
|
||||||
|
----------------------------------------------------------------------<BR>
|
||||||
|
<BR>
|
||||||
|
Status of this document<BR>
|
||||||
|
-----------------------<BR>
|
||||||
|
<BR>
|
||||||
|
This document is a Fidonet Standard (FTS).<BR>
|
||||||
|
<BR>
|
||||||
|
This document specifies a Fidonet standard for the Fidonet<BR>
|
||||||
|
community.<BR>
|
||||||
|
<BR>
|
||||||
|
This document is released to the public domain, and may be used,<BR>
|
||||||
|
copied or modified for any purpose whatever.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
Abstract<BR>
|
||||||
|
--------<BR>
|
||||||
|
<BR>
|
||||||
|
Current practice for Fidonet Technology Networks (FTN) is to<BR>
|
||||||
|
maintain a nodelist used to store the details of the nodes in<BR>
|
||||||
|
the network, and the network structure. Flags are used in this<BR>
|
||||||
|
nodelist to aid automatic and manual control of various tasks.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
1. Authorized flags<BR>
|
||||||
|
-------------------<BR>
|
||||||
|
<BR>
|
||||||
|
Flags authorized for use in the Fidonet nodelist:<BR>
|
||||||
|
<BR>
|
||||||
|
A: OPERATING CONDITION FLAGS:<BR>
|
||||||
|
<BR>
|
||||||
|
Flag Meaning<BR>
|
||||||
|
<BR>
|
||||||
|
CM Node accepts mail 24 hours a day<BR>
|
||||||
|
MO Node does not accept human callers<BR>
|
||||||
|
LO Node accepts calls Only from Listed<BR>
|
||||||
|
FidoNet addresses<BR>
|
||||||
|
<BR>
|
||||||
|
B. MODEM FLAGS:<BR>
|
||||||
|
The following flags define modem protocols supported:<BR>
|
||||||
|
<BR>
|
||||||
|
Flag Meaning<BR>
|
||||||
|
<BR>
|
||||||
|
V21 CCITT V.21 300 bps full duplex<BR>
|
||||||
|
V22 CCITT V.22 1200 bps full duplex<BR>
|
||||||
|
V29 CCITT V.29 9600 bps half duplex<BR>
|
||||||
|
V32 CCITT V.32 9600 bps full duplex<BR>
|
||||||
|
V32b ITU-T V.32 bis 14400 bps full duplex<BR>
|
||||||
|
V32T V.32 Terbo<BR>
|
||||||
|
V33 CCITT V.33<BR>
|
||||||
|
V34 CCITT V.34<BR>
|
||||||
|
HST USR Courier HST<BR>
|
||||||
|
H14 USR Courier HST 14.4<BR>
|
||||||
|
H16 USR Courier HST 16.8<BR>
|
||||||
|
H96 Hayes V9600<BR>
|
||||||
|
MAX Microcom AX/96xx series<BR>
|
||||||
|
PEP Packet Ensemble Protocol<BR>
|
||||||
|
CSP Compucom Speedmodem<BR>
|
||||||
|
ZYX Zyxel series<BR>
|
||||||
|
VFC V.Fast Class<BR>
|
||||||
|
Z19 Zyxel 19,200 modem protocol<BR>
|
||||||
|
V90C ITU-T V.90 modem Client <BR>
|
||||||
|
V90S ITU-T V.90 Server. <BR>
|
||||||
|
X2C US Robotics x2 client. <BR>
|
||||||
|
X2S US Robotics x2 server. <BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
The following flags define type of error correction available. A<BR>
|
||||||
|
separate error correction flag should not be used when the error<BR>
|
||||||
|
correction type can be determined by the modem flag. For instance<BR>
|
||||||
|
a modem flag of HST implies MNP.<BR>
|
||||||
|
<BR>
|
||||||
|
Flag Meaning<BR>
|
||||||
|
<BR>
|
||||||
|
MNP Microcom Networking Protocol error correction<BR>
|
||||||
|
of type MNP1 to MNP4<BR>
|
||||||
|
V42 LAP-M error correction w/fallback to MNP<BR>
|
||||||
|
<BR>
|
||||||
|
C: COMPRESSION FLAGS:<BR>
|
||||||
|
<BR>
|
||||||
|
The following flags define the type(s) of compression of mail<BR>
|
||||||
|
packets supported.<BR>
|
||||||
|
<BR>
|
||||||
|
Flag Meaning<BR>
|
||||||
|
<BR>
|
||||||
|
MN No compression supported<BR>
|
||||||
|
<BR>
|
||||||
|
The following flags define the type(s) of data compression<BR>
|
||||||
|
available.<BR>
|
||||||
|
<BR>
|
||||||
|
V42b ITU-T V42bis<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
D: FILE/UPDATE REQUEST FLAGS:<BR>
|
||||||
|
<BR>
|
||||||
|
The following flags indicate the types of file/update requests<BR>
|
||||||
|
supported.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
|--------------------------------------------------|<BR>
|
||||||
|
| | Bark | WaZOO |<BR>
|
||||||
|
| |---------------------|---------------------|<BR>
|
||||||
|
| | File | Update | File | Update |<BR>
|
||||||
|
| Flag | Requests | Requests | Requests | Requests |<BR>
|
||||||
|
|------|----------|----------|----------|----------|<BR>
|
||||||
|
| XA | Yes | Yes | Yes | Yes |<BR>
|
||||||
|
| XB | Yes | Yes | Yes | No |<BR>
|
||||||
|
| XC | Yes | No | Yes | Yes |<BR>
|
||||||
|
| XP | Yes | Yes | No | No |<BR>
|
||||||
|
| XR | Yes | No | Yes | No |<BR>
|
||||||
|
| XW | No | No | Yes | No |<BR>
|
||||||
|
| XX | No | No | Yes | Yes |<BR>
|
||||||
|
|--------------------------------------------------|<BR>
|
||||||
|
<BR>
|
||||||
|
E: GATEWAY FLAG:<BR>
|
||||||
|
<BR>
|
||||||
|
The following flag defines gateways to other domains (networks).<BR>
|
||||||
|
<BR>
|
||||||
|
Flag Meaning<BR>
|
||||||
|
<BR>
|
||||||
|
Gx..x Gateway to domain 'x..x', where 'x..x` is a string<BR>
|
||||||
|
of alphanumeric characters. Valid values for<BR>
|
||||||
|
'x..x' are assigned by the FidoNet International<BR>
|
||||||
|
Coordinator. Current valid values of 'x..x' may<BR>
|
||||||
|
be found in the notes at the end of the FidoNet<BR>
|
||||||
|
nodelist.<BR>
|
||||||
|
<BR>
|
||||||
|
F: MAIL PERIOD FLAGS:<BR>
|
||||||
|
The following flags define the dedicated mail periods supported.<BR>
|
||||||
|
They have the form "#nn" or !nn where nn is the UTC hour the mail<BR>
|
||||||
|
period begins, # indicates Bell 212A compatibility, and !<BR>
|
||||||
|
indicates incompatibility with Bell 212A.<BR>
|
||||||
|
<BR>
|
||||||
|
Flag Meaning<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
#01 Zone 5 mail hour (01:00 - 02:00 UTC)<BR>
|
||||||
|
#02 Zone 2 mail hour (02:30 - 03:30 UTC)<BR>
|
||||||
|
#08 Zone 4 mail hour (08:00 - 09:00 UTC)<BR>
|
||||||
|
#09 Zone 1 mail hour (09:00 - 10:00 UTC)<BR>
|
||||||
|
#18 Zone 3 mail hour (18:00 - 19:00 UTC)<BR>
|
||||||
|
#20 Zone 6 mail hour (20:00 - 21:00 UTC)<BR>
|
||||||
|
<BR>
|
||||||
|
NOTE: When applicable, the mail period flags may<BR>
|
||||||
|
be strung together with no intervening commas, eg. <BR>
|
||||||
|
"#02#09". Only mail hours other than that<BR>
|
||||||
|
standard within a node's zone should be given.<BR>
|
||||||
|
Since observance of mail hour within one's zone is<BR>
|
||||||
|
mandatory, it should not be indicated.<BR>
|
||||||
|
<BR>
|
||||||
|
G: ISDN CAPABILTY FLAGS:<BR>
|
||||||
|
<BR>
|
||||||
|
Nodelist Specification of minimal support required for this flag;<BR>
|
||||||
|
flag any additional support to be arranged via agreement <BR>
|
||||||
|
between users<BR>
|
||||||
|
<BR>
|
||||||
|
V110L ITU-T V.110 19k2 async ('low').<BR>
|
||||||
|
V110H ITU-T V.110 38k4 async ('high').<BR>
|
||||||
|
V120L ITU-T V.120 56k async, layer 2 framesize 259, window 7,<BR>
|
||||||
|
modulo 8.<BR>
|
||||||
|
V120H ITU-T V.120 64k async, layer 2 framesize 259, window 7,<BR>
|
||||||
|
modulo 8.<BR>
|
||||||
|
X75 ITU-T X.75 SLP (single link procedure) with 64kbit/s B<BR>
|
||||||
|
channel; layer 2 max.framesize 2048, window 2, non-ext.<BR>
|
||||||
|
mode (modulo 8); layer 3 transparent (no packet layer).<BR>
|
||||||
|
ISDN Other configurations. Use only if none of the above<BR>
|
||||||
|
fits.<BR>
|
||||||
|
<BR>
|
||||||
|
NOTE: No flag implies another. Each capability MUST be specifically<BR>
|
||||||
|
listed.<BR>
|
||||||
|
If no modem connects are supported, the nodelist speed field should<BR>
|
||||||
|
be 300.<BR>
|
||||||
|
<BR>
|
||||||
|
Conversion from old to new ISDN capability flags:<BR>
|
||||||
|
ISDNA -> V110L<BR>
|
||||||
|
ISDNB -> V110H<BR>
|
||||||
|
ISDNC -> X75<BR>
|
||||||
|
<BR>
|
||||||
|
H: INTERNET CAPABILITY FLAGS: <BR>
|
||||||
|
<BR>
|
||||||
|
FLAG MEANING<BR>
|
||||||
|
<BR>
|
||||||
|
IBN - denotes a system that does BINKP <BR>
|
||||||
|
IFC - denotes a system that is capable of RAW or IFCICO <BR>
|
||||||
|
ITN - denote a system that does TELNET <BR>
|
||||||
|
IVM - denotes a system that is capable of VMODEM <BR>
|
||||||
|
IFT - denotes a system that allows FTP <BR>
|
||||||
|
ITX - denotes a system that uses TransX encoding for email<BR>
|
||||||
|
tunneling<BR>
|
||||||
|
IUC - denotes a system that uses UUEncode for email tunneling <BR>
|
||||||
|
IMI - denotes a system which uses MIME encoding for email<BR>
|
||||||
|
tunneling<BR>
|
||||||
|
ISE - denotes a system which supports SEAT receipts for anonymous<BR>
|
||||||
|
mail<BR>
|
||||||
|
IP - denotes a system that can receive TCP/IP connects using a<BR>
|
||||||
|
protocol that is not covered by any other flag. <BR>
|
||||||
|
IEM - is a deprecated flag, and new implementations must not<BR>
|
||||||
|
write it in nodelist entries. This was used as a single<BR>
|
||||||
|
placeholder for the InterNet address of the system if it<BR>
|
||||||
|
supported several transport methods. Instead of placing<BR>
|
||||||
|
the system address in the deprecated form specified below<BR>
|
||||||
|
in each flag, the address would be placed once only in this<BR>
|
||||||
|
flag. Implementations may need to parse this information<BR>
|
||||||
|
from nodelists created with older programs.<BR>
|
||||||
|
<BR>
|
||||||
|
Conversion from old Internet capabilty flags to the new flags:<BR>
|
||||||
|
<BR>
|
||||||
|
BND -> IBN<BR>
|
||||||
|
TEL -> ITN<BR>
|
||||||
|
TELNET -> ITN<BR>
|
||||||
|
VMD -> IVM<BR>
|
||||||
|
TCP -> IP<BR>
|
||||||
|
<BR>
|
||||||
|
The Internet Address should be placed in the BBS name field.<BR>
|
||||||
|
<BR>
|
||||||
|
Previous usage has placed the InterNet address as part of the<BR>
|
||||||
|
I-flag (for example ITX:r10_tx@thevision.net); in this format the<BR>
|
||||||
|
flag, colon, and address combined cannot exceed 32 characters.<BR>
|
||||||
|
However, this practice is deprecated, and new implementations must<BR>
|
||||||
|
not place address data in the flag section of the nodelist entry,<BR>
|
||||||
|
implementations may however be required to read this data from the<BR>
|
||||||
|
flag section.<BR>
|
||||||
|
<BR>
|
||||||
|
Telnet default port is 23. If the port is not 23 then the port<BR>
|
||||||
|
number must be placed after the ITN flag (eg ITN:60177) if the<BR>
|
||||||
|
Telnet address is part of the ITN flag (eg ITN:farsi.dynip.com) then<BR>
|
||||||
|
the port number should be last (eg ITN:farsi.dynip.com:60177) always<BR>
|
||||||
|
remember that the flag cannot exceed 32 characters total.<BR>
|
||||||
|
<BR>
|
||||||
|
The default ports for other protocols are shown below, and changes<BR>
|
||||||
|
from the default port must be flagged in a similar way.<BR>
|
||||||
|
<BR>
|
||||||
|
Protocol Flag Default Port<BR>
|
||||||
|
<BR>
|
||||||
|
FTP IFT 21<BR>
|
||||||
|
BINKP IBN 24554<BR>
|
||||||
|
RAW/IFCICO IFC 60179<BR>
|
||||||
|
VMODEM IVM 3141<BR>
|
||||||
|
<BR>
|
||||||
|
Actual IP addresses can also be placed in the phone number field<BR>
|
||||||
|
using the country code of 000.<BR>
|
||||||
|
<BR>
|
||||||
|
I: SYSTEM ONLINE USERFLAGS<BR>
|
||||||
|
<BR>
|
||||||
|
The flag Tyz is used by non-CM nodes online not only during ZMH,<BR>
|
||||||
|
y is a letter indicating the start and z a letter indicating the<BR>
|
||||||
|
end of the online period as defined below (times in UTC):<BR>
|
||||||
|
<BR>
|
||||||
|
A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,<BR>
|
||||||
|
D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,<BR>
|
||||||
|
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,<BR>
|
||||||
|
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,<BR>
|
||||||
|
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,<BR>
|
||||||
|
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,<BR>
|
||||||
|
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,<BR>
|
||||||
|
V 21:00, v 21:30, W 22:00, w 22:30, X 23:00, x 23:30.<BR>
|
||||||
|
<BR>
|
||||||
|
For example TuB shows an online period from 20:30 until 1:00 UTC.<BR>
|
||||||
|
<BR>
|
||||||
|
Daylight saving time<BR>
|
||||||
|
<BR>
|
||||||
|
If a node changes online times with respect to UTC when daylight<BR>
|
||||||
|
saving time becomes effective (which would be the case with most<BR>
|
||||||
|
part time nodes), then this is to be taken into account when<BR>
|
||||||
|
assigning this flag. An online times flag assigned to a node should<BR>
|
||||||
|
not be altered for the specific purpose of adjusting due to<BR>
|
||||||
|
daylight saving time, since large difference files (NODEDIFF's)<BR>
|
||||||
|
would result if every node was allowed to do this, e.g. my node<BR>
|
||||||
|
used to be online from 2300 to 0800 in local time, which in winter<BR>
|
||||||
|
is UTC, but in the summer it becomes BST (British Summer Time).<BR>
|
||||||
|
This is one hour ahead of UTC, and the corresponding availability<BR>
|
||||||
|
times of my node during the summer period were 2200 to 0700 UTC.<BR>
|
||||||
|
Therefore my online times flag would have indicated availability<BR>
|
||||||
|
between the hours of 2300 and 0700 UTC, the daily time period<BR>
|
||||||
|
encompassing both times, so the flag would be TXH.<BR>
|
||||||
|
<BR>
|
||||||
|
2. Userflags<BR>
|
||||||
|
------------<BR>
|
||||||
|
<BR>
|
||||||
|
Registry of Userflags<BR>
|
||||||
|
<BR>
|
||||||
|
A. FORMAT OF USER FLAGS<BR>
|
||||||
|
<BR>
|
||||||
|
U,x..x<BR>
|
||||||
|
A user-specified string, which may contain any<BR>
|
||||||
|
alphanumeric character except blanks. This string may<BR>
|
||||||
|
contain one to thirty-two characters of information<BR>
|
||||||
|
that may be used to add user-defined data to a specific<BR>
|
||||||
|
nodelist entry. The character "U" must not be<BR>
|
||||||
|
repeated, eg, ",U,XXX,YYY,ZZZ" not ",U,XXX,U,YYY,UZZZ".<BR>
|
||||||
|
The 32 character limitation is per userflag, not for<BR>
|
||||||
|
the total of all userflags.<BR>
|
||||||
|
<BR>
|
||||||
|
New implementations must place a comma after the<BR>
|
||||||
|
initial "U" before the user flags. Some<BR>
|
||||||
|
implementations will not place a separating comma<BR>
|
||||||
|
betweent the "U" and the first user flag, but this<BR>
|
||||||
|
practice is deprecated. Implementations should be<BR>
|
||||||
|
prepared to read flags in this format, and must strip<BR>
|
||||||
|
the "U" from the flag before analysis in this case.<BR>
|
||||||
|
<BR>
|
||||||
|
Entries following the "U" flag must be of a technical<BR>
|
||||||
|
or administrative nature. While experimentation of new<BR>
|
||||||
|
software functions using this flag is encouraged,<BR>
|
||||||
|
advertisement is strictly prohibited.<BR>
|
||||||
|
<BR>
|
||||||
|
For applications other than those shown, or if you<BR>
|
||||||
|
have questions concerning the use of this field, please<BR>
|
||||||
|
contact your Regional or Zone Coordinator.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
B: MAIL ORIENTED USER FLAGS:<BR>
|
||||||
|
<BR>
|
||||||
|
ZEC Zone EchoMail Coordinator. Not more than one entry<BR>
|
||||||
|
in the zone segment may carry this flag and that entry<BR>
|
||||||
|
must be the current Zone EchoMail Coordinator.<BR>
|
||||||
|
<BR>
|
||||||
|
REC Regional EchoMail Coordinator. Not more than one<BR>
|
||||||
|
entry in any region may carry this flag and that entry<BR>
|
||||||
|
must be the current Regional EchoMail Coordinator.<BR>
|
||||||
|
<BR>
|
||||||
|
NEC Network EchoMail coordinator. Not more than one entry<BR>
|
||||||
|
in any net may carry this flag and that entry must be<BR>
|
||||||
|
the current Network EchoMail Coordinator of that Net.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
SDS Software Distribution System<BR>
|
||||||
|
<BR>
|
||||||
|
SMH Secure Mail Hub<BR>
|
||||||
|
<BR>
|
||||||
|
NC Network Coordinator. This flag is ONLY to be used by<BR>
|
||||||
|
the Network Coordinator of a net which has split the<BR>
|
||||||
|
duties of NC and Host and the NC does NOT occupy the<BR>
|
||||||
|
Net/0 position in the nodelist.<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
A. Contact Data<BR>
|
||||||
|
---------------<BR>
|
||||||
|
<BR>
|
||||||
|
David Hallford <BR>
|
||||||
|
Fidonet: 1:208/103<BR>
|
||||||
|
<BR>
|
||||||
|
Andreas Klein<BR>
|
||||||
|
Fidonet: 2:2480/47<BR>
|
||||||
|
E-mail: akx@gmx.net<BR>
|
||||||
|
<BR>
|
||||||
|
Michael McCabe<BR>
|
||||||
|
Fidonet: 1:297/11<BR>
|
||||||
|
<BR>
|
||||||
|
Odinn Sorensen<BR>
|
||||||
|
Fidonet: N/A<BR>
|
||||||
|
E-mail: odinn@goldware.dk<BR>
|
||||||
|
WWW: http://www.goldware.dk<BR>
|
||||||
|
<BR>
|
||||||
|
Colin Turner<BR>
|
||||||
|
Fidonet: 2:443/13<BR>
|
||||||
|
E-mail: ct@piglets.com<BR>
|
||||||
|
WWW: http://www.piglets.com<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
B. History<BR>
|
||||||
|
----------<BR>
|
||||||
|
<BR>
|
||||||
|
Rev.1, 19990627: Initial Release. Principal Author David Hallford<BR>
|
||||||
|
<BR>
|
||||||
|
<BR>
|
||||||
|
</TT>
|
||||||
|
|
||||||
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
||||||
|
|
||||||
|
</BODY>
|
||||||
|
</HTML>
|
||||||
Reference in New Issue
Block a user