F I D O N E W S -- Volume 13, Number 47 18 November 1996
+----------------------------+-----------------------------------------+
| The newsletter of the | ISSN 1198-4589 Published by: |
| FidoNet community | "FidoNews" |
| _ | 1-904-409-7040 [1:1/23] |
| / \ | |
| /|oo \ | |
| (_| /_) | |
| _`@/_ \ _ | |
| | | \ \\ | Editor: |
| | (*) | \ )) | Christopher Baker 1:18/14 |
| |__U__| / \// | |
| _//|| _\ / | |
| (_/(_|(____/ | |
| (jm) | Newspapers should have no friends. |
| | -- JOSEPH PULITZER |
+----------------------------+-----------------------------------------+
| Submission address: FidoNews Editor 1:1/23 |
+----------------------------------------------------------------------+
| MORE addresses: |
| |
| submissions=>
[email protected] |
+----------------------------------------------------------------------+
| For information, copyrights, article submissions, |
| obtaining copies of FidoNews or the internet gateway FAQ |
| please refer to the end of this file. |
+----------------------------------------------------------------------+
SIXTY HORSES FOUND WEDGED UP CHIMNEY!
Table of Contents
1. EDITORIAL ................................................ 1
Standards and proposals .................................. 1
2. ARTICLES ................................................. 2
Destroy the Bastard, says I! ............................. 2
Proposed update to fts-0005 .............................. 2
Action is a meausurement of convictions: ................. 14
Region 13 has no RC ...................................... 15
Credibility? ............................................. 16
Fidonet on Win95 ......................................... 16
3. COLUMNS .................................................. 17
Fidonet In Europe ........................................ 17
4. GETTING TECHNICAL ........................................ 18
FTS-0005 - The Nodelist Standard ......................... 18
5. COORDINATORS CORNER ...................................... 29
Nodelist-statistics as seen from Zone-2 for day 320 ...... 29
6. NET HUMOR ................................................ 30
More C humor? ............................................ 30
Deep thoughts? ........................................... 32
7. NOTICES .................................................. 35
Future History ........................................... 35
8. FIDONEWS PUBLIC-KEY ...................................... 36
This Space intentionally left blank? ..................... 36
9. FIDONEWS INFORMATION ..................................... 37
FIDONEWS 13-47 Page 1 18 Nov 1996
=================================================================
EDITORIAL
=================================================================
Another Standard [FTS-0005] meets another proposal in this issue.
No new Headline entries. Guess that was a QotW that went nowhere.
Any ASCII art for the upcoming U.S. Thanksgiving Day Issue next
week?
Would anyone like to become a FidoNews interviewer and go out there
and get some .BIO info from various FidoNet luminaries or maybe
infamositers? [grin]
C.B.
-----------------------------------------------------------------
FIDONEWS 13-47 Page 2 18 Nov 1996
=================================================================
ARTICLES
=================================================================
Destroy the Bastard, says I!
Fredric Rice 1:218/890.0 (
[email protected])
The Skeptic Tank (818) 335-9601
In issue 13-46, Cindy Ingersoll (1:2623/71;
[email protected])
voices some difficulties which, I must opine, seem to indicate
a growing phenomena in FidoNet: When a lazy bastard is asked
politely enough to do his fucking job, there appears to be some
which adopt a resentful attitude at the audacity of being asked
and endlessly refuse just on general principles.
What fun, Cindy! Now's your chance! Distribute a formal note
to all nodes in your network or region (wherever the problem is)
calling for an election. Since the source of your difficulties
come from someone you claim wasn't elected in the first place,
you don't have the embarrassing unpleasantness (or the fun) of
THROWING THE BUMS OUT! so it should be fairly simple to elect
someone willing to do the job. Your log of unanswered and
ignored messages you transmitted should show your network that
there is a need for some rework.
Some many years ago there were some snotty-nosed upstarts here
in Net 102 (wipe your nose, Pablo) which tried to bowdlerize
the benignant beau who ran Net 102 Bedlam on the grounds that
requests for nodelist updates were ignored and such yet when
the network was polled the consensus was that our beloved NC
was doing his job and doing it well. (And we all _do_ love
him.) <wink> <wink>
Poll your net or region, Cindy, and find out what the consensus
is and, if the clown is the lazy bastard you say he is, and
he wasn't appointed officially, there should be an easy solution
to your problem (not to mention you would be preempting other
problems before they can begin.) If everyone else finds no
complaint, however, you is outta luck.
-----------------------------------------------------------------
A couple of widgies added to fts-0005
by Lee Kindness, 2:259/7,
[email protected]
Well fts-0005 will be included in this issue of Fidonews, so here
is a new revision that i submitted to the FTSC a couple of months
ago (no action taken yet). I was just going to include the diffs,
but these didn't work too well (too hard to follow) so you can
have two versions of fts-0005 in this issue ;)
The modem flags could do with a major overhaul and a lot has
been going on about this in ENET.SYSOP and NET_DEV, i didn't
FIDONEWS 13-47 Page 3 18 Nov 1996
touch them too much as i don't have a firm technical knowledge
of them...
Remember, this is currently a proposed spec...
Document: FTS-0005
Version: 004
Date: August 10, 1996
The Distribution Nodelist
Originally by Ben Baker
Amended by Rick Moore, 1:115/333, February 5, 1989
Amended by David Nugent, 3:632/348, February 27, 1996
Amended by Lee Kindness, 2:259/7, August 4, 1996
Copyright 1986-1996 by the FidoNet Technical Standards Committee.
All rights reserved. Duplication and/or distribution permitted
for non-commercial purposes only.
This document supersedes and replaces the document known under
| the names of FSC002, FSC-0002, and FTS-0002. Significant changes,
| which excludes mere formatting changes, to revision 3 of this
| document have been marked by '|' in the leftmost column.
This document defines the format and content of the nodelist for
the Public FidoNet Network (PFN) as published on Friday of each
week. This format is historically known as the "St. Louis nodelist
format".
The PFN is an international network of independently owned
electronic mail systems, most with interlocking electronic
bulletin board systems. The distribution nodelist, or simply
"nodelist", is the glue which holds the network together. It is
the PFN's "phone book" and it defines the top-level network
structure and is the means by which FidoNet retains its integrity
as a point-to-point mail network.
THE NODELIST
The nodelist is published as an ASCII text file named
NODELIST.nnn, where nnn is a three digit number representing the
day-of-year of the Friday publication date, with zeros filling
positions to the left if necessary. This file is packed into a
archive file named NODELIST.?nn, where 'nn' are the last two
digits of day-of-year, and the character at the position of the
'?' indicating the type of compression used. Conventions as to
which compression method is used for the distributed nodelist is
a matter of local policy and is usually determined by each zone's
| Zone Coordinator. Common conventions are:
| NODELIST.Znn : Zip
| NODELIST.Ann : Arc
FIDONEWS 13-47 Page 4 18 Nov 1996
| NODELIST.Lnn : Lzh/Lha
| NODELIST.Jnn : ARJ
As stated above, NODELIST.nnn is an ASCII text file. It contains
two kinds of lines; comment lines and data lines. Each line is
terminated with an ASCII carriage return and line feed character
sequence, and contains no trailing white-space (spaces, tabs,
etc.). The file is terminated with a DOS end-of-file character
(character value 26 decimal, or "control-Z").
Comment lines contain a semicolon (;) in the first character
position followed by zero or more alphabetic characters called
"interest flags". A program which processes the nodelist may use
comment interest flags to determine the disposition of a comment
line. The remainder of a comment line (with one exception,
treated below) is free-form ASCII text. There are five types of
comments flags:
;S This is of particular interest to Sysops
;U This is of particular interest to BBS users
;F This should appear in any formatted "Fido List"
;A This is of general interest (shorthand for ;SUF)
;E This is an error message inserted by the nodelist generator
; This comment may be ignored by a nodelist processor
The first line of a nodelist is a special comment line containing
identification data for the particular edition of the nodelist.
The following is an example of the first line of a nodelist:
;A FidoNet Nodelist for Friday, July 3, 1987 -- Day number 184 : 15943
This line contains the general interest flag, the day, date, and
three-digit (zero-filled) day-of-year number of publication, and
ends with a 5 digit decimal number with leading zeros, if
necessary. This number is the decimal representation of a check
value derived as follows:
Beginning with the first character of the second line, a
16 bit cyclic redundancy check (CRC) is calculated for the
entire file, including carriage return and line feed
characters, but not including the terminating EOF
character. The check polynomial used is the same one used
for many file transfer protocols:
2**16 + 2**12 + 2**5 + 2**0
The CRC may be used to verify that the file has not been edited.
The importance of this will become evident in the discussion of
NODEDIFF, below. CRC calculation techniques are well documented
in various technical references, and will not be treated further
here.
The content of the remaining comments in the nodelist are
intended to be informative. Beyond the use of interest flags for
distribution, a processing program need not have any interest in
them.
FIDONEWS 13-47 Page 5 18 Nov 1996
A nodelist data line contains eight variable length "fields"
separated by commas (,). No space characters are allowed in a
data line, and underscore characters are used in lieu of spaces.
The term "alphanumeric character" is defined as the portion of
the ASCII character set from 20 hex through 7E hex, inclusive.
The following discussion defines the contents of each field in a
data line.
Field 1: Keyword
The keyword field may be empty, or may contain one of the
following:
Zone
Begins the definition of a geographic zone and define its
coordinator. All the data lines following a line with the
"Zone" keyword down to, but not including, the next
occurrence of a "Zone" keyword, are regions, networks, and
nodes within the defined zone. Node entries defined
immediately after the "Zone" keyword and before the next
region or host entry are known as zone administrative nodes.
These are allocated by the Zone Coordinator for use by nodes
in the entire zone; for example, mail gateways between
FidoNet zones.
Region
Begins the definition of a geographic region and defines
its coordinator. All the data lines following a line with
the "Region" keyword down to, but not including, the
next occurrence of a "Zone", "Region", or "Host"
keyword, are independent nodes within the defined region.
Host
Begins the definition of a local network and defines its
network coordinator. All the data lines following a line
with the Host keyword down to, but not including, the
next occurrence of a "Zone", "Region", or "Host" keyword,
are local nodes, members of the defined local network.
Hub
Begins the definition of a routing sub-unit within a
multi-level local network. The hub is the routing focal
point for nodes listed below it until the next occurrence
of a "Zone", "Region", "Host", or "Hub" keyword. The hub
entry MUST be a redundant entry, with a unique number, for
one of the nodes listed below it, within its hub segment.
This is necessary because some nodelist processors
eliminate these entries in all but the local network.
Pvt
FIDONEWS 13-47 Page 6 18 Nov 1996
Defines a private node with unlisted number. Private nodes
are only allowed as members of local networks.
| Point
| Defines a private point off a node. Should not be used in
| the Fidonet nodelist, but rather private 'pointlists',
| local net level nodelists and nodelists in other Fidonet
| technology networks.
Hold
Defines a node which is temporarily down. Mail may be sent
to it and is held by its host or coordinator.
Down
Defines a node which is not operational. Mail may NOT be
sent to it. This keyword may not be used for longer than
two weeks on any single node, at which point the "down"
node is to be removed from the nodelist.
<empty>
The field contains no text (not the sequence "<empty>"),
and defines a normal node entry.
Only one of these may be used in any individual data line.
| Field 2: Zone/Region/Net/Node/Point number
This field contains only numeric digits and is a number in the
range of 0 to 32767. If the line had the "Zone", "Region", "Host"
| or "Point" keyword, the number is the zone, net, region or point
number, and the node has an implied node number of 0. Otherwise,
the number is the node number. The zone number, region or net
number, and the node number, taken together, constitute a node's
FidoNet address.
Zone numbers must be unique. Region or net numbers must be unique
within their zone, hub numbers unique be within their net, node
numbers unique within their net (and region, for regional
independent nodes, zone for zone administrative entries).
Duplicate node numbers under different hubs within the same net
are not
| allowed. Point numbers must be unique within their node.
Field 3: Node name
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces, and
a comma delimits the end of the field. This is the name by which
the node is known, usually as determined by the node or the
| coordinator responsible for compiling the segment. For zone,
FIDONEWS 13-47 Page 7 18 Nov 1996
| region and host entries this field should indicate its (rough)
| geographical area.
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 an
identifier of the regional geopolitical administrative district
(state, province, department, county, etc.). Wherever possible,
standard postal abbreviations for the major regional district
should be used (IL, BC, NSW, etc.).
Field 5: Sysop name
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces. This
| is the name of the SYSTEM OPERATOR, entries such as "postmaster",
| "uucp" and aliases are not permitted.
Field 6: Phone number
This field contains at least three and usually four numeric sub-
fields separated by dashes (-). The fields are country code,
city or area code, exchange code, and number. The various parts
of the phone number are frequently used to derive cost and
routing information, as well as what number is to be dialed. A
typical example of the data in a phone number field is 1-800-555-
1212, corresponding to country 1 (USA), area 800
(inbound WATS), exchange 555, and number 1212.
Alternatively, this field may contain the notation
| "-Unpublished-" in the case of a private node or point. In this
| case, the keyword "Pvt" or "Point" must appear at the start of
the line.
Field 7: Baud rate
This field contains one of the values: 300, 1200, 2400, 9600,
19200, or 38400.
This baud rate is indicative only of the maximum baud rate that
may be expected when connecting to a node and is generally of use
only where a calling node needs to adjust the baud rate used to
dial to the caller's modem speed in order to achieve a
connection, a requirement that with modem technology available in
1996 is rarely if ever needed. This information is largely
superseded by modem protocol flags (see next section) where any
two nodes using a common protocol may have other expectations
with regards to actual transfer rates. Use of the baud rate field
| alone is therefore depreciated. FSC-0091 should be consulted with
FIDONEWS 13-47 Page 8 18 Nov 1996
| regard to the special use of '300'
Field 8 - Flags
This optional field contains data about the specific operation of
the node, such as file requests, modem protocol supported, etc.
Any text following the seventh comma on a data line is taken
collectively to be the flags field. The required format is zero
or more sub-fields, separated by commas. Each sub-field consists
| of a flag, possibly followed by a value. Entries here are update
| to or succeeded in the epilogue of the Nodelist. The flags field
| has no maximum size.
The following flags define special operating conditions:
Flag Meaning
CM Node accepts mail 24 hours a day
MO Node does not accept human callers
LO Node accepts calls only from valid listed node
numbers in the current FidoNet nodelist
The following flags define modem protocols supported:
Flag Meaning
V21 ITU-T V21 300 bps full duplex
V22 ITU-T V22 1200 bps full duplex
V29 ITU-T V29 9600 bps half duplex
V32 ITU-T V32 9600 bps full duplex
V32b ITU-T V32bis 14400 bps full duplex
V33 ITU-T V33
V34 ITU-T V34 28800 bps full duplex
| 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 ISDN configurations. Use *only* if none
| of the above fits
| NOTE: ISDN nodes which do not accept modem calls must use
| '300' in the baud field, see FSC-0091 for more details.
H96 Hayes V9600
HST USR Courier HST
H14 USR Courier HST up to 14.4Kbps
FIDONEWS 13-47 Page 9 18 Nov 1996
H16 USR Courier HST up to 16.8Kbps
PEP Packet Ensemble Protocol
CSP Compucom Speedmodem
| V32T V.32 Terbo mode (implies V32b)
VFC Rockwell's V.Fast Class
| ZYX Zyxel 16.8 Kbps (implies V32b & V42b)
| Z19 Zyxel 19.2 Kbps (implies V32b, V42b & ZYX)
NOTE: Many V22 modems also support Bell 212A.
| If no modem flag is given, ITU-T V.22 is assumed within zone 2
| for 1200bps, while Bell 212A is assumed for 1200 bps systems in
| other zones, ITU-T V22bis is assumed for 2400 bps systems.
| A separate modem capability flag should not be used when it can be
| determined by the modem flag. For instance, a modem flag of HST
| implies MNP. V32B implies V32 and V42B implies V42. MNP,HST and
| V32,V32B and V42,V42B flag pairs are unnecessary. H14 implies HST
| and H16 implies H14 as well as V42b.
The following flags define type of error correction available. A
separate error correction flag should not be used when the error
correction type can be determined by the modem flag. For
instance, a modem flag of HST implies MNP, V32b implies V32 and
V42b implies V42. Therefore MNP+HST, H14+MNP, H16+MNP, V32+V32b
and V42+V42b flag pairs are redundant and should not be used.
Flag Meaning
MNP Microcom Networking Protocol error correction
V42 ITU-T LAP-M error correction w/fallback to MNP 1-4
V42b ITU-T LAP-M error correction w/fallback to MNP 1-5
| (V42 implied)
The following flags define the type(s) of compression of mail
| packets supported plus message encoding.
Flag Meaning
MN No compression supported
| ENC The node accepts inbound encrypted mail
NOTE: While FidoNet nodes usually exchange mail
using a variety of different file compression
formats negotiated between individual systems, the
presence of this flag indicates the INABILITY TO
RECEIVE MAIL compressed using the SEA ARC version 5
compression format and/or named according to the
ARCmail 0.6 mail bundle naming method. This is, by
convention, the most common mail compression format
in use within FidoNet. The presence of this flag
would normally indicate that all mail should be sent
uncompressed unless there is some overriding
arrangement with the receiving system.
FIDONEWS 13-47 Page 10 18 Nov 1996
The following flags indicate the types of file and file update
requests supported.
Flag Meaning
XA Bark and WaZOO file/update requests
XB Bark file/update requests, WaZOO file requests
XC Bark file requests, WaZOO file file/update
XP Bark file/update requests
XR Bark and WaZOO file requests
XW WaZOO file requests
XX WaZOO file/update requests
The following flag defines gateways to other domains (mail
networks).
Flag Meaning
Gx..x Gateway to domain 'x..x', where 'x..x` is a string
of alphanumeric characters.
NOTE: Valid values for 'x..x' are assigned by the FidoNet
International Coordinator or the person appointed as
Internetworking Coordinator by the FidoNet
International Coordinator. Current valid values of
'x..x' may usually be found in the notes at the end
of the current FidoNet nodelist. The most common
gateway flag is "GUUCP", to denote a gateway to the
Internet mail system that gates on behalf of the
fidonet.org internet domain.
The following flags define the dedicated mail periods supported.
They have the form "#nn" or "!nn" where nn is the UTC hour the
mail period begins, '#' indicates Bell 212A compatibility, and
'!' indicates incompatibility with Bell 212A.
Flag Meaning
#01 Zone 5 mail hour (01:00 - 02:00 UTC)
#02 Zone 2 mail hour (02:30 - 03:30 UTC)
#03 Zone 4 mail hour (08:00 - 09:00 UTC)
#09 Zone 1 mail hour (09:00 - 10:00 UTC)
#18 Zone 3 mail hour (18:00 - 19:00 UTC)
#20 Zone 6 mail hour (20:00 - 21:00 UTC)
NOTE: When applicable, the mail period flags may be strung
together with no intervening commas, e.g.. "#02#09"
or "!02!09". Only mail hours other than that
standard within a node's zone should be given. Since
observance of mail hour within one's zone is
mandatory, it should not be indicated.
| Txx Availability flag for non-CM nodes indicating the
| hours during which the node is available in addition
FIDONEWS 13-47 Page 11 18 Nov 1996
| to ZMH. This must be in accordance with the recommen-
| dations in FSC-0062 and the reference table reproduced
| below. ATTENTION : All times must be UTC!
|
| +------+----++------+----++------+----++------+----++------+----+
| |Letter|Time||Letter|Time||Letter|Time||Letter|Time||Letter|Time|
| +------+----++------+----++------+----++------+----++------+----+
| | A |0000|| F |0500|| K |1000|| P |1500|| U |2000|
| | a |0030|| f |0530|| k |1030|| p |1530|| u |2030|
| | B |0100|| G |0600|| L |1100|| Q |1600|| V |2100|
| | b |0130|| g |0630|| l |1130|| q |1630|| v |2130|
| | C |0200|| H |0700|| M |1200|| R |1700|| W |2200|
| | c |0230|| h |0730|| m |1230|| r |1730|| w |2230|
| | D |0300|| I |0800|| N |1300|| S |1800|| X |2300|
| | d |0330|| i |0830|| n |1330|| s |1830|| x |2330|
| | E |0400|| J |0900|| O |1400|| T |1900|| | |
| | e |0430|| j |0930|| o |1430|| t |1930|| | |
| +------+----++------+----++------+----++------+----++------+----+
The following flag defines user-specific values. If present,
this flag MUST be the last flag present in a nodelist entry.
Flag Meaning
Ux..x A user-specified string, which may contain any
alphanumeric character except blanks. This string
may contain one to thirty-two characters of
information that may be used to add user-defined
data to a specific nodelist entry.
NOTE: Ux..x flags are the mechanism by which new flags may
be experimentally introduced into the nodelist for a
trial period to assess their worth. They are
therefore of a temporary nature, and after their
introduction they are eventually either promoted
to a non-U flag or dropped from use altogether.
| The FTSC recognizes that the FidoNet International Coordinator
| (IC) is the ultimate authority over what appears in the FidoNet
nodelist. Also, FTSC is by definition a deliberative body, and
adding or changing a flag may take a considerable amount of time.
Therefore, the FidoNet International Coordinator may temporarily
make changes or additions to the flags as defined in this
document. The FidoNet International Coordinator will then consult
with FTSC over the changes needed to this document to reflect
these temporary changes.
The following are examples of nodelist data lines:
Host,102,SOCALNET,Los_Angeles_CA,Richard_Martz,1-213-874-
9484,2400,XP ,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-
204-2996,2400,
FIDONEWS 13-47 Page 12 18 Nov 1996
THE NODEDIFF
With more than thirty-five thousand nodes as of this date (1996),
the nodelist, even in archive form, is a document of substantial
size. Since distribution of the nodelist occurs via electronic
file transfer, this file is NOT routinely distributed. Instead,
when a new nodelist is prepared weekly, it is compared with the
previous week's nodelist, and a file containing only the
differences is created and distributed.
The distribution difference file, called NODEDIFF.nnn, where nnn
is the day-of-year of publication, is actually an editing script
which will transform the previous week's nodelist into the
current nodelist. A definition of its format follows:
The first line of NODEDIFF.nnn is an exact copy of the first line
of LAST WEEK'S nodelist (i.e. the first line of the nodelist to
which the current difference file applies). This is used as a
first-level confidence check to insure that the correct file is
being edited. The second and subsequent lines are editing
commands and data.
There are three editing commands and all have the same format:
<command><number>
<command> is a 1 letter command, one of 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 (or skip) nn lines from the input file.
The following illustrate how the first few lines of a
hypothetical NODEDIFF.213 might look:
;A Friday, July 25, 1986 -- Day number 206 : 27712
D2
A2
;A Friday, August 1, 1986 -- Day number 213 : 05060
;A
C5
This fragment illustrates all three editing commands. The first
line is the first line from the previous nodelist, NODELIST.206.
The next line says "delete the first two lines" from
NODELIST.206. These are the identification line and the line
following it. The next command says "add the next two lines" to
NODELIST.213 at the "current" location. The two data lines are
followed by a command which says "copy five unchanged lines" from
NODELIST.206 to NODELIST.213. Notice that the first line added
FIDONEWS 13-47 Page 13 18 Nov 1996
will ALWAYS contain the new nodelist CRC, so that the software
applying the changes to the old nodelist may check the result of
its editing.
Since only the differences will be distributed, it is important
to insure the accuracy of the newly created nodelist. This is the
function of the CRC mentioned above. It is sufficient for a
program designed to perform the above edits to pick the CRC value
from the first line added to the output file, then compute the
CRC of the rest of the output file. If the two CRCs do not agree,
one of the input files has been corrupted. If they do agree, the
probability is very high (but not 100%) that the output file is
accurate.
For actual distribution, NODEDIFF.nnn is packed into an archive
file named NODEDIFF.?nn, where 'nn' are the last two digits of
day-of-year, and '?' indicates the compression format used.
NODELIST COMPILATION
This section is included for tutorial reasons and is not intended
as a definition of any specific method by which FidoNet MUST
compile its weekly nodelist. It merely represents an attempt to
document the method by which it currently does so. It is intended
to be explanatory, and seeks to answer commonly asked questions,
such as how the nodelist is compiled and where the information
comes from, why the nodelists used in different FidoNet zones are
not the same document, and why the difference file generated for
use in one FidoNet zone cannot be applied to the nodelist
generated for use in a different zone, even though the week
numbers match.
Nodelists are compiled via a distributed method, which follows
the same structure as the FidoNet coordinator hierarchy. At the
lowest level, network coordinators maintain a list of the nodes
in their network and are responsible for the addition, removal
and correction of individual node's listings in their "segment"
(as portions of the full nodelist are called). In some larger
networks, it is common for this job to be shared with hub
coordinators appointed by the net coordinator, though the
responsibility for those hub segments still remains with the
network coordinator.
At a nominated day during the week, before the regional level
segment is submitted to the zone coordinator, individual net
coordinators submit their segments to the regional coordinator
who subsequently compiles these segments and transmits the merged
copy to the zone coordinator. These are combined by the zone
coordinator with the separate segments of other zones and
compiled into that zone's version of the world nodelist. This
world nodelist is then compared with the previous week's version,
a difference file is generated and subsequently distributed
throughout the zone.
In some cases, in the interest of saving in transmission times
FIDONEWS 13-47 Page 14 18 Nov 1996
and therefore costs, the compilation process itself may be better
served by the submission of DIFFERENCE FILES rather than full
net- or region-level segments. Each coordinator therefore retains
a copy of the previously submitted segments and applies
difference files to those to derive the new one. This process is
exactly identical to the NODEDIFF/NODELIST scenario described
earlier in this document, with the same first line and CRC
validation method used to guard the integrity of the nodelist
segments.
For a number of reasons, it is important that publication of the
nodelist be as timely as possible. These reasons include: the
nodelist is a definitive list of valid FidoNet addresses that may
receive mail, and must therefore be as correct and up-to-date as
possible to save nodes the unnecessary expense of mail routed to
possibly non-existing addresses; the nodelist contains the list
of telephone numbers that may be called by any user of the
FidoNet nodelist and should therefore be accurate so as not to
unduly annoy owners of those phone numbers should a listed node
go down and an unsuspecting telephone subscriber inherit the same
telephone number.
Given this constraint, the expense of international calls and the
fact that FidoNet is a worldwide network that exists in many time
zones, it may be unreasonable to expect the compilation of the
nodelist to be delayed until each zone coordinator can transmit
their most up-to-date zone segment to a central authority for
compilation and subsequent redistribution in any week. For the
sake of expedience, each zone instead maintains its own separate
world nodelist which contains a compilation of the current zone's
latest segments and including the most current copy to hand of
all other FidoNet zone's segments. The zone level nodelist
generated each week by each zone coordinator is then transmitted
to all other zone coordinators for inclusion into their separate
world nodelist as timing permits.
In theory, then, the only difference between nodelists
distributed in each zone in any week are accounted for by timing
differences in the exchange of each zone's separate segment. In
practice, other constraints may interfere with timeliness, such
as the difficulty and expense of international telephonic
communications. Also, another point of variance is introduced by
the fact that each zone usually includes its own zone segment
first into its world nodelist to assist - amongst other things -
software that uses the nodelist for index generation. Some
software in common use in FidoNet indexes the nodelist according
to its sequential order (e.g. version 5 and 6 compiled nodelist
formats), and including the current zone first before others will
have a beneficial effect on software performance.
-30-
-----------------------------------------------------------------
Action is a meausurement of convictions
FIDONEWS 13-47 Page 15 18 Nov 1996
by Bob Moravsik 1:2606/583
>Bob Morasvik writes in fnewsd45:
>> make it my business. By not filing a PC against me
>> it is your admission that I'm right and you are wrong.
>> My NC is Sean Aldrich 1:2606/0...the lines are open.
Then Lee Kindness whines in fnewsd46:
>Oh, please! Can we not have a *discussion* without reverting
>to this sort of rubbish! I will not waste any NC's time over a
>thread in *Fidonews*, nor will I continue a discussion when this
>is the view of one of the participants!
The test of a persons credability and convictions occurs
when they are "challenged" to put action to back their words.
I gather then only retort to my well thought out analysis
of why a zone echopol is a waste of time is Mr. Kindness'
whinning that it is none of my business. When challenged
to back this up...WIMP OUT.
OK Mr. Kindness fluff up your feathers, take your one distorted
marble and live in the world of denial. But try reading
section one of policy 4.07. That section is the linchpin of
any local policy. Disregard it and the policy will come
tumbling down because it lacks a foundation.
By not addressing the Section one issue it is your admission
that you live inn this denial world. Come on....give it a shot.
Analyze Woodmorepol pursuant to Section 1.0. Impress "us".
-----------------------------------------------------------------
Region 13 has no RC
By Bob Moravsik
A lot of you have read the plight of CIA trying to
get back into the node list. Messages to the RC
have gone unanswered. This is typical of Philip
Dampier, RC13. He communicates with his "buddies"
and ignores the rest. Region 13 is not coordinated,
its split. R13 a small group of nets under the "rule"
of Dampier; R13A the rest of region 13.
Time and time again, Dampier has issolated himself
from the mainstream. Why the ZC allows just one
node to remain out of the nodelist is in itself
pathetic. Region 13 needs an enema and Dampier
should be the first "turd" out !
Any *C that allows a PC Or appeal to go over the
30 days SHOULD RESIGN. The nodelist might
get smaller but those who remain will be of a higher
quality then these waste products that can't get
along with society.
FIDONEWS 13-47 Page 16 18 Nov 1996
Dampier....resign.
-----------------------------------------------------------------
Credibility?
Seanette Blaylock, 1:206/2735,
[email protected]
Rob Shinn does seem awfully determined to find unwarranted fault with
U'NI-Net, doesn't he?
Two minor points that I think reflect very unfavorably on Mr. Shinn's
credibility on this subject:
1) He refers to Cam DeBuck as "her". Cam is male, as anyone who has
actually participated on U'NI-Net would know.
2) By his own admission, Mr. Shinn has NOT participated on U'NI-Net.
How can a non-participant on a given net have *any* credibility
discussing that net's internal workings?
Respectfully submitted,
Seanette Blaylock
-----------------------------------------------------------------
Fine, original wimmin - aged 95
by Lee Kindness, 2:259/7,
[email protected]
One of my points recently(-ish) moved to Win95 from the Amiga (which
as many know has a great range of Fidonet programs). What he found was
a platform void of any decent software (his opinion). FIPS is the only
thing worth noting, but the evaluation versions method of delays has
made his evaluation a nightmare ;)
So, can anyone recommend a 'good' setup (be it one integrated program
or separate editor, tosser, mailer et al), and please no DOS apps
running in a console (when my point asked in a Win95 echo the general
suggestion was Terminate...)! Answers to 2:259/7 please or just
follow up in Fidonews...
So may the eternal traffic cone enlighten your catum...
-----------------------------------------------------------------
FIDONEWS 13-47 Page 17 18 Nov 1996
=================================================================
COLUMNS
=================================================================
FIDONET IN EUROPE
-----------------
by Dave Meikle (2:259/58.90 ,
[email protected])
Sorry about last week my machine crashed , but nothing happened
anyway. My new WWW page is at
http://members.aol.com/rebeljambo/homepage.html.
Rebemember the address to submit is EUROPE@2:259/58.90 or
[email protected]
Dave
-----------------------------------------------------------------
FIDONEWS 13-47 Page 18 18 Nov 1996
=================================================================
GETTING TECHNICAL
=================================================================
[Part of a continuing series of FidoNet Technical Standards and
Proposals being published here in numerical order. This is also
part of our continuing FidoNet History series. It has been
reformatted to 70 columns where necessary.] Ed.
| Document: FTS-0005
| Version: 003
| Date: February 7, 1996
| Maintainer: David Nugent, 3:632/348@fidonet
The Distribution Nodelist
Originally by Ben Baker
Amended by Rick Moore, 1:115/333@FidoNet, February 5, 1989
Amended by David Nugent, 3:632/348@FidoNet, February 27, 1996
| Copyright 1986-1996 by the FidoNet Technical Standards Committee.
All rights reserved. Duplication and/or distribution permitted
for non-commercial purposes only.
This document supersedes and replaces the document known under
| the names of FSC002, FSC-0002, and FTS-0002. Significant changes,
| which excludes mere formatting changes, to the previous version
| of this document have been "redlined" (marked with a vertical
| bar in the leftmost column).
This document defines the format and content of the nodelist for
the Public FidoNet Network (PFN) as published on Friday of each
| week. This format is historically known as the "St. Louis nodelist
| format".
The PFN is an international network of independently owned
electronic mail systems, most with interlocking electronic
bulletin board systems. The distribution nodelist, or simply
"nodelist", is the glue which holds the network together. It is
the PFN's "phone book" and it defines the top-level network
| structure and is the means by which FidoNet retains its integrity
| as a point-to-point mail network.
| THE NODELIST
The nodelist is published as an ASCII text file named
NODELIST.nnn, where nnn is a three digit number representing the
| day-of-year of the Friday publication date, with zeros filling
| positions to the left if necessary. This file is packed into a
| archive file named NODELIST.?nn, where 'nn' are the last two
| digits of day-of-year, and the character at the position of the
| '?' indicating the type of compression used. Conventions as to
| which compression method is used for the distributed nodelist is
FIDONEWS 13-47 Page 19 18 Nov 1996
| a matter of local policy and is usually determined by each zone's
| Zone Coordinator.
As stated above, NODELIST.nnn is an ASCII text file. It contains
two kinds of lines; comment lines and data lines. Each line is
terminated with an ASCII carriage return and line feed character
sequence, and contains no trailing white-space (spaces, tabs,
| etc.). The file is terminated with a DOS end-of-file character
| (character value 26 decimal, or "control-Z").
Comment lines contain a semicolon (;) in the first character
position followed by zero or more alphabetic characters called
"interest flags". A program which processes the nodelist may use
comment interest flags to determine the disposition of a comment
line. The remainder of a comment line (with one exception,
| treated below) is free-form ASCII text. There are five types of
| comments flags:
| ;S This is of particular interest to Sysops
| ;U This is of particular interest to BBS users
| ;F This should appear in any formatted "Fido List"
| ;A This is of general interest (shorthand for ;SUF)
| ;E This is an error message inserted by the nodelist generator
| ; This comment may be ignored by a nodelist processor
The first line of a nodelist is a special comment line containing
identification data for the particular edition of the nodelist.
The following is an example of the first line of a nodelist:
;A FidoNet Nodelist for Friday, July 3, 1987 -- Day number 184 : 15943
This line contains the general interest flag, the day, date, and
| three-digit (zero-filled) day-of-year number of publication, and
ends with a 5 digit decimal number with leading zeros, if
necessary. This number is the decimal representation of a check
value derived as follows:
Beginning with the first character of the second line, a
16 bit cyclic redundancy check (CRC) is calculated for the
entire file, including carriage return and line feed
characters, but not including the terminating EOF
character. The check polynomial used is the same one used
for many file transfer protocols:
2**16 + 2**12 + 2**5 + 2**0
The CRC may be used to verify that the file has not been edited.
The importance of this will become evident in the discussion of
NODEDIFF, below. CRC calculation techniques are well documented
| in various technical references, and will not be treated further
here.
The content of the remaining comments in the nodelist are
intended to be informative. Beyond the use of interest flags for
distribution, a processing program need not have any interest in
them.
FIDONEWS 13-47 Page 20 18 Nov 1996
A nodelist data line contains eight variable length "fields"
separated by commas (,). No space characters are allowed in a
data line, and underscore characters are used in lieu of spaces.
The term "alphanumeric character" is defined as the portion of
the ASCII character set from 20 hex through 7E hex, inclusive.
The following discussion defines the contents of each field in a
data line.
Field 1: Keyword
The keyword field may be empty, or may contain one of the
following:
Zone
Begins the definition of a geographic zone and define its
coordinator. All the data lines following a line with the
"Zone" keyword down to, but not including, the next
occurrence of a "Zone" keyword, are regions, networks, and
| nodes within the defined zone. Node entries defined
| immediately after the "Zone" keyword and before the next
| region or host entry are known as zone adminstrative nodes.
| These are allocated by the Zone Coordinator for use by nodes
| in the entire zone; for example, mail gateways between
| FidoNet zones.
Region
Begins the definition of a geographic region and defines
its coordinator. All the data lines following a line with
the "Region" keyword down to, but not including, the
next occurrence of a "Zone", "Region", or "Host"
keyword, are independent nodes within the defined region.
Host
Begins the definition of a local network and defines its
| network coordinator. All the data lines following a line
with the Host keyword down to, but not including, the
next occurrence of a "Zone", "Region", or "Host" keyword,
are local nodes, members of the defined local network.
Hub
Begins the definition of a routing sub-unit within a
multi-level local network. The hub is the routing focal
point for nodes listed below it until the next occurrence
of a "Zone", "Region", "Host", or "Hub" keyword. The hub
entry MUST be a redundant entry, with a unique number, for
one of the nodes listed below it, within its hub segment.
This is necessary because some nodelist processors
eliminate these entries in all but the local network.
Pvt
FIDONEWS 13-47 Page 21 18 Nov 1996
Defines a private node with unlisted number. Private nodes
are only allowed as members of local networks.
Hold
Defines a node which is temporarily down. Mail may be sent
to it and is held by its host or coordinator.
Down
Defines a node which is not operational. Mail may NOT be
sent to it. This keyword may not be used for longer than
two weeks on any single node, at which point the "down"
node is to be removed from the nodelist.
<empty>
| The field contains no text (not the sequence "<empty>"),
| and defines a normal node entry.
| Only one of these may be used in any individual data line.
Field 2: Zone/Region/Net/Node number
This field contains only numeric digits and is a number in the
range of 0 to 32767. If the line had the "Zone", "Region", or
"Host" keyword, the number is the zone, net, or region number,
and the node has an implied node number of 0. Otherwise, the
number is the node number. The zone number, region or net number,
and the node number, taken together, constitute a node's FidoNet
address.
Zone numbers must be unique. Region or net numbers must be unique
within their zone, hub numbers unique be within their net, node
| numbers unique within their net (and region, for regional
| independent nodes, zone for zone administrative entries).
Duplicate node numbers under different hubs within the same net
are not allowed.
Field 3: Node name
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces, and
a comma delimits the end of the field. This is the name by which
the node is known, usually as determined by the node or the
coordinator responsible for compiling the segment.
Field 4: Location
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces. This
field contains the location of the node. It is usually expressed
as the primary local location (town, suburb, city, etc.) plus the
FIDONEWS 13-47 Page 22 18 Nov 1996
identifier of the regional geopolitical administrative district
(state, province, department, county, etc.). Wherever possible,
standard postal abbreviations for the major regional district
should be used (IL, BC, NSW, etc.).
Field 5: Sysop name
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces. This
is the name of the system operator.
Field 6: Phone number
This field contains at least three and usually four numeric
sub-fields separated by dashes (-). The fields are country code,
city or area code, exchange code, and number. The various parts
of the phone number are frequently used to derive cost and
routing information, as well as what number is to be dialed. A
typical example of the data in a phone number field is
1-800-555-1212, corresponding to country 1 (USA), area 800
(inbound WATS), exchange 555, and number 1212.
Alternatively, this field may contain the notation
"-Unpublished-" in the case of a private node. In this case, the
| keyword "Pvt" must appear at the start of the line.
Field 7: Baud rate
This field contains one of the values: 300, 1200, 2400, 9600,
| 19200, or 38400.
| This baud rate is indicative only of the maximum baud rate that
| may be expected when connecting to a node and is generally of use
| only where a calling node needs to adjust the baud rate used to
| dial to the caller's modem speed in order to achieve a
| connection, a requirement that with modem technology available in
| 1996 is rarely if ever needed. This information is largely
| superseded by modem protocol flags (see next section) where any
| two nodes using a common protocol may have other expectations
| with regards to actual transfer rates. Use of the baud rate field
| alone is therefore depreciated.
Field 8 - Flags
This optional field contains data about the specific operation of
the node, such as file requests, modem protocol supported, etc.
Any text following the seventh comma on a data line is taken
collectively to be the flags field. The required format is zero
or more sub-fields, separated by commas. Each sub-field consists
of a flag, possibly followed by a value.
The following flags define special operating conditions:
FIDONEWS 13-47 Page 23 18 Nov 1996
Flag Meaning
CM Node accepts mail 24 hours a day
MO Node does not accept human callers
| LO Node accepts calls only from valid listed node
| numbers in the current FidoNet nodelist
The following flags define modem protocols supported:
Flag Meaning
| V21 ITU-T V21 300 bps full duplex
| V22 ITU-T V22 1200 bps full duplex
| V29 ITU-T V29 9600 bps half duplex
| V32 ITU-T V32 9600 bps full duplex
| V32b ITU-T V32bis 14400 bps full duplex
| V33 ITU-T V33
| V34 ITU-T V34 28800 bps full duplex
H96 Hayes V9600
HST USR Courier HST up to 9600
| H14 USR Courier HST up to 14400
| H16 USR Courier HST up to 16800
MAX Microcom AX/96xx series
PEP Packet Ensemble Protocol
| CSP Compucom Speedmodem
| ZYX Zyxel series
| VFC V.Fast Class
| V32T V.32 Terbo
NOTE: Many V22 modems also support Bell 212A.
If no modem flag is given, Bell 212A is assumed for 1200 bps
systems, ITU-T V22bis is assumed for 2400 bps systems.
The following flags define type of error correction available. A
separate error correction flag should not be used when the error
correction type can be determined by the modem flag. For
| instance, a modem flag of HST implies MNP, V32b implies V32 and
| V42b implies V42. Therefore MNP+HST, H14+MNP, H16+MNP, V32+V32b
| and V42+V42b flag pairs are redundant and should not be used.
Flag Meaning
MNP Microcom Networking Protocol error correction
| V42 ITU-T LAP-M error correction w/fallback to MNP 1-4
| V42b ITU-T LAP-M error correction w/fallback to MNP 1-5
The following flags define the type(s) of compression of mail
packets supported.
Flag Meaning
FIDONEWS 13-47 Page 24 18 Nov 1996
MN No compression supported
| NOTE: While FidoNet nodes usually exchange mail
| using a variety of different file compression
| formats negotiated between individual systems, the
| presence of this flag indicates the INABILITY TO
| RECEIVE MAIL compressed using the SEA ARC version 5
| compression format and/or named according to the
| ARCmail 0.6 mail bundle naming method. This is, by
| convention, the most common mail compression format
| in use within FidoNet. The presence of this flag
| would normally indicate that all mail should be sent
| uncompressed unless there is some overriding
| arrangement with the receiving system.
The following flags indicate the types of file and file update
requests supported.
Flag Meaning
XA Bark and WaZOO file/update requests
XB Bark file/update requests, WaZOO file requests
| XC Bark file requests, WaZOO file file/update
XP Bark file/update requests
XR Bark and WaZOO file requests
XW WaZOO file requests
| XX WaZOO file/update requests
The following flag defines gateways to other domains (mail
networks).
Flag Meaning
Gx..x Gateway to domain 'x..x', where 'x..x` is a string
of alphanumeric characters.
NOTE: Valid values for 'x..x' are assigned by the FidoNet
| International Coordinator or the person appointed as
| Internetworking Coordinator by the FidoNet
| International Coordinator. Current valid values of
'x..x' may usually be found in the notes at the end
| of the current FidoNet nodelist. The most common
| gateway flag is "GUUCP", to denote a gateway to the
| Internet mail system that gates on behalf of the
| fidonet.org internet domain.
The following flags define the dedicated mail periods supported.
They have the form "#nn" or "!nn" where nn is the UTC hour the
mail period begins, '#' indicates Bell 212A compatibility, and '!'
indicates incompatibility with Bell 212A.
Flag Meaning
| #01 Zone 5 mail hour (01:00 - 02:00 UTC)
FIDONEWS 13-47 Page 25 18 Nov 1996
#02 Zone 2 mail hour (02:30 - 03:30 UTC)
| #03 Zone 4 mail hour (08:00 - 09:00 UTC)
#09 Zone 1 mail hour (09:00 - 10:00 UTC)
#18 Zone 3 mail hour (18:00 - 19:00 UTC)
| #20 Zone 6 mail hour (20:00 - 21:00 UTC)
NOTE: When applicable, the mail period flags may be strung
together with no intervening commas, e.g.. "#02#09"
| or "!02!09". Only mail hours other than that
standard within a node's zone should be given. Since
observance of mail hour within one's zone is
mandatory, it should not be indicated.
The following flag defines user-specific values. If present,
this flag MUST be the last flag present in a nodelist entry.
Flag Meaning
Ux..x A user-specified string, which may contain any
alphanumeric character except blanks. This string
may contain one to thirty-two characters of
information that may be used to add user-defined
data to a specific nodelist entry.
| NOTE: Ux..x flags are the mechanism by which new flags may
| be experimentally introduced into the nodelist for a
| trial period to assess their worth. They are
| therefore of a temporary nature, and after their
| introduction they are eventually either promoted
| to a non-U flag or dropped from use altogether.
The FTSC recognizes that the FidoNet International Coordinator is
the ultimate authority over what appears in the FidoNet nodelist.
Also, FTSC is by definition a deliberative body, and adding or
changing a flag may take a considerable amount of time.
Therefore, the FidoNet International Coordinator may temporarily
make changes or additions to the flags as defined in this
document. The FidoNet International Coordinator will then consult
with FTSC over the changes needed to this document to reflect
these temporary changes.
The following are examples of nodelist data lines:
Host,102,SOCALNET,Los_Angeles_CA,Richard_Martz,1-213-874-9484,2400,XP
,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,
| THE NODEDIFF
| With more than thirty-five thousand nodes as of this date (1996),
| the nodelist, even in archive form, is a document of substantial
| size. Since distribution of the nodelist occurs via electronic
file transfer, this file is NOT routinely distributed. Instead,
| when a new nodelist is prepared weekly, it is compared with the
FIDONEWS 13-47 Page 26 18 Nov 1996
previous week's nodelist, and a file containing only the
differences is created and distributed.
| The distribution difference file, called NODEDIFF.nnn, where nnn
is the day-of-year of publication, is actually an editing script
which will transform the previous week's nodelist into the
current nodelist. A definition of its format follows:
The first line of NODEDIFF.nnn is an exact copy of the first line
| of LAST WEEK'S nodelist (i.e. the first line of the nodelist to
| which the current difference file applies). This is used as a
first-level confidence check to insure that the correct file is
being edited. The second and subsequent lines are editing
commands and data.
There are three editing commands and all have the same format:
<command><number>
<command> is a 1 letter command, one of 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 (or skip) nn lines from the input file.
The following illustrate how the first few lines of a
| hypothetical NODEDIFF.213 might look:
;A Friday, July 25, 1986 -- Day number 206 : 27712
D2
A2
;A Friday, August 1, 1986 -- Day number 213 : 05060
;A
C5
This fragment illustrates all three editing commands. The first
line is the first line from the previous nodelist, NODELIST.206.
The next line says "delete the first two lines" from
NODELIST.206. These are the identification line and the line
following it. The next command says "add the next two lines" to
NODELIST.213 at the "current" location. The two data lines are
followed by a command which says "copy five unchanged lines" from
NODELIST.206 to NODELIST.213. Notice that the first line added
| will ALWAYS contain the new nodelist CRC, so that the software
| applying the changes to the old nodelist may check the result of
| its editing.
Since only the differences will be distributed, it is important
to insure the accuracy of the newly created nodelist. This is the
function of the CRC mentioned above. It is sufficient for a
FIDONEWS 13-47 Page 27 18 Nov 1996
program designed to perform the above edits to pick the CRC value
from the first line added to the output file, then compute the
CRC of the rest of the output file. If the two CRCs do not agree,
one of the input files has been corrupted. If they do agree, the
probability is very high (but not 100%) that the output file is
accurate.
For actual distribution, NODEDIFF.nnn is packed into an archive
| file named NODEDIFF.?nn, where 'nn' are the last two digits of
| day-of-year, and '?' indicates the compression format used.
| NODELIST COMPILATION
| This section is included for tutorial reasons and is not intended
| as a definition of any specific method by which FidoNet MUST
| compile its weekly nodelist. It merely represents an attempt to
| document the method by which it currently does so. It is intended
| to be explanatory, and seeks to answer commonly asked questions,
| such as how the nodelist is compiled and where the information
| comes from, why the nodelists used in different FidoNet zones are
| not the same document, and why the difference file generated for
| use in one FidoNet zone cannot be applied to the nodelist
| generated for use in a different zone, even though the week
| numbers match.
| Nodelists are compiled via a distributed method, which follows
| the same structure as the FidoNet coordinator hierarchy. At the
| lowest level, network coordinators maintain a list of the nodes
| in their network and are responsible for the addition, removal
| and correction of individual node's listings in their "segment"
| (as portions of the full nodelist are called). In some larger
| networks, it is common for this job to be shared with hub
| coordinators appointed by the net coordinator, though the
| responsibility for those hub segments still remains with the
| network coordinator.
| At a nominated day during the week, before the regional level
| segment is submitted to the zone coordinator, individual net
| coordinators submit their segments to the regional coordinator
| who subsequently compiles these segments and transmits the merged
| copy to the zone coordinator. These are combined by the zone
| coordinator with the separate segments of other zones and
| compiled into that zone's version of the world nodelist. This
| world nodelist is then compared with the previous week's version,
| a difference file is generated and subsequently distributed
| throughout the zone.
| In some cases, in the interest of saving in transmission times
| and therefore costs, the compilation process itself may be better
| served by the submission of DIFFERENCE FILES rather than full
| net- or region-level segments. Each coordinator therefore retains
| a copy of the previously submitted segments and applies
| difference files to those to derive the new one. This process is
| exactly identical to the NODEDIFF/NODELIST scenario described
| earlier in this document, with the same first line and CRC
FIDONEWS 13-47 Page 28 18 Nov 1996
| validation method used to guard the integrity of the nodelist
| segments.
| For a number of reasons, it is important that publication of the
| nodelist be as timely as possible. These reasons include: the
| nodelist is a definitive list of valid FidoNet addresses that may
| receive mail, and must therefore be as correct and up-to-date as
| possible to save nodes the unnecessary expense of mail routed to
| possibly non-existing addresses; the nodelist contains the list
| of telephone numbers that may be called by any user of the
| FidoNet nodelist and should therefore be accurate so as not to
| unduly annoy owners of those phone numbers should a listed node
| go down and an unsuspecting telephone subscriber inherit the same
| telephone number.
| Given this constraint, the expense of international calls and the
| fact that FidoNet is a worldwide network that exists in many time
| zones, it may be unreasonable to expect the compilation of the
| nodelist to be delayed until each zone coordinator can transmit
| their most up-to-date zone segment to a central authority for
| compilation and subsequent redistribution in any week. For the
| sake of expedience, each zone instead maintains its own separate
| world nodelist which contains a compilation of the current zone's
| latest segments and including the most current copy to hand of
| all other FidoNet zone's segments. The zone level nodelist
| generated each week by each zone coordinator is then transmitted
| to all other zone coordinators for inclusion into their separate
| world nodelist as timing permits.
| In theory, then, the only difference between nodelists
| distributed in each zone in any week are accounted for by timing
| differences in the exchange of each zone's separate segment. In
| practice, other constraints may interfere with timeliness, such
| as the difficulty and expense of international telephonic
| communications. Also, another point of variance is introduced by
| the fact that each zone usually includes its own zone segment
| first into its world nodelist to assist - amongst other things -
| software that uses the nodelist for index generation. Some
| software in common use in FidoNet indexes the nodelist according
| to its sequential order (e.g. version 5 and 6 compiled nodelist
| formats), and including the current zone first before others will
| have a beneficial effect on software performance.
-30-
-----------------------------------------------------------------
FIDONEWS 13-47 Page 29 18 Nov 1996
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 320
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-292|Nodelist-299|Nodelist-306|Nodelist-313|Nodelist-320|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 11666|11555 -111 |11332 -223 |11332 0 |11127 -205 |37|
| 2 | 16356|16324 -32 |16307 -17 |16157 -150 |16300 143 |54|
| 3 | 956| 954 -2 | 954 0 | 942 -12 | 929 -13 | 3|
| 4 | 620| 620 0 | 624 4 | 620 -4 | 620 0 | 2|
| 5 | 97| 97 0 | 95 -2 | 95 0 | 95 0 | 0|
| 6 | 1020| 1020 0 | 1007 -13 | 1007 0 | 999 -8 | 3|
+----+------+------------+------------+------------+------------+--+
| 30715|30570 -145 |30319 -251 |30153 -166 |30070 -83 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 13-47 Page 30 18 Nov 1996
=================================================================
NET HUMOR
=================================================================
From: "Mike Riddle" <
[email protected]>
To: "Baker, Christopher" <
[email protected] (Christopher Baker)>
Date: Mon, 11 Nov 96 09:38:41 -0500
Reply-To: "Mike Riddle" <
[email protected]>
Subject: Fwd: (Fwd) Announcing C+- [humor]
==================BEGIN FORWARDED MESSAGE==================
>From: "Joel Shapiro" <
[email protected]>
>Date: Thu, 7 Nov 1996 18:14:28 -0500
>>Subject: (Fwd) Announcing C+- [humor]
Some more good geek humor . . .
--- Forwarded mail from "Hugo Simao" <
[email protected]>
From: "Hugo Simao" <
[email protected]>
Date: Wed, 6 Nov 1996 14:33:46 -0500
To:
[email protected],
[email protected],
[email protected]
Subject: (Fwd) Announcing C+- [humor]
--- Forwarded mail from "Steve Sashihara"<
[email protected]>
From: "Steve Sashihara"<
[email protected]>
Date: Tue, 5 Nov 1996 10:43:46 -0400
Subject: Announcing C+- [humor]
Announcing: C+- (Pronounced "C More or Less")
Unlike C++, C+- is a subject-oriented language.
Each C+- class instance, known as a subject, holds
hidden members, known as prejudices or undeclared
preferences, which are impervious to outside messages,
as well as public members known as boasts or claims.
The following C operators are overridden as shown:
> better than
< worse than
>> way better than
<< forget it
! not on your life
== comparable, other things being equal
C+- is a strongly typed language based on stereotyping
and self-righteous logic. The Boolean variables TRUE
and FALSE (known as constants in less realistic
languages) are supplemented with CREDIBLE and DUBIOUS,
which are fuzzier than Zadeh's traditional fuzzy
categories. All Booleans can be declared with the
modifiers strong and weak. Weak implication is said to
FIDONEWS 13-47 Page 31 18 Nov 1996
"preserve deniability" and was added at the request of
the DoD to ensure compatibility with future versions of
ADA. Well-formed falsehoods (WFFs) are assignment-
compatible with all booleans. What-if and why-not
interactions are aided by the special conditional
evenifnot X then Y.
C+- supports information hiding and, among friend
classes only, rumor sharing. Borrowing from the Eiffel
lexicon, non-friend classes can be killed by arranging
contracts. Note that friendships are intransitive,
volatile, and non-Abelian.
Operator precedence rules can be suspended with the
directive #pragma dwim, known as the "Do what I mean"
pragma.
ANSIfication will be firmly resisted. C+-'s slogan is
"Be Your Own Standard."
----------------------
Editor's note: if you even laughed once, you're a fellow
nerd.
Steve Sashihara
President, Princeton Consultants Inc.
2 Research Way, Princeton NJ
Phone: 609-987-8787 * Fax: 609-987-0033
E-mail:
[email protected] * Web:
http://www. princeton.com
---End of forwarded mail from "Steve
Sashihara"<
[email protected]>
---------------------------------------------------------------------
Hugo P. Simao |> |>
Staff, CASTLE Laboratory | |
Dept. of Civil Eng'g & Operations Research '-_-_-' '-_-_-'
Princeton University |_____| |_____|
Princeton, NJ 08544 USA \ / \ /
Phone: 1 (609) 258-6809 |---| |---|
FAX: 1 (609) 258-3796 | + |_-_-_-_| + |
E-mail:
[email protected] | = = |
WWW:
http://dragon.princeton.edu |= +++++ =|
Computational And Stochastic Transportation |_____|||||_____|
Logistics Engineering Laboratory | _____|||||_____ |
---------------------------------------------------------------------
---End of forwarded mail from "Hugo Simao" <
[email protected]>
----------------------------------------------------------------------
FIDONEWS 13-47 Page 32 18 Nov 1996
Joel A. Shapiro |> |>
Research Assistant, CASTLE Lab | |
Dept. of Civil Eng'g & Operations Research '-_-_-' '-_-_-'
Princeton University |_____| |_____|
Princeton, NJ 08544 USA \ / \ /
Phone: (609) 258-3839 |---| |---|
Fax: (609) 258-1270 | + |_-_-_-_| + |
E-mail:
[email protected] | = = |
WWW:
http://dragon.princeton.edu |= +++++ =|
Computational And Stochastic Transportation |_____|||||_____|
Logistics Engineering Laboratory | _____|||||_____ |
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."
-Some Smart Guy
----------------------------------------------------------------------
===================END FORWARDED MESSAGE===================
-----------------------------------------------------------------
From: "Mike Riddle" <
[email protected]>
To: "Baker, Christopher" <
[email protected] (Christopher Baker)>
Date: Sat, 02 Nov 96 11:37:30 -0500
Reply-To: "Mike Riddle" <
[email protected]>
Subject: Fwd: [Fwd: Deep Thoughts] (fwd)
==================BEGIN FORWARDED MESSAGE==================
>Date: Fri, 01 Nov 1996 23:15:45 -0600
>To:
[email protected]
>From:
[email protected] (Ron Barzel) (by way of gil sapir
<
[email protected]>)
>Subject: [Fwd: Deep Thoughts] (fwd)
>Reply-To:
[email protected]
Deep Thoughts Contest
-- From a newspaper contest where entrants were asked to imitate
"Deep Thoughts by Jack Handey"
HONORABLE MENTIONS:
My young son asked me what happens after we die. I told him we get
buried under a bunch of dirt and worms eat our bodies. I guess I
should have told him the truth--that most of us go to Hell and burn
eternally--but I didn't want to upset him.
It sure would be nice if we got a day off for the president's
birthday, like they do for the queen. Of course, then we would have
a lot of people voting for a candidate born on July 3 or December
26, just for the long weekends.
FIDONEWS 13-47 Page 33 18 Nov 1996
Democracy is a beautiful thing, except for that part about letting
just any old yokel vote.
Home is where the house is.
Often, when I am reading a good book, I stop and thank my teacher.
That is, I used to, until she got an unlisted number.
As you make your way through this hectic world of ours, set aside a
few minutes each day. At the end of the year, you'll have a couple
of days saved up.
It would be terrible if the Red Cross Bloodmobile got into an
accident. No, wait. That would be good because if anyone needed
it, the blood would be right there.
Give me the strength to change the things I can, the grace to accept
the things I cannot, and a great big bag of money.
The people who think Tiny Tim is strange are the same ones who think
it odd that I drive without pants.
For centuries, people thought the moon was made of green cheese.
Then the astronauts found that the moon is really a big hard rock.
That's what happens to cheese when you leave it out.
Think of the biggest number you can. Now add five. Then, imagine
if you had that many Twinkies. Wow, that's five more than the
biggest number you could come up with!
I bet living in a nudist colony takes all the fun out of Halloween.
The only stupid question is the one that is never asked, except
maybe "Don't you think it is about time you audited my return?" or
"Isn't is morally wrong to give me a warning when, in fact, I was
speeding?"
Once, I wept for I had no shoes. Then I came upon a man who had no
feet. So I took his shoes. I mean, it's not like he really needed
them, right?
When I go to heaven, I want to see my grandpa again. But he better
have lost the nose hair and the old-man smell.
I believe you should live each day as if it is your last, which is
why I don't have any clean laundry because, come on, who wants to
wash clothes on the last day of their life?
I often wonder how come John Tesh isn't as popular a singer as some
people think he should be. Then, I remember it's because he sucks.
Whenever I start getting sad about where I am in my life, I think
about the last words of my favorite uncle: "A truck!"
If you really want to impress people with your computer literacy,
add the words "dot com" to the end of everything you say, dot com.
FIDONEWS 13-47 Page 34 18 Nov 1996
I like to go down to the dog pound and pretend that I've found my
dog. Then I tell them to kill it anyway because I already gave away
all of his stuff. Dog people sure don't have a sense of humor.
THIRD RUNNER UP
I don't know about you, but I enjoy watching paint dry. I imagine
that the wet paint is a big freshwater lake that is the only source
of water for some tiny cities by the lake. As the lake gets drier,
the population gets more desperate, and sometimes there are water
riots. Once there was a big fire and everyone died.
SECOND RUNNER UP
I once heard the voice of God. It said "Vrrrrmmmmm." Unless it was
just a lawn mower.
FIRST RUNNER UP
I gaze at the brilliant full moon. The same one, I think to myself,
at which Socrates, Aristotle, and Plato gazed. Suddenly, I imagine
they appear beside me. I tell Socrates about the national debate
over one's right to die and wonder at the constancy of the human
condition. I tell Plato that I live in the country that has come
the closest to Utopia, and I show him a copy of the Constitution. I
tell Aristotle that we have found many more than four basic elements
and I show him a periodic table. I get a box of kitchen matches and
strike one. They gasp with wonder. We spend the rest of the night
lighting farts.
WINNER
If we could just get everyone to close their eyes and visualize
world peace for an hour, imagine how serene and quiet it would be
until the looting started.
===================END FORWARDED MESSAGE===================
-----------------------------------------------------------------
FIDONEWS 13-47 Page 35 18 Nov 1996
=================================================================
NOTICES
=================================================================
Future History
1 Dec 1996
Twelfth Anniversary of FidoNews Volume 1, Issue 1.
12 Dec 1996
Constitution Day, Russia
26 Jan 1997
Australia Day, Australia.
6 Feb 1997
Waitangi Day, New Zealand.
16 Feb 1997
Eleventh Anniversary of invention of Echomail by Jeff Rush.
29 Feb 1997
Nothing will happen on this day.
25 May 1997
Independence Day, Argentina
11 Jun 1997
Independence Day, Russia
1 Dec 1998
Fifteenth Anniversary of release of Fido version 1 by
Tom Jennings.
31 Dec 1999
Hogmanay, Scotland. The New Year that can't be missed.
15 Sep 2000
Sydney (Australia) Summer Olympiad opens.
-- If YOU have something which you would like to see in this
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
FIDONEWS 13-47 Page 36 18 Nov 1996
=================================================================
FIDONEWS PUBLIC-KEY
=================================================================
[this must be copied out to a file starting at column 1 or
it won't process under PGP as a valid public-key]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
Comment: Clear-signing is Electronic Digital Authenticity!
-----END PGP PUBLIC KEY BLOCK-----
Pending a formal decision about including 'encrypted' material inside
FidoNews from the Zone Coordinator Council, the guts of the FidoNews
public-key have been removed from this listing.
File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the
Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone
1 ZMH at 1200-9600+ HST/V32B.
This section will contain only this disclaimer and instructions until
a ZCC decision is forwarded to the Editor.
Sorry for any inconvenience.
-----------------------------------------------------------------
FIDONEWS 13-47 Page 37 18 Nov 1996
=================================================================
FIDONEWS INFORMATION
=================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------
Editor: Christopher Baker
Editors Emeritii: Thom Henderson, Dale Lovell,
Vince Perriello, Tim Pozar,
Tom Jennings, Sylvia Maxwell,
Donald Tees
"FidoNews Editor"
FidoNet 1:1/23
BBS 1-904-409-7040, 300/1200/2400/14400/V.32bis/HST(ds)
more addresses:
Christopher Baker -- 1:18/14,
[email protected]
[email protected]
(Postal Service mailing address)
FidoNews Editor
P.O. Box 471
Edgewater, FL 32132-0471
U.S.A.
voice: 1-904-409-3040 [1400-2100 ET only, please]
[1800-0100 UTC/GMT]
------------------------------------------------------
FidoNews is published weekly by and for the members of the FIDONET
INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation
of individual articles contributed by their authors or their
authorized agents. The contribution of articles to this compilation
does not diminish the rights of the authors. OPINIONS EXPRESSED in
these articles ARE THOSE OF THE AUTHORS and not necessarily those of
FidoNews.
Authors retain copyright on individual works; otherwise FidoNews is
Copyright 1996 Christopher Baker. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only. For
use in other circumstances, please contact the original authors, or
the Editor.
=*=*=*=*=*=*=*=*=
OBTAINING COPIES: The most recent issue of FidoNews in electronic
form may be obtained from the FidoNews Editor via manual download or
file-request, or from various sites in the FidoNet and Internet.
PRINTED COPIES may be obtained by sending SASE to the above postal
address. File-request FIDONEWS for the current Issue. File-request
FNEWS for the current month in one archive. Or file-request specific
back Issue filenames in distribution format [FNEWSDnn.LZH] for a
FIDONEWS 13-47 Page 38 18 Nov 1996
particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP
where mmm = three letter month [JAN - DEC] and y = last digit of the
current year [6], i.e., FNWSMAY6.ZIP for all the Issues from May 96.
Annual volumes are available as FNEWSn.ZIP where n = the Volume number
1 - 12 for 1984 - 1995, respectively. Annual Volume archives range in
size from 48K to 1.2M.
INTERNET USERS: FidoNews is available via:
http://www.fidonet.org/fidonews.htm
ftp://ftp.fidonet.org/pub/fidonet/fidonews/
ftp://ftp.aminet.org/pub/aminet/comm/fido/
You can read the current FidoNews Issue in HTML format at:
http://www.geocities.com/athens/6894/
STAR SOURCE for ALL Past Issues via FTP and file-request -
Available for FReq from 1:396/1 or by anonymous FTP from:
ftp://ftp.sstar.com/fidonet/fnews/
Each yearly archive also contains a listing of the Table-of-Contents
for that year's issues. The total set is currently about 11 Megs.
=*=*=*=
The current week's FidoNews and the FidoNews public-key are now also
available almost immediately after publication on the Editor's new
homepage on the World Wide Web at:
http://ddi.digital.net/~cbaker84/fidonews.html
There are also links there to jim barchuk's HTML FidoNews source and
to John Souvestre's FTP site for the archives. There is also an email
link for sending in an article as message text. Drop on over.
=*=*=*=*=*=*=*=*=
A PGP generated public-key is available for the FidoNews Editor from
1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from
Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18. It
is also posted twice a month into the PKEY_DROP Echo available on the
Zone 1 Echomail Backbone.
*=*=*=*=*
Anyone interested in getting a copy of the INTERNET GATEWAY FAQ may
file-request GISFAQ.ZIP from 1:133/411.0, or send an internet message
to
[email protected]. No message or text or subject is
necessary. The address is a keyword that will trigger the automated
response. People wishing to send inquiries directly to David Deitch
should now mail to
[email protected] rather than the
previously listed address.
FIDONEWS 13-47 Page 39 18 Nov 1996
*=*=*=*=*
SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
from 1:1/23 [1:18/14] as file "ARTSPEC.DOC". ALL Zone Coordinators
also have copies of ARTSPEC.DOC. Please read it.
"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.
"Disagreement is actually necessary,
or we'd all have to get in fights
or something to amuse ourselves
and create the requisite chaos."
-Tom Jennings
-30-
-----------------------------------------------------------------
