home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
MISC
/
STN0306.ZIQ
/
FTSC.TXT
< prev
next >
Wrap
Text File
|
1999-07-08
|
32KB
|
819 lines
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FTS-5000
Revision: 1
Title: THE DISTRIBUTION NODELIST
Author(s): Colin Turner, Andreas Klein, Michael McCabe,
David Hallford, Odinn Sorensen
Revision Date: 27 June 1999
Expiry Date: 17 June 2001
----------------------------------------------------------------------
Contents:
1. Supercessions
2. Purpose
3. Publication and Distribution
4. Contents
5. Nodediff
----------------------------------------------------------------------
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.
Abstract
--------
Current practice for Fidonet Technology Networks (FTN) is to
maintain a nodelist used to store the details of the nodes in
the network, and the network structure.
1. Supercessions
----------------
FTS-0005 superceded and replaced the documents known under the names
of FSC-0002, and FTS-0002.
This document supercedes and replaces FTS-0005, FSC-0009, FSC-0040,
FSC-0075, FSC-0091, and FSP-1012.
2. Purpose
----------
Along with the companion technical standard (FTS-5001) this document
defines the format and content of the nodelist for the FidoNet
International Hobby Network. The FTS-5001 is seperated into two
parts - the first part is a listing of authorized flags and the
second part is a registry of userflags. The registry is used to
prevent a userflag from being used for more than one meaning. The
registry is maintained by the Fidonet Technical Standards Committee
Working Group D (the Nodelist).
3. Publication and Distribution
-------------------------------
The nodelist is published as an ASCII text file named NODELIST.nnn,
where nnn is the day-of-year of the publication date.
For actual distribution, NODELIST.nnn is packed into an archive
file named NODELIST.Pnn, where nn are the last two digits of day-of
-year and P is the compression format used as listed below.
A = .arc
Z = .zip
J = .arj
R = .rar
Since .zip is useable on most computer platforms, it is recommended
that this format be used for distribution of the Distribution
Nodelist.
4. Contents
-----------
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 an end-of-file character, ASCII <EOF>
(1AH).
Comments 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 interest flags defined as follows:
;S This comment is of particular interest to Sysops.
;U This comment is of particular interest to BBS users.
;F This comment should appear in any formatted "Fido List".
;A This comment is of general interest (shorthand for ;SUF).
;E This comment is an error message inserted by a nodelist
generating program.
; 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
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 the
literature, 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 exactly one keyword
approved by the Zone Coordinator Council. Current approved keywords
are:
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, nets, and
nodes within the defined zone.
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
host. 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 subunit within a
multilevel 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. 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,or is a region/zone
independent node which is reachable via IP only. 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> --
Defines a normal node entry.
Field 2 - Zone/Region/Net/Node number
This field contains only numeric digits and is a number in the
range of 1 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, therfore the use of
a 0 in this field is strictly forbidden. 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 must be within their net.
Node numbers must be unique within their region (for regional
independents) or net (for members of a local network). 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.
This is the name by which the node is known.
For IP nodes this field may alternately contain an ip address or
E-Mail address for email tunneling programs.
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 admin-
istrative 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
subfields 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 on the line.
This field may also contain the IP address for an IP node
utilizing the country code of 000.
Field 7 - Baud rate
This field contains the maximum baud rate supported by the node.
(eg: 9600, 14400, 38400, etc)
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 subfields, separated by commas. Each subfield consists
of a flag, possibly followed by a value. The authorized flags
for use in the distribution nodelist are distributed as in
FTS-5001 to facilitate additions and deletions of the authorized
flags without requiring an amendment to this FTS.
FTSC recognizes that the FidoNet Zone Coordinator Council with
the International Coordinator as the ZCC Chairman 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 or Zone
Coordinators may temporarily make changes or additions to the
flags as defined in FTS-5001. The FidoNet International
Coordinator/Zone Coordinators will then consult with FTSC over
the changes needed to FTS-5001 to reflect these temporary
changes.
The following are examples of nodelist data lines:
Host,102,SOCALNET,Los_Angeles_CA,Richard_Mart,1-213-874-9484,2400,XP
,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,
,102,fido.tree.com,Los_Angeles_CA,Bill_Smart,1-213-555-1212,9600,
CM,IP,ITN
5. Nodediff
-----------
With more than twenty thousand nodes as of this date, the nodelist,
even in archive form, is a substantial document (or file). Since
distribution is via electronic file transfer, this file is NOT
routinely distributed. Instead, when a new nodelist is prepared, it
is compared with the previous week's nodelist, and a file containing
only the differences is created and distributed.
The distribution 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. This is used as a first-level confidence check
to insure that the right file is being edited. The second and sub-
sequent lines are editing commands and editing data.
There are three editing commands and all have the same format:
<command><number>
<command> is a 1-letter command; A, C, or D. <number> 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 nn lines from the input file.
The following illustrate how the first few lines of 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 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. 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's CRC.
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.Pnn, where nn are the last two digits of day-of-year
and P is the compression format used as listed below.
A = .arc
Z = .zip
J = .arj
R = .rar
Since .zip is useable on most computer platforms, it is recommended
that this format be used for distribution of the Distribution
Nodediff.
A. References
-------------
[FTS-5] "The distribution nodelist", Ben Baker, Rick Moore.
February 1989. Obsoleted by this document.
[FSC-9] "Nodelist flag Changes draft document", Ray Gwinn, David
Dodell. November 1987. Obsoleted by this document.
[FSC-40] "Extended Modem Handling", Michael Shiels. February 1990.
Obsoleted by this document.
[FSC-75] "ISDN capability flags in the nodelist", Jan Ceuleers.
October 1993. Obsoleted by this document.
[FSC-91] "ISDN nodelist flags", Arjen Lentz.
October 1995. Obsoleted by this document.
[FSP-1012] "Integration of IP Nodes in the nodelist", Lothar Behet
June 1999.
B. Contact Data
---------------
David Hallford
Fidonet: 1:208/103
Andreas Klein
Fidonet: 2:2480/47
E-mail: akx@gmx.net
Michael McCabe
Fidonet: 1:297/11
Odinn Sorensen
Fidonet: N/A
E-mail: odinn@goldware.dk
WWW: http://www.goldware.dk
Colin Turner
Fidonet: 2:443/13
E-mail: ct@piglets.com
WWW: http://www.piglets.com
C. History
----------
Rev.1, 19990627: Initial Release. Principal Author David Hallford
--- BBBS/LiI v3.50 Flag-D
* Origin: Stronghold Enterprises/X - telnet://shx.tzo.net (111:111/0)
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FTS-5001
Revision: 1
Title: NODELIST FLAGS AND USERFLAGS
Author(s): Colin Turner, Andreas Klein, Michael McCabe,
David Hallford, Odinn Sorensen
Revision Date: 27 June 1999
Expiry Date: 27 June 2001
----------------------------------------------------------------------
Contents:
1. Authorized Flags
2. Userflags
----------------------------------------------------------------------
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.
Abstract
--------
Current practice for Fidonet Technology Networks (FTN) is to
maintain a nodelist used to store the details of the nodes in
the network, and the network structure. Flags are used in this
nodelist to aid automatic and manual control of various tasks.
1. Authorized flags
-------------------
Flags authorized for use in the Fidonet nodelist:
A: OPERATING CONDITION FLAGS:
Flag Meaning
CM Node accepts mail 24 hours a day
MO Node does not accept human callers
LO Node accepts calls Only from Listed
FidoNet addresses
B. MODEM FLAGS:
The following flags define modem protocols supported:
Flag Meaning
V21 CCITT V.21 300 bps full duplex
V22 CCITT V.22 1200 bps full duplex
V29 CCITT V.29 9600 bps half duplex
V32 CCITT V.32 9600 bps full duplex
V32b ITU-T V.32 bis 14400 bps full duplex
V32T V.32 Terbo
V33 CCITT V.33
V34 CCITT V.34
HST USR Courier HST
H14 USR Courier HST 14.4
H16 USR Courier HST 16.8
H96 Hayes V9600
MAX Microcom AX/96xx series
PEP Packet Ensemble Protocol
CSP Compucom Speedmodem
ZYX Zyxel series
VFC V.Fast Class
Z19 Zyxel 19,200 modem protocol
V90C ITU-T V.90 modem Client
V90S ITU-T V.90 Server.
X2C US Robotics x2 client.
X2S US Robotics x2 server.
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.
Flag Meaning
MNP Microcom Networking Protocol error correction
of type MNP1 to MNP4
V42 LAP-M error correction w/fallback to MNP
C: COMPRESSION FLAGS:
The following flags define the type(s) of compression of mail
packets supported.
Flag Meaning
MN No compression supported
The following flags define the type(s) of data compression
available.
V42b ITU-T V42bis
D: FILE/UPDATE REQUEST FLAGS:
The following flags indicate the types of file/update requests
supported.
|--------------------------------------------------|
| | Bark | WaZOO |
| |---------------------|---------------------|
| | File | Update | File | Update |
| Flag | Requests | Requests | Requests | Requests |
|------|----------|----------|----------|----------|
| XA | Yes | Yes | Yes | Yes |
| XB | Yes | Yes | Yes | No |
| XC | Yes | No | Yes | Yes |
| XP | Yes | Yes | No | No |
| XR | Yes | No | Yes | No |
| XW | No | No | Yes | No |
| XX | No | No | Yes | Yes |
|--------------------------------------------------|
E: GATEWAY FLAG:
The following flag defines gateways to other domains (networks).
Flag Meaning
Gx..x Gateway to domain 'x..x', where 'x..x` is a string
of alphanumeric characters. Valid values for
'x..x' are assigned by the FidoNet International
Coordinator. Current valid values of 'x..x' may
be found in the notes at the end of the FidoNet
nodelist.
F: MAIL PERIOD FLAGS:
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)
#08 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, eg.
"#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.
G: ISDN CAPABILTY FLAGS:
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 supported, the nodelist speed field should
be 300.
Conversion from old to new ISDN capability flags:
ISDNA -> V110L
ISDNB -> V110H
ISDNC -> X75
H: INTERNET CAPABILITY FLAGS:
FLAG MEANING
IBN - denotes a system that does BINKP
IFC - denotes a system that is capable of RAW or IFCICO
ITN - denote a system that does TELNET
IVM - denotes a system that is capable of VMODEM
IFT - denotes a system that allows FTP
ITX - denotes a system that uses TransX encoding for email
tunneling
IUC - denotes a system that uses UUEncode for email tunneling
IMI - denotes a system which uses MIME encoding for email
tunneling
ISE - denotes a system which supports SEAT receipts for anonymous
mail
IP - denotes a system that can receive TCP/IP connects using a
protocol that is not covered by any other flag.
IEM - is a deprecated flag, and new implementations must not
write it in nodelist entries. This was used as a single
placeholder for the InterNet address of the system if it
supported several transport methods. Instead of placing
the system address in the deprecated form specified below
in each flag, the address would be placed once only in this
flag. Implementations may need to parse this information
from nodelists created with older programs.
Conversion from old Internet capabilty flags to the new flags:
BND -> IBN
TEL -> ITN
TELNET -> ITN
VMD -> IVM
TCP -> IP
The Internet Address should be placed in the BBS name field.
Previous usage has placed the InterNet address as part of the
I-flag (for example ITX:r10_tx@thevision.net); in this format the
flag, colon, and address combined cannot exceed 32 characters.
However, this practice is deprecated, and new implementations must
not place address data in the flag section of the nodelist entry,
implementations may however be required to read this data from the
flag section.
Telnet default port is 23. If the port is not 23 then the port
number must be placed after the ITN flag (eg ITN:60177) if the
Telnet address is part of the ITN flag (eg ITN:farsi.dynip.com) then
the port number should be last (eg ITN:farsi.dynip.com:60177) always
remember that the flag cannot exceed 32 characters total.
The default ports for other protocols are shown below, and changes
from the default port must be flagged in a similar way.
Protocol Flag Default Port
FTP IFT 21
BINKP IBN 24554
RAW/IFCICO IFC 60179
VMODEM IVM 3141
Actual IP addresses can also be placed in the phone number field
using the country code of 000.
I: SYSTEM ONLINE USERFLAGS
The flag Tyz is used by non-CM nodes online not only during ZMH,
y is a letter indicating the start and z a letter indicating the
end of the online period as defined below (times in UTC):
A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,
D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,
V 21:00, v 21:30, W 22:00, w 22:30, X 23:00, x 23:30.
For example TuB shows an online period from 20:30 until 1:00 UTC.
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.
2. Userflags
------------
Registry of Userflags
A. FORMAT OF USER FLAGS
U,x..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. The character "U" must not be
repeated, eg, ",U,XXX,YYY,ZZZ" not ",U,XXX,U,YYY,UZZZ".
The 32 character limitation is per userflag, not for
the total of all userflags.
New implementations must place a comma after the
initial "U" before the user flags. Some
implementations will not place a separating comma
betweent the "U" and the first user flag, but this
practice is deprecated. Implementations should be
prepared to read flags in this format, and must strip
the "U" from the flag before analysis in this case.
Entries following the "U" flag must be of a technical
or administrative nature. While experimentation of new
software functions using this flag is encouraged,
advertisement is strictly prohibited.
For applications other than those shown, or if you
have questions concerning the use of this field, please
contact your Regional or Zone Coordinator.
B: MAIL ORIENTED USER FLAGS:
ZEC Zone EchoMail Coordinator. Not more than one entry
in the zone segment may carry this flag and that entry
must be the current Zone EchoMail Coordinator.
REC Regional EchoMail Coordinator. Not more than one
entry in any region may carry this flag and that entry
must be the current Regional EchoMail Coordinator.
NEC Network EchoMail coordinator. Not more than one entry
in any net may carry this flag and that entry must be
the current Network EchoMail Coordinator of that Net.
SDS Software Distribution System
SMH Secure Mail Hub
NC Network Coordinator. This flag is ONLY to be used by
the Network Coordinator of a net which has split the
duties of NC and Host and the NC does NOT occupy the
Net/0 position in the nodelist.
A. Contact Data
---------------
David Hallford
Fidonet: 1:208/103
Andreas Klein
Fidonet: 2:2480/47
E-mail: akx@gmx.net
Michael McCabe
Fidonet: 1:297/11
Odinn Sorensen
Fidonet: N/A
E-mail: odinn@goldware.dk
WWW: http://www.goldware.dk
Colin Turner
Fidonet: 2:443/13
E-mail: ct@piglets.com
WWW: http://www.piglets.com
B. History
----------
Rev.1, 19990627: Initial Release. Principal Author David Hallford
--- BBBS/LiI v3.50 Flag-D
* Origin: Stronghold Enterprises/X - telnet://shx.tzo.net (111:111/0)