F I D O N E W S Volume 17, Number 18 01 May 2000

F I D O N E W S Volume 17, Number 18 01 May 2000
+----------------------------+---------------------------------------+
| The newsletter of the | ISSN 1198-4589 Published by: |
| FidoNet community | "FidoNews" |
| _ | 1-717-732-6820 1:270/720 |
| / \ | |
| /|oo \ | |
| (_| /_) | |
| _`@/_ \ _ | |
| | | \ \\ | Editor: Douglas Myers, 1:270/720 |
| | (*) | \ )) | [email protected] |
| |__U__| / \// | |
| _//|| _\ / | |
| (_/(_|(____/ | |
| (jm) | Newspapers should have no friends. |
| | -- JOSEPH PULITZER |
+----------------------------+---------------------------------------+

Table of Contents
1. HEADLINES ................................................ 1
2. EDITORIAL ................................................ 2
Where Are We Going? ...................................... 2
3. ARTICLES ................................................. 3
FTS-5000 Draft ........................................... 3
FTS-5001 Draft ........................................... 12
4. COLUMNS .................................................. 25
Ol'WDB: A Friend Told Me ................................. 25
This Weeks Web Page ...................................... 27
5. NET HUMOR ................................................ 29
Signs You're Getting Old ................................. 29
6. COMIX IN ASCII ........................................... 31
Remember These Famous Cows? .............................. 31
7. NOTICES .................................................. 32
Fidonews Editor Still Hangs in There :) .................. 32
8. INTERNET INFO ............................................ 33
Fidonet-related sites .................................... 33
9. FIDONEWS INFO ............................................ 37
Masthead ................................................. 37
FIDONEWS 17-18 Page 1 1 May 2000

=================================================================
HEADLINES
=================================================================

This week's edition is larger than normal, mostly because of my
decision to publish the FTSC material in it's entirety rather than
stretching it across issues. My apologies for the bulk, but I feel
it's important to keep abreast of the way FTSC defines Fidonet.

Of course, our old regulars are in here too :)

-----------------------------------------------------------------

FIDONEWS 17-18 Page 2 1 May 2000

=================================================================
EDITORIAL
=================================================================

Where Are We Going?
Doug Myers

Perhaps this week's editorial is in the same vein as last week's,
but with a touch of yellow journalism. I'm about to utter
blasphemies which, perhaps, will bring the Fidonet Elders from their
chambers tearing their robes from their chest.

The BBS as we know it is a dying animal - it's not coming back in
the old form we grew to know and love. Why not? Simply because
we'll attract no users again - they'll log onto their ISP and play
on the Internet even if they know about BBSes. Why not? The
graphics are better than we ever dreamed about at the height of
BBSing, the variety of activity is greater than we individual sysops
could ever supply, and some areas such as e-business - which can
transform lifestyle - were never even possible with BBSes.

This means that Fidonet can't survive as it is presently structured
- a network of sysops. If we sysops can't attract users, then we'll
have nothing to do and will eventually drift off... and our network
will eventually whither.

Oh, I'm not totally negative here - just trying to address
realities. What it all means is that we've got to redefine
ourselves to continue on. What we had was great - the sense of
community in particular was never, in my humble opinion, never
exceeded even by today's Internet. We've got to find a new role for
ourselves where we can function in the new paradigms.

I don't have answers here, I can merely point out some directions.
I'm hoping some of the readers can take these directions and make
something of them (or possibly point out my errors).

First of all, we've got to operate on the Internet in a new way.
Our current efforts are good, in that they enable us to move mail
and files which would probably be impossible if we tried to operate
strictly through the conventional telephone system. What we don't
do much of right now is to attract new users in the way they are
able to operate - with a plain old preconfigured WEB browser.
Somehow we've got to create WEB sites with the taste and feel of the
old BBSes, drawing at least a small group of users back time after
time just for the sense of community.

Can we do it? I don't know. How about you folks telling me?

-----------------------------------------------------------------

FIDONEWS 17-18 Page 3 1 May 2000

=================================================================
ARTICLES
=================================================================

FTS-5000 Draft

This is the latest draft available to FIDONEWS of the Fidonet
Technical Standards Committee document defining The Distribution
Nodelist. This copy was derived from a message by Colin Turner in
the echo SYSOP.FTSC inviting public comment by May 15, 2000; and
subsequently reported to FIDONEWS by Lesley-Dee Dylan (1:250/515).
Though the period for public comment is over, and though this
document is not in force yet, it and it's accompanying FTS-5001 are
presented in their draft form as information of concern to all
Fidonet Sysops. Minor formatting changes were required to make this
document fit the FIDONEWS format, but due care was exercised to make
no editorial changes to the content.

* note - proposed changes are marked by asterisks
[ comments of Fino Lucrezi are included in square brackets ]

*********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
*********************************************************************

Publication: FTS-5000 - REVIEW COPY - *NOT IN FORCE*
Draft: *Proposed* Revision 2
Title: THE DISTRIBUTION NODELIST
Author(s): Colin Turner, Andreas Klein, Michael McCabe,
David Hallford, Odinn Sorensen, Gino Lucrezi

Draft Date: 22 April 2000
---------------------------------------------------------------------
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
* or copied for any purpose whatever.
* Any modification should be clearly identified as such and called
* with a different name

FIDONEWS 17-18 Page 4 1 May 2000

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 separated
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).

* Unlike most FTSC documents, this one is not only aimed at
* developers, but also at maintainers of Fidonet (and other Fidonet
* Technology Networks) nodelist segments. While nodelist segment
* maintainers should try to be quite strict in their adherence to
* this document, it is recommended that software developers be
* prepared to accept deviations from this standard, especially with
* regard to field and line size.

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
* L = .lzh

Since .zip is usable on most computer platforms, it is recommended
that this format be used for distribution of the Distribution
FIDONEWS 17-18 Page 5 1 May 2000

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 white-space (spaces, tabs, etc.) at all.
The file is terminated with an end-of-file character, ASCII <EOF>
(1AH).
* Except for the above, no control characters (ASCII 0-31) should be
* used in the nodelist.

* Each line shouldn't exceed 157 characters. However, it is
* recommended that software developers be quite liberal, and accept
* unlimited-lenght strings.

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

* Please note that the above line has been split in the sole interest
* of readability. It should appear on just one line.

* This line contains the general interest flag, the week day, full
* date, the 3-digit day-of-year number (also called "Julian date")
* of publication, and ends with a 5-digit decimal check value. The
* Julian date and check value are padded with leading zeros, if
* necessary.
FIDONEWS 17-18 Page 6 1 May 2000

* The check value is 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 first line will certainly be different from the above in the
* case of nodelist segments for individual zones, regions, networks
* or hubs; it will also be different for other Fidonet Technology
* Networks.

* Except for the day number and the CRC, developers shouldn't make
* any assumption on the format of this line. The suggested parsing
* algorithm is to find the last colon in the line, and then scan
* backwards to get the day of issue.

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
FIDONEWS 17-18 Page 7 1 May 2000

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. They are also
* considered part of a network whose number is the same as
* the region number.

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.

Pvt --
Defines a private node with unlisted number. Private nodes
are only allowed as members of local networks.

Hold --
Defines a node which is operational but can't be reached
with a dial-up connection. Mail can be sent to it in care
of its host or coordinator, who will hold it for that node.

Down --
Defines a node which is not operational. Mail may NOT be
sent to it.

[ I removed the two-week limit on being down before removal; I
believe it to be a policy issue, not an FTSC one]

<empty> --
Defines a normal node entry.

* Administrative entries (those with a Zone, Region, Host or Hub
* keyword) MUST be redundant entries for one of the nodes listed
* below them.

* No other content is possible for this field in the master
* Fidonet nodelist; however, private listings can conceivably
* include other kind of entries, by marking them appropriately in
* this field. It is recommended that software parsing nodelists
* ignore any line which has an unknown keyword in this field.

* One such example is the "Point" keyword. It can be used in
* so-called "pointlists" to include entries describing points of
* the Fidonet node immediately preceding. This keyword should
* never be used in the Fidonet nodelist, but it is recommended
* that nodelist parsers recognize it.

Field 2 - Zone/Region/Net/Node number
FIDONEWS 17-18 Page 8 1 May 2000

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 unique within
* their net. The hub number will be treated like an extra node in
* its local network. 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.

* If the entry is marked by a "Point" keyword in the first field,
* this field contains the point number. The address of the "boss"
* node is that of the last regular node entry preceding the point.

Field 3 - Node name

This field may contain any alphanumeric character other than
* commas and spaces. This is the name by which the node is known.
* For IP nodes this field may alternately contain a numeric IP
* address or E-Mail address for email tunneling programs.

Field 4 - Location

This field may contain any alphanumeric character 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 two or more numeric subfields separated by
* dashes (-). The first field is the country code. The rest of the
* phone number should be formatted according to local customs.

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),
FIDONEWS 17-18 Page 9 1 May 2000

* area 800 (area code), exchange 555, and number 1212.

* Alternatively, in the case of a private node, this field may
* contain the notation -Unpublished-. In this case, the keyword
"Pvt" must appear on the line.

* If a nodelist uses "Point" keywords, such entries can also have
* "-Unpublished-" in this field (and will do so almost always).

* This field may also contain the IP address of an IP node
* utilizing the country code of 000. This should only be done in
* exceptional circumstances, since it is almost always better to
* list a fully qualified domain name instead of a numeric IP
* address, which could become obsolete in a matter of hours.

Field 7: Obsolete

* In the past, this field was used to show the maximum modem speed
* supported by the node.

* However, given the number of competing (and incompatible)
* protocols available having the same speed, this function was
* later taken over by modem flags. Today, this field carries no
* relevant information, and is ignored by most software, with
* only one exception. If the node has no analog modem available
* on this line (it is either ISDN-only or IP-only) then it must
* use a value of 300 in this field. If there is an analog modem
* on this line, the value of 9600 is strongly recommended for
* maximum compatibility.

* Values other than 300, 1200, 2400 and 9600 (historically
* accepted by any program) have to be approved by the ZCC before
* being used.

* However, it is recommended that developers accept any 16 bit
* unsigned integer value.

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.

* Each subfield should be long at most 32 characters. It is
* however recommended that software developers recognize and
* process even fields which are longer than this limit.

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.
FIDONEWS 17-18 Page 10 1 May 2000

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
-----------

* 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.

FIDONEWS 17-18 Page 11 1 May 2000

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
* L = .lzh

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.

FIDONEWS 17-18 Page 12 1 May 2000

[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: [email protected]

Michael McCabe
Fidonet: 1:297/11

Odinn Sorensen
Fidonet: N/A
E-mail: [email protected]
WWW: http://www.goldware.dk

Colin Turner
Fidonet: 2:443/13
E-mail: [email protected]
WWW: http://www.piglets.com

C. History
----------

Rev.1, 19990627: Initial Release. Principal Author David Hallford
Rev.2 20000424: Re-draft by Gino Lucrezi, with input from others,
especially Andreas Klein. Major changes:
- notes on parsing line 1
- baud rate
- different use of fields for IP nodes
- notes to developers and maintainers
- notes on pointlists
- notes on line and field limits
- revised definition of "Hold" nodes.
- clarification on hub node numbers
- clarification on point phone numbers
- clarification on the former "speed" field

-----------------------------------------------------------------

FTS-5001 Draft

This artical accompanies the previous one on FTS-5000. The same
FIDONEWS 17-18 Page 13 1 May 2000

preliminary notes apply.

*********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
*********************************************************************

Publication: FTS-5001 - REVIEW COPY - *NOT IN FORCE*
Draft: *Proposed* Revision 2
Title: NODELIST FLAGS AND USERFLAGS
Author(s): Colin Turner, Michael McCabe, David Hallford, Odinn
Sorensen, Gino Lucrezi

Draft Date: 22 April 2000
---------------------------------------------------------------------
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
* or copied for any purpose whatever.
* Any modification should be clearly identified as such and named
* differently.

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
* MN No packet compression supported
FIDONEWS 17-18 Page 14 1 May 2000

* B. MODEM CONNECTION PROTOCOL FLAGS:
The following flags define modem connection protocols supported.
* Please also read section I on flag redundancies.

[ I standardized entries format, and added speeds wherever I could ]

* ITU-T (formerly CCITT) Protocols:

Flag Meaning

* V21 ITU-T V.21 300 bps full duplex
* V22 ITU-T V.22 1.200 bps full duplex
* V29 ITU-T V.29 9.600 bps half duplex
* V32 ITU-T V.32 9.600 bps full duplex
* V32b ITU-T V.32bis 14.400 bps full duplex
* V33 ITU-T V.33
* V34 ITU-T V.34 28.800 bps full duplex
* (this flag also covers so-called V.34+,
* capable of 33.600 bps)
* V90C ITU-T V.90 Client 56.000 bps asymmetric
* V90S ITU-T V.90 Server 56.000 bps asymmetric

* Industry standard protocols:

* Flag Meaning

* V32T V.32 Terbo 28.800 bps
* VFC V.Fast Class 28.800 bps

* Proprietary Protocols:

* Flag Meaning

* HST USR Courier HST 9.600 bps asymmetric
* H14 USR Courier HST 14.400 bps asymmetric
* H16 USR Courier HST 16.800 bps asymmetric
* X2C US Robotics x2 client 56.000 bps asymmetric
* X2S US Robotics x2 server 56.000 bps asymmetric
* ZYX Zyxel 16.800 bps
* Z19 Zyxel 19,200 bps
* H96 Hayes V9600 9.600 bps
MAX Microcom AX/96xx series
PEP Packet Ensemble Protocol
* CSP Compucom Speedmodem

* C: SESSION LEVEL ERROR-CORRECTION AND COMPRESSION FLAGS:

* The following flags define type of error correction and/or data
* compression available. A separate error correction flag should
* not be used when the error correction type can be determined by
* the modem flag. See section I for details.

Flag Meaning
FIDONEWS 17-18 Page 15 1 May 2000

MNP Microcom Networking Protocol error correction
of type MNP1 to MNP4
* V42 ITU-T V.42: LAP-M error correction with fallback
* to MNP 1-4
* V42b ITU-T V.42bis: LAP-M error correction and
* compression with fallback to MNP 1-5

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 |
* | none | No | No | No | No |
+--------------------------------------------------+

* The following software is qualified to
* use the appropriate file request flag
* according to information provided by
* developers:
*
* +-----------------------------------+
* | Flag Software Package |
* |-----------------------------------|
* | XA Frontdoor 1.99b and lower |
* | Frontdoor 2.01 and higher |
* | Dutchie 2.90c |
* | Binkleyterm 2.1 and higher |
* | D'Bridge 1.2 and lower |
* | Melmail |
* | TIMS |
* |-----------------------------------|
* | XB Binkleyterm 2.0 |
* | Dutchie 2.90b |
* |-----------------------------------|
* | XC Opus 1.1 |
* |-----------------------------------|
* | XP Seadog |
* |-----------------------------------|
* | XR Opus 1.03 |
* | Platinum Xpress |
* |-----------------------------------|
FIDONEWS 17-18 Page 16 1 May 2000

* | XW Fido 12N and higher |
* | Tabby |
* | TrapDoor No update processor|
* |-----------------------------------|
* | XX Argus 2.00 and higher |
* | D'Bridge 1.30 and higher |
* | Frontdoor 1.99c/2.00 |
* | InterMail 2.01 |
* | McMail 1.00 |
* | T-Mail |
* | TrapDoor - Update Processor |
* |-----------------------------------|
* | None QMM |
* +-----------------------------------+

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 or the Zone Coordinators Council. They
* will also adequately distribute a list of valid
* values.

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)
* #17 Zone 3 mail hour (17:00 - 18:00 UTC)
#20 Zone 6 mail hour (20:00 - 21:00 UTC)

The above listing of the ZMH for each individual zone is only
given for your convenience. It was correct at the time of this
writing, but could be changed at any time by following the
procedures established in Fidonet policy. The FTSC has no role
in determining the Mail Hour of any Zone. You'll find an
up-to-date list in the comments at the end of the Fidonet
Nodelist.

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
FIDONEWS 17-18 Page 17 1 May 2000

given. Since observance of mail hour within one's zone is
mandatory, it should not be indicated.

* If one node wishes to advertise a much larger mail period, use
* of the T?? flag is recommended, as described in part 2, section
* C.

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 analog 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:

[this is an almost complete rewrite: all lines are to be considered
prefixed by *]

Several different protocols are available to exchange Fidonet
Mail over the Internet, and they are denoted by the following
flags:

Direct Connectivity

Flag Protocol

IBN BINKP (FSP-1011)
IFC RAW protocol as used by ifcico or compatible programs
ITN FTS-0001 over TELNET connection
IVM FTS-0001 over VMODEM connection
IP can receive TCP/IP connects using some protocol not
covered by above flags; see later for another use of this
FIDONEWS 17-18 Page 18 1 May 2000

flag

Indirect Connectivity

Flag Protocol

IFT Packet exchange via FTP
ITX TransX encoding for email tunneling with receipts enabled
IUC uuencoding of mail bundles
IMI MIME encoding of mail bundles
ISE SEAT protocol for Email tunneling with receipts enabled;
should always be accompanied by IUC and/or IMI
IEM other mail tunneling methods not covered by above flags;
see later for another use of this flag

Direct connectivity means that both parties to the mail
exchange must be connected to the internet at the same time,
and communicate in real time. Such a connection is analogous to
a crash-mail connection between two fidonet nodes. Indirect
connectivity protocols require the use of one or more systems
storing information to pass it to a fidonet system. This kind
of connection is analogous to routed mail.

To use any direct connectivity flag, a node must at least be
able to process inbound calls with that protocol during ZMH.
Nodes also listing flags denoting additional online times (CM,
Tyz, !nn and #nn) must also support that protocol during these
additional times.

To use any indirect connectivity flag, a node must connect to
its Internet provider at least once a day.

[Tobias would like to add a requirement for CM nodes to poll
their ISP every hour]

To use the flag for any Email method providing for return
receipts (currently ITX and ISE) a node *must* have them
enabled and send such receipts within 24 hours of receiving a
file.

It should be noted that only some of these Internet based
methods (currently IBN, IFC, ITN, IVM, ITX and ISE) can give
the sender a proof of receipt of a file by the addressee, like
FTS-0001 does. Other methods have no guarantee of reliability,
so they shouldn't be used to transmit critical data.

Also, nodelist segment maintainers should take into account the
presence of at least one of these reliable protocols when
deciding on application for Fidonet membership by nodes without
a dial-up connection.

While to set up a FTS-0001 connection you only need to know the
phone number to call, for an internet connection you'll need
some more information.

When using a direct connectivity protocol (flags IBN, IFC, ITN,
FIDONEWS 17-18 Page 19 1 May 2000

IVM) or FTP (flag IFT) a node needs to identify the Internet
host to connect to. This requires a FQDN (Fully Qualified
Domain Name) and a port number.

This can be specified using the following format:

<flag>[:<fqdn>][:<port#>]

If the port number is not specified, the following defaults are
assumed:

Protocol Flag Default Port

BINKP IBN 24554
RAW/IFCICO IFC 60179
TELNET ITN 23
VMODEM IVM 3141
FTP IFT 21

If a node supports more than one protocol on the same internet
host (thus using the same FQDN), the FQDN should only be listed
once. In this case, the IP flag should be added to the nodelist
entry (even if it wouldn't be needed otherwise), with the
following syntax: IP:<fqdn>

Please note the 32 characters limit on any flag.

As an alternative, the FQDN can be placed in the "Node Name"
field of the nodelist entry.

In general it is better to list a FQDN in the nodelist, and
leave to a DNS (Domain Name Server) the task of "resolving" it,
i.e. translating it to a numeric IP address. However, in some
particular situations it could be preferable to list directly
the IP address. This should only be done with full knowledge of
the possible problems involved. In such cases, the IP address
shouldn't be placed in the flags field, but in the "Node Name"
field. Another possibility (though deprecated in some
countries) is to put it in the "Phone Number" field, prefixed
by a country code of 000 (reserved by ITU-T, and unlikely to be
assigned to any country in the near future), with dashes ("-")
replacing dots ("."). An IP address should never be placed in
the flags section, where it could be misinterpred as a port
number.

Email-based transport methods (ITX, IUC, IMI, ISE, IEM) need
knowledge of an Email address, in the form <username>@<fqdn>.
So, each of these flags has the syntax:
<flag>[:<username>@<fqdn>]
If the same Email addess is used for more than one protocol,
then it should only be listed once. In this case, the IEM flag
should be used (even if it wouldn't be needed otherwise), and
the Email addess should only be stated after this flag.

Some programs can parse Email addresses in the "Node Name"
field. This, however, conflicts with the use of it for holding
FIDONEWS 17-18 Page 20 1 May 2000

an IP address.

The following flags were used in the past. Please note their
"modern" equivalent, and use it in their place:

Old New

BND -> IBN
TEL -> ITN
TELNET -> ITN
VMD -> IVM
TCP -> IP

* I: FLAG REDUNDANCIES

[All the section is new, and should be considered prefixed by * ]

Only the smallest possible set of flags should be used in each
entry.

Since different people might have different perception of modem
flag redundancies, the FTSC decided to provide a standard table.

The relation "implies" means either that the first protocol
requires all the others as a fallback or that to all practical
purposes all modems which have been manufactured until today (and
conceivably even future ones) implemented the other protocols
anyway.

For example, the protocol V.32bis implies V.32 because it's
required as a fallback; on the other hand, V.32Terbo implies
V.32bis because practically all modems with V.32Terbo also had
V.32bis to connect to existing modems, even though it wasn't
required in the protocol specifications.

V32 implies V22
V32B implies V22 V32
V34 implies V22 V32 V32B
V90C implies V22 V32 V32B V34
V90S implies V22 V32 V32B V34

V42 implies MNP
V42B implies V42 MNP

V32T implies V22 V32 V32B
VFC implies V22 V32 V32B

HST implies MNP
H14 implies HST MNP
H16 implies HST H14 MNP V42 V42B

X2C implies V22 V32 V32B V34
X2S implies V22 V32 V32B V34

ZYX implies V22 V32 V32B V42 V42B MNP
FIDONEWS 17-18 Page 21 1 May 2000

Z19 implies V22 V32 V32B V42 V42B MNP ZYX

Please note also that:
. V21 may or may not be supported by modems using higher ITU-T
protocols, so it is never implied; however, this flag is not
really useful, either, so it should only be used if there is a
strong reason to expressely denote such a compatibility;
. the V90C and V90S flags are mutually exclusive;
. the X2C and X2CS flasg are are mutually exclusive;
. no modem has at the same time the US Robotics proprietary
protocols and the ZyXEL ones; so, use of any flag in the group
HST, H14, H16, X2S and X2C is incompatible with any of the ZYX
and Z19 flags, and vice versa.
. all X? flags are mutually exclusive;
. the #??, !??, T?? and CM flags are incompatible with each
other.

2. Userflags
------------

Registry of Userflags

It is impossible to document all user flags in use. The FTSC
makes no attempt at it. This document lists those flags which
got at least some kind of official sanction or were deemed of
technical interest by FTSC.

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.
FIDONEWS 17-18 Page 22 1 May 2000

* Developers should note that the distinction between
* "normal" flags and user flags is a non-technical,
* purely political one. It often happened that a user
* flag was "promoted" to regular status, and the
* reverse could conceivably happen. It is recommended
* that, while parsing nodelist entries, no distinction
* at all be done between the two categories of flags.

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.

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.

SDS Software Distribution System

* SMH Secure Mail Hub - or one of the following variations,
* indication the specific level of the hub:

* NSMH - Net SecureMail Host - only one per net
* RSMH - Region SecureMail Host - only one per region
* ZSMH - Zone SecureMail Host - only one in Zone 1
* ISMH - International SecureMail Host - only one in
Fidonet

* RPK Regional Pointlist Keeper.
* This user-flag identifies the person who compiles the
* region-pointlist (only 1 entry per region allowed)

* NPK Net Pointlist Keeper.
* This user-flag identifies the person who compiles the
* net-pointlist (only 1 entry per net allowed)

* K12 This flag identifies systems offering the full range of
* educational K12-conferences.

* ENC This node accepts inbound encrypted mail and will route
* it like other mail
FIDONEWS 17-18 Page 23 1 May 2000

* CDP This node will accept points auto-created by the
* CD-point software.

* C: SYSTEM ONLINE USERFLAGS

[This section was relocated between user flags]

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.

A. Contact Data
---------------

David Hallford
Fidonet: 1:208/103

Michael McCabe
Fidonet: 1:297/11

Odinn Sorensen
Fidonet: N/A
E-mail: [email protected]
WWW: http://www.goldware.dk

FIDONEWS 17-18 Page 24 1 May 2000

Colin Turner
Fidonet: 2:443/13
E-mail: [email protected]
WWW: http://www.piglets.com

Gino Lucrezi
Fidonet: 2:335/610
E-Mail: [email protected]

B. History
----------

Rev.1, 19990627: Initial Release. Principal Author David Hallford

Rev.2, 20000422: new draft by Gino Lucrezi; major changes:
- reorganization of flags classification
- rewrite for clarification of internet connection
flags
- note on difference between "regular" and "user"
flags
- description of flag redundancies
new draft by Gino Lucrezi with input from others
- removed Andreas Klein from authors
- ENC flag
- distinction of direct and indirect IP
connectivity
- requirement for return recepits with ITX and ISE
- additional requirement for IP-nodes with CM flag
- clarification on some flag redundancies
new draft by Gino Lucrezi with input from others
- corrected Z3MH and added note on changing of
ZMHs

-----------------------------------------------------------------

FIDONEWS 17-18 Page 25 1 May 2000

=================================================================
COLUMNS
=================================================================

Ol'WDB's Column
A Friend Told Me...
[email protected]

When I was quite young, my father had one of the first telephones in
our neighborhood. I remember well, the polished, old case fastened
to the wall and shiny receiver on the side of the box.

I was too little to reach the telephone, but used to listen with
fascination when my mother used to talk to it. Then I discovered
that somewhere inside the wonderful device lived an amazing person -
her name was "Information Please" and there was nothing she did not
know.

"Information Please" could supply anybody's number and the correct
time. My first personal experience with this genie-in-the-bottle
came one day while my mother was visiting a neighbor. Amusing
myself at the tool bench in the basement. I whacked my finger with a
hammer. The pain was terrible, but there didn't seem to be any
reason in crying because there was no one home to give sympathy. I
walked around the house sucking my throbbing finger, finally
arriving at the stairway. The telephone! Quickly, I ran for the
footstool in the parlor and dragged it to the landing. Climbing up,
I unhooked the receiver in the parlor and held it to my ear.

"Information Please," I said into the mouthpiece just above my head.
A click or two and a small clear voice spoke into my ear.

"Information"

"I hurt my finger." I wailed into the phone. The tears came readily
enough now that I had an audience.

"Isn't your mother home?" came the question.

Nobody's home but me," I blubbered.

"Are you bleeding?" the voice asked.

"No," I replied. "I hit my finger with the hammer and it HURTS!

"Can you open your icebox?" she asked. I said I could. "Then take
an ice cube and hold it to your finger," said the voice.

After that, I called "Information Please" for everything. I asked
her for help with my geography and she told me where Philadelphia
was. She helped me with my math. She told me my pet chipmunk, that
I had caught in the park just the day before, would eat fruit and
nuts.

Then, there was the time Petey, our pet canary died. I called
FIDONEWS 17-18 Page 26 1 May 2000

"Information Please" and told her the sad story. She listened, then
said the usual things grown ups say to soothe a child.

But I was un-consoled. I asked her, "Why is it that birds should
sing so beautifully and bring joy to all families, only to end up as
a heap of feathers on the bottom of a cage?"

She must have sensed my deep concern, for she said quietly, "Paul,
always remember that there are other worlds to sing in."

Somehow I felt better.

Another day I was on the telephone. "Information Please."
"Information," said the now familiar voice.

"How do you spell fix?" I asked.

All this took place in a small town in the Pacific northwest. When
I was nine years old, we moved across the country to Boston. I
missed my friend very much. "Information Please" belonged in that
old wooden box back home and I somehow never thought of trying the
tall, shiny new phone that sat on the table in the hall. As I grew
into my teens, the memories of those childhood conversations never
really left me. Often, in moments of doubt and perplexity I would
recall the serene sense of security I had then. I appreciated now
how patient, understanding and kind she was to have spent her time
on a little boy.

A few years later, on my way west to college, my plane put down in
Seattle. I had about half-an-hour or so between planes. I spent 15
minutes or so on the phone with my sister, who lived there now.
Then, without thinking what I was doing, I dialed my hometown
operator and said, "Information, please."

Miraculously, I heard the small, clear voice I knew so well.

"Information."

I hadn't planned this, but I heard myself saying, "Could you please
tell me how to spell fix?"

There was a long pause. Then came the soft spoken answer, "I guess
your finger must have healed by now."

I laughed, "So it's really still you," I said. "I wonder if you
have any idea how much you meant to me during that time."

"I wonder," she said, "if you know how much your calls meant to me.
I never had any children and I used to look forward to your calls."

I told her how often I had thought of her over the years and I asked
if I could call her again when I came back to visit my sister.

"Please do," she said. "Just ask for Sally."

Three months later I was back in Seattle. A different voice
FIDONEWS 17-18 Page 27 1 May 2000

answered, "Information."

I asked for Sally. "Are you a friend?" she asked.

"Yes, I'm Paul, a very old friend," I answered.

"I'm sorry to have to tell you this," she said.

"Sally had been working part time the last few years because she was
sick. She died five weeks ago."

Before I could hang up she said, "Wait a minute. Did you say your
name was Paul?"

"Yes."

"Well, Sally left a message for you. She wrote it down in case you
called. Let me read it to you." The note said, "Tell him I still
say there are other worlds to sing in. He'll know what I mean."

I thanked her and hung up. I know what Sally meant.

**********

Never underestimate the impression you may make on others, two years
to nineteen...even beyond that age.... I hope I have touched your
life today, even though these were the words of a friend, to a
friend who sent them to me.

-----------------------------------------------------------------

This Weeks Web Page
by Frank Vest
1:124/6308(.1)

This weeks page is the NET103 site.

Where: http://www.webworldinc.com/club103/

Unusual thing is that this page doesn't have a header announcing
that it is the Net103 page. It does have a nice graphic that shows
the world with an animated connection to the main Net feed and
distribution to the Hubs in the Net.

Under this is are several links to pages and sites. If you want to
see what Joe Jared's page looks like, there's a link to it. :) Most
of the links are to pages telling about the various BBS' in the Net,
but there is a Telnet link to Joe's BBS. Where he got the name for
his BBS must be a good story. :-))

Under the list of links are three links. They give information and
credits. There's also the E-Mail to the Webmaster.

All in all, this is a simple site. Not a lot of stuff on it, but it
FIDONEWS 17-18 Page 28 1 May 2000

does have information and links. The Telnet is nice and was actually
not real slow.

If you live in the Net103 area, drop by. If you don't live in the
area, drop in anyway and say hi. Telnet in and mess around or check
out the links.

Till next week,

Frank
[email protected]

-----------------------------------------------------------------

FIDONEWS 17-18 Page 29 1 May 2000

=================================================================
NET HUMOR
=================================================================

Signs You're Getting Old
Thanks to Old Roy Reed

1. You're asleep, but others worry that you're dead.

2. Your back goes out more than you do.

3. You quit trying to hold your stomach in, no matter who walks into
the room.

4. You buy a compass for the dash of your car/truck.

5. You are proud of your lawn mower

6. Your best friend is dating someone half their age, and isn't
breaking any laws.

7. Your arms are almost too short to read the newspaper.

8. You sing along with the elevator music.

9. You would rather go to work than stay home sick.

10. You enjoy hearing about other people's operations.

11. You no longer think of speed limits as a challenge.

12. People call at 9:00 p.m. and ask, "Did I wake you?"

13. You answer a question with, "Because I said so."

14. You send money to PBS.

15. The end of your tie doesn't come anywhere near the top of your
pants.

16. You take a metal detector to the beach.

17. You know what the word "equity" means.

18. You can't remember the last time you laid on the floor to watch
television.

19. Your ears are hairier than your head.

20. You talk about "good grass" and you're referring to someone's
lawn.

21. You get into a heated argument about pension plans.

22. You got cable for The Weather Channel.
FIDONEWS 17-18 Page 30 1 May 2000

23. You can go bowling without drinking.

24. You have a party and the neighbors don't even realize it.

25. People send you this list.

-----------------------------------------------------------------

FIDONEWS 17-18 Page 31 1 May 2000

=================================================================
COMIX IN ASCII
=================================================================

Remember These Famous Cows?

( )
PRISON# # # # # ||||||
# # # # #(_#) # (OO)
# # # # #(o#) # /------------\___/
# #/-#--#--#-\# # / | |||
# # |# # #||# # / || |||
# *# |#--#--#||# # * ||----------|||
# # ^# # #^^# # ^^ ^^
The Bakker Cows

-----------------------------------------------------------------

FIDONEWS 17-18 Page 32 1 May 2000

=================================================================
NOTICES
=================================================================

Fidonews Editor Still Hangs in There :)
Doug Myers

Contrary to my announcement last week, I did not undergo my
angioplasty last Monday as scheduled. Doctors put off the procedure
because I had an infected cyst on my back, electing instead to
surgically remove it and put me on antibiotics. However, they
reacheduled me for last Friday, so I'm out of the hospital as of
Saturday.

The angioplasty went better than expected, as the doctors were only
expecting to clear the blockage to one of the four blocked blood
vessels in my heart; instead they were able to clear three of four.
I'll be returning to work (with some restrictions) Monday as this
edition is released, so there'll be no economic hardship... and
hopefully improved health for years to come.

My hat's off to modern medical science. Fifteen years ago, my only
alternative would have been open heart surgery followed by three
months of disability while recuperating. Angioplasty, by
comparison, is a minor procedure.

-----------------------------------------------------------------

FIDONEWS 17-18 Page 33 1 May 2000

=================================================================
INTERNET INFO
=================================================================

! = New entries this week
? = not responding
?? = unknown content, doesn't look like fidonet

. -- -- -- -- --- -- -- -- -- .
| FIDONET-RELATED SITES |
` -- -- -- -- --- -- -- -- -- '
Last update: April 17, 2000

FidoNet
Homepage: http://www.fidonet.org
FidoNews: http://www.fidonews.org [HTML]
ftp://ftp.nwstar.com/fidonet/fidonews/
ftp://ftp.sstar.com/fidonet/fnews/
Echolist: http://www.baltimoremd.com/echolist/
Echomail links: http://www.osirusoft.com/fidonet/fidoip.html
SDS Files: http://fidobbs.dk/download (Web Access to SDS)
FTSC page: http://www.ftsc.org/
General: http://www.writebynight.com/fidonet.html

List server:
http://www.onelist.com/subscribe.cgi/fidonet-discussion

Zone 1: http://www.z1.fidonet.org
Region 10: http://www.psnw.com/~net205/region10.html
http://www.tnl-online.com/andy/rgn10.htm
Net 103: http://www.webworldinc.com/club103/
Net 203: http://www.geocities.com/Area51/8687/net203index.html
Region 11: http://oeonline.com/~garyg/region11/
Net 2410: http://oeonline.com/~garyg/net2410/
Region 12: http://sparkys.dyndns.org
Region 13: http://www.net264.org/r13.htm
Net 264: http://www.net264.org/
Net 275: http://www.homershut.net/~mahoover/net275/
Region 14: http://www.ouijabrd.com/region14
Net 282: http://www.rxn.com/~net282/
Region 15: <vacant>
Region 16: <vacant>
Region 17: http://www.nwstar.com/~region17/
Region 18: http://techshop.pdn.net/fido/

Region 19: <Vacant>
Net 124: http://www.startext.net/np/net124
http://texoma.net/~flv
Net 130: http://www.startext.net/homes/net130
Net 393: http://www.chatter.com/~wb/

Zone 2: http://www.z2.fidonet.org
ftp://ftp.sstar.com/fidonet/zone2 (Z2 nodelists etc.)
Region 20: http://www.fidonet.pp.se (in Swedish)
Region 23: http://www.fido.dk (in Danish)
FIDONEWS 17-18 Page 34 1 May 2000

Region 24: http://www.swb.de/personal/flop/gatebau.html (German)
Fido-IP: http://home.nrh.de/fido/ (English/German)
Region 25: http://www.literary.freeserve.co.uk/net2502/
Region 26: http://www.nemesis.ie
REC 26: http://www.nrgsys.com/orb
Region 27: http://telematique.org/ft/r27.htm
Region 29: http://www.rtfm.be/fidonet/ (French)
http://Welcome.to/skynetbbs/
Region 30: http://www.fidonet.ch (German)
? Region 33: http://www.fidoitalia.net (Italian)
Region 34: http://www.pobox.com/cnb/r34.htm (Spanish)
REC34: http://www.geocities.com/SiliconValley/4552/
Region 36: http://www.geocities.com/SiliconValley/7207/
Region 38: http://public.st.carnet.hr/~blagi/bbs/adriam.html
Region 41: http://www.fidonet.gr (Greek/English)
Region 42: http://www.fido.cz
! Net422: http://www.fido.sk (Slovak/English)
Region 50: http://www.fido7.com/ (Russian)
Net 5010: http://fido.tu-chel.ac.ru/ (Russian)
Net 5015: http://www.fido.nnov.ru/ (Russian)
Net 5028: http://5028.yaroslavl.ru/
Net 5030: http://kenga.ru/fido/ (Russian & English)
Net 5049: http://www.n5049.z2.fidonet.org (English/Russian)
?? Net 5085: http://www.fidonet.uz/ (Russian)

Zone 3: http://www.z3.fidonet.org

Zone 4:
Region 80: http://fidobrasil.8m.com (Portuguese)
Region 90:
Net 904: http://members.tripod.com/~net904 (Spanish)

Zone 5: http://www.eastcape.co.za/fidonet/

Zone 6: http://www.z6.fidonet.org
Region 65: http://www.cfido.com/fidonet/cfidochina.html
(Chinese)

Fidonet Via Internet Hubs

See also: http://www.osirusoft.com/fidoip.html

a @ preceding an individual's name implies a virtual email
address. The email is translated as follows
[email protected] will automatically route to the
appropriate individual's email. Anyone in this list will
also receive routed notice of this feature. In my case, it
would still be [email protected], but you get the idea.

Also, as information is provided to me, I will be adding a
latency field to each node, which is defined as the maximum
time between when the message is received, and when it is
sent on to other nodes, or available to be sent onward,
defined in minutes. A latency of ! implies that there is an
immediate response, and an attempt to deliver immediately
FIDONEWS 17-18 Page 35 1 May 2000

after processing, or a "MinuteMail System", as it were.

v-email flag [email protected]
| email address or
Node# | Operator | Facilities (*) | Speed,| Basic Rate
| | |latency|
-----------+-------------------+----------------+-------+------------
Zone 1 | | | |
10/3 @ Brenda Donovan | FTP,UUE,BinkP | 384K,30| n/c
10/345 @ Todd Cochrane | FTP,BinkP,VMOT | T1,! | n/c
12/12 @ Ken Wilson | FTP | T1 | $24mo.
13/25 @ Jim Balcom | FTP | 56k | $20mo.
103/5 @ Mark Luetger | BinkP | 384k,!| n/c
103/153 @ Michael Box | BinkP | aDSL,!| n/c
103/301 @ Joe Jared | BinkP,FTP | 384k,!| n/c
103/401 @ Warren Bonner | BinkP | aDSL,!| n/c
105/8 | Russ Johnson | FTP,BinkP,VMoT | 384k | n/c
105/72 @ Larry James | FTP, BinkP | aDSL | $50/yr
106/1 @ Matt Bedynek | BinkP, FTP | 128k | n/c
106/6018 | Lawrence Garvin | FTP, VMoT | aDSL,60| n/c
107/453 @ Jeffrey Estevez| FTP,BinkP,VMoT,UUE| 56k,60| $10 mo.
140/1 @ Bob Seaborn | FTP,BinkP | T3,30 | $5/$16
167/133 | Stephen Monteith | BinkP | 128k+ | n/c
211/417 @ Korombos | BinkP,UUE,FTP | T1 | n/c
218/109 @ Matt Munson | BinkP,UUE | 33.6k | n/c
244/2 | Kari Suomela | FTP,VMoT,BinkP,UUE| T1,! | $25.00/mo
246/160 @ Mason Vye | FTP, UUE | 56K | n/c
271/140 @ Tom Barstow | UUE,FTP | T1 | n/c
280/169 | Brian Greenstreet | FTP | 33.6 | $2mo.
342/3 @ Richard Dodsworth | BinkP,FTP | 128K+ | n/c
395/670 | Arthur Stark | BinkD,FTP | 128k | n/c
396/1 @ John Souvestre | FTP,VMoT | T1,10 | $5/mo
396/45 | Marc Lewis | UUE | 33.6 | $26/yr
2604/104 @ Jim Mclaughlin | FTP,VMoT,UUE | 33.6 | $1mo
2613/404 @ David Moufarrege | BinkP,FTP,VMoT | 128k+,!| n/c
2624/306 @ David Calafrancesco | VMoT | 33.6 | n/c
3613/2 @ [email protected] | UUE | 28.8 | n/c
3632/84 | Robert Todd |FTP,VMoT,UUE,BinkP | 57.6k | n/c
3639/93 @ Ross Cassell | FTP, BinkP |128K+,!| n/c
3651/9 @ Jerry Gause | FTP,VMoT | 33.6 | $3/$6
--------------------------------------------------------------
Zone 2 |
20/11 | Henrik Lindhe | BinkP | ??? | n/c
31/1 | Gabriel Plutzar | BinkP | T1+ | n/c
203/600 | Mikael Karlsson | UUE | 64k | n/c
221/360 @ Tommi Koivula | BinkP,UUE | ??? | n/c
236/205 @ Michael Kaaber | BinkP | ??? | n/c
246/2098 | Volker Imre | BinkP | ??? | n/c
284/800 @ Jeroen VanDeLeur | FTP,UUE | 64k | n/c
292/620 | Eddy Missoul | VMoT, UUE | 64k |N/C
292/624 | Steven Leeman | UUE | 64k | N/C
292/2003 | Eric Vaneberck | BinkP | 768k | n/c
301/1 | Peter Witschi | BinkP | 768k | n/c
332/807 | Roberto Mascolo | BinkP | ??? | n/c
335/535 @ Mario Mure | BinkP,VMot,UUE | 64k | n/c
335/610 | Gino Lucrezi | UUE | 33.6 | n/c
FIDONEWS 17-18 Page 36 1 May 2000

344/201 | Julio Garcia | BinkP | ??? | n/c
346/3 @ Carlos Navarro | UUE | ??? | n/c
382/100 | Sinisa Burina | BinkP | ??? | n/c
406/555 | Ofir Michaeli & | BinkP | ??? | n/c
406/555 | Marius Kaizerman | BinkP | ??? | n/c
423/81 | Milos Bajer | BinkP | ??? | n/c
464/4077 | Serguei Trouchelle| UUE | 19.2 | n/c
465/204 | Va Milushnikov | BinkP | 33.6k | n/c
469/84 | Max Masyutin | VMoT | 256k | n/c
480/112 | Adam Sarapata| FTP, VMoT, UUE,BinkP| 128k | n/c
2411/413 @ Dennis Dittrich | UUE,BinkP | 64k | n/c
2446/301 | Lothar Behet | BinkP,VMoT,UUE,FTP | 64K | n/c
2474/275 | Christian Emig | UUE | 64k | unkn
5030/115 | Andrey Podkolzin | BinkP | ??? | n/c
5100/8 | Egons Bush | BinkP | ??? | n/c
5020/1159 | Gennady Kudryashoff | UUE | 33.6 | n/c
--------------------------------------------------------------
Zone 3
633/260 @ Malcolm Miles | FTP,BinkP | 64K | n/c
640/954 | Rick Van Ruth | FTP,VMot,UUE,BinkP| 56K| n/c
774/605 @ Barry Blackford|BinkP,VMoT:10023,ifcico,FTP |33.6| n/c

--------------------------------------------------------------
Zone 4
905/100 | Fabian Gervan | VMoT,UUE,BinkP | 128k | n/c
902/18 | Javier Tejedor | UUE | 33,6 | n/c

--
* FTP = Internet File Transfer Protocol
* VMoT = Virtual Mailer over Telnet (various)
* UUE = uuencode<->email type transfers
* BinkP = front end mailer for TCPIP networks

----------------------------------------------
Fidonet oriented news servers

news.osirusoft.com
news.tardis.net

Fidonet oriented chat rooms.

room #fidonet 5PM (PDT 11AM GMT) Sundays
irc.osirusoft.com (Peers wanted)

----------------------------------------------

Please send updates, corrections and suggestions to
Joe Jared, 1:103/301, [email protected]. All email addresses
here for purpose of corresponding with fidonet members about
obtaining a feed. Improper use of the virtual email addresses, and
most especially, email addressed to [email protected]
will be considered a request to be blocked by my open relay spam
stopper at http://relays.osirusoft.com

-----------------------------------------------------------------
FIDONEWS 17-18 Page 37 1 May 2000

=================================================================
FIDONEWS INFO
=================================================================

Masthead

+ -- -- -- -- -- -- -- -- FIDONEWS STAFF - -- -- -- -- -- -- -- +
| |
| Editor: Douglas Myers, 1:270/720, [email protected] |
| Webmaster: Jim Barchuk, [email protected] |
| Columnist: Joe Jared, 1:103/0, [email protected] |
| (Fido Via Internet Hubs column) |
| Columnist: Warren D. Bonner, 1:103/401, [email protected] |
| (Warren uses the pen name "Ol'WDB") |
| Humor: Roy Reed, [email protected] |
| Features: Frank Vest, 1:124/6308.1 |
| |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

+ -- -- -- -- -- -- -- - EDITORS EMERITI - -- -- -- -- -- -- -- +
| |
| Tom Jennings, Thom Henderson, Dale Lovell, Vince |
| Perriello, Tim Pozar, Sylvia Maxwell, Donald Tees, |
| Christopher Baker, Zorch Frezberg, Henk Wolsink |
| |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA
94141, and are used with permission.

Fidonews is published weekly by and for the members of Fidonet.
Fidonews is Copyright (C) 2000 by Douglas Myers, though authors
retain rights to their contributed articles. Opinion expressed by
the authors is strictly their own. Noncommercial duplication and
distribution within Fidonet is encouraged. Authors are encouraged
to send their articles in ASCII text to Douglas Myers at one of his
addresses above.

The weekly edition of Fidonews is distributed through the file area
FIDONEWS, and is published as echomail in the echo FIDONEWS. These
sources are normally available through your Network Coordinator.
The current and past issues are also available from the following
sources:

+ -- -- -- -- -- -- - FIDONEWS AVAILABILITY - -- -- -- -- -- -- +
| |
| Freq FIDONEWS @ 1:270/720, 1:140/1, or 1:396/1 |
| ftp://ftp.sstar.com/fidonet/fnews/ |
| ftp://ftp.nwstar.com/fidonet/fidonews/ |
| http://www.fidonews.org |
| email subscription: [email protected] |
| (subject: help body: list) |
| ftp mail: [email protected] (subject: help) |
| |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +
FIDONEWS 17-18 Page 38 1 May 2000

-----------------------------------------------------------------