FidoNews is published weekly by the International FidoNet
Association as its official newsletter. You are encouraged to
submit articles for publication in FidoNews. Article submission
standards are contained in the file ARTSPEC.DOC, available from
node 1:1/1.
Copyright 1988 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067. IFNA may also be contacted
at PO Box 41143, St. Louis, MO 63141.
Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and
are used with permission.
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them.
Everything here is subject to debate. We publish EVERYTHING
received.
Table of Contents
1. ARTICLES ................................................. 1
FSC-0027 - Proposed Nodelist Flags Update ................ 1
2. COLUMNS .................................................. 10
Bodies Behind the BBS: Don Daniels ...................... 10
RegComm - Communications From RegCon ..................... 12
3. NOTICES .................................................. 14
The Interrupt Stack ...................................... 14
New Medical Echo: MEDLIT -- Medical Literature Discussi .. 14
Latest Software Versions ................................. 14
4. COMMITTEE REPORTS ........................................ 16
IFNA Treasurer's Report .................................. 16
FidoNews 5-49 Page 1 5 Dec 1988
Below you will find the proposed update to the nodelist flags.
This proposal will be open to public comment for a period of
fourteen days from the date it appears in FidoNews. Please
direct all constructive comments to Rick Moore, 1:115/333.
Please don't waste your time and effort with complete rewrites of
this document. What I am looking for is small detail revisions
that will make it a better document, not a complete rewrite.
While I am sure this document will not please anyone completely,
it represents the sum of several months of discussion by the
FTSC, followed by several rounds of revision by myself and the
FidoNet International Coordinator.
A few words concerning the objectives in this update are in
order. First, there was a concerted effort to minimize the size
of the nodelist, which is growing at a very rapid rate.
Second, there was a clear concensus in the FTSC to limit the
content in the nodelist to that needed by FidoNet nodes, rather
than a humanly readable BBS list. Third, there was great demand
to include modem data, expand the data concerning types of
file-request/update supported, provide a flag to denote gateways
to other network domains, and provide a mechanism by which
nonstandard data could be included into a nodelist entry. Last,
and this was my own desire, I tried to make these flags upwardly
compatible with the flags used in the AlterNet nodelist, where
possible.
A machine readable version of this document is available at
1:115/333 as FSC-0027.ARC. Special machine readable versions in
either MultiMate or DCA/RFT (Document Content Architecture /
Revised Form Text) format are available upon special request.
==========
FSC-0027
The Distribution Nodelist
by Ben Baker, 1:100/76
updated by Rick Moore, 1:115/333
December 3, 1988
Copyright 1986, 1987, 1988 International FidoNet Association. All
rights reserved. Duplication and or distribution permitted for
non-commercial purposes only.
This document is a proposed update for the document known under
the names of FSC002-4, FSC-0002, and FTS-0002.
This document defines the format and content of the nodelist for
FidoNews 5-49 Page 2 5 Dec 1988
the Public FidoNet Network (PFN) as published each Friday.
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.
The nodelist is published as an ASCII text file named
NODELIST.nnn, where nnn is the day-of-year of the Friday
publication date. This file is packed into an archive file (by
System Enhancement Associates' ARC utility) named NODELIST.Ann,
where nn are the last two digits of day-of-year.
A companion file, COORD.nnn, lists the coordinators of the
various regions and local networks which constitute the PFN. This
file may be created from NODELIST.nnn by the program COORD.EXE,
distributed by many PFN bulletin boards.
As stated above, NODELIST.nnn is an ASCII text file. It contains
two kinds of lines, comment lines and data lines. Each line is
terminated with an ASCII carriage return and line feed character
sequence, and contains no trailing white-space (spaces, tabs,
etc.). The file is terminated with an end-of-file character (EOF
= decimal character value 26).
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 the nodelist
generating program MakeNL.
; 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,
FidoNews 5-49 Page 3 5 Dec 1988
and day-of-year number of publication, and ends with a 5-digit
decimal number with leading zeros, if necessary. This number is
the decimal representation of a check value derived as follows:
Beginning with the first character of the second line, a
16-bit cyclic redundancy check (CRC) is calculated for the
entire file, including carriage return and line feed
characters, but not including the terminating EOF
character. The check polynomial used is the same one used
for many file transfer protocols:
2**16 + 2**12 + 2**5 + 2**0
The CRC may be used to verify that the file has not been edited.
The importance of this will become evident in the discussion of
NODEDIFF, below. CRC calculation techniques are well documented
in the literature, and will not be treated further here.
The content of the remaining comments in the nodelist are
intended to be informative. Beyond the use of interest flags for
distribution, a processing program need not have any interest in
them.
A nodelist data line contains eight variable length "fields"
separated by commas (,). No space characters are allowed in a
data line, and underscore characters are used in lieu of spaces.
The 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,
nets and nodes within the defined zone.
Region --
Begins the definition of a geographic region and
defines its coordinator. All the data lines following
a line with the "Region" keyword down to, but not
including the next occurrence of a "Region" or "Host"
keyword, are independent nodes within the defined
region.
Host --
Begins the definition of a local network and defines
its host. All the data lines following a line with the
"Host" keyword down to, but not including the next
occurrence of a "Region" or "Host" keyword, are local
FidoNews 5-49 Page 4 5 Dec 1988
nodes, members of the defined local network. The
difference between a region and a local network is in
the routing of messages. A message addressed to a
member of a region is sent direct to the addressee,
while a message to a member of a local network is sent
to the network host.
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 "Hub", "Region", "Host", or "Zone"
keyword. The hub entry MUST be a redundant entry,
with a unique number, for one of the nodes listed
below it. This is necessary because some nodelist
processors eliminate these entries in all but the local
network.
Pvt --
Defines a private node with unlisted number. Private
nodes are only allowed as members of local networks.
Hold --
Defines a node which is temporarily down. Mail may
be sent to it and is held by its host or coordinator.
Down --
Defines a node which is not operational. Mail may NOT
be sent to it. This keyword may not be used for
longer than two weeks on any single node, at which
point the "down" node is to be removed from the
nodelist.
<empty> --
Defines a normal node entry.
Field 2 - 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, constitutes a node's FidoNet
address.
Zone numbers must be unique. Region or net numbers must be
unique within their zone. Other numbers must be unique
within their respective units.
Field 3 - Node name
This field may contain any characters except commas and
spaces. Underscores are used to represent spaces. This is
the name by which the node is known.
FidoNews 5-49 Page 5 5 Dec 1988
Field 4 - Location
This field may contain any characters except commas and
spaces. Underscores are used to represent spaces. This
field contains the location of the node. In the USA it is
typically "City_ST where ST is the standard two-letter
abbreviation for the state.
Field 5 - Sysop name
This field may contain any characters except commas and
spaces. Underscores are used to represent spaces. This is
the name of the system operator.
Field 6 - Phone number
This field contains at least three and usually four numeric
subfields separated by dashes (-). The fields are country
code (1 for USA and Canada), city or area code, exchange
code, and number. The various parts of the phone number
are frequently used to derive cost and routing information,
as well as what number is to be dialed. A typical example
of the data in a phone number field is 1-800-555-1212,
corresponding to country 1 (USA), area 800 (inbound
WATS), exchange 555, and number 1212.
Alternatively, this field may contain the notation
"-Unpublished-" in the case of a private node. In this
case, the keyword "Pvt" must appear on the line.
Field 7 - Baud rate
This field contains one of the values: 300, 1200, 2400,
or 9600, and defines the maximum baud rate supported by the
node.
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 sixth
comma on a data line is taken collectively to be the flags
field. The required format is zero or more subfields,
separated by commas, consisting of a flag, possibly
followed by a value.
The following flags define special operating conditions:
Flag Meaning
CM Node accepts mail 24 hours a day
MO Node does not accept human callers
The following flags define modem protocols supported:
FidoNews 5-49 Page 6 5 Dec 1988
Flag Meaning
CT1 CCITT V21 300 bps
CT2 CCITT V23 1200/75 split bps rate
CT3 CCITT V22 1200 bps full duplex
HAY Hayes V9600
HST USR Courier HST
MAX Microcom AX/96xx series
PEP Telebit TrailBlazer
V32 CCITT V32
V33 CCITT V33
V34 CCITT V34
NOTE: Many V22 modems also support Bell 212A.
If no modem flag is given, Bell 212A is assumed for
1200 bps systems, CCITT 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.
The following flags define the type(s) of compression of
mail packets supported.
Flag Meaning
MN No compression supported
NOTE: The only compression method supported
by FidoNet at this time is SEA's ARC, as
defined by the specs for ARCMail 0.6. When
other types of mail compression are adopted,
indicators for them will be added. For now,
the absence of a compression flag indicates
that ARCMail 0.6 compression is supported.
The following flags indicate the types of file/update
requests supported.
Flag Meaning
XA Bark and WaZOO file/update requests
XB Bark file/update requests, WaZOO file
requests
XP Bark file/update requests
FidoNews 5-49 Page 7 5 Dec 1988
XR Bark and WaZOO file requests
XW WaZOO file requests
The following flag defines gateways to other domains
(networks).
Flag Meaning
Gx Gateway to domain 'x' where 'x` is a value
from 'A' to 'Z` or `1' to '9'.
NOTE: Valid values of 'x' are assigned by
the FidoNet International Coordinator.
Current valid values of 'x' may be found in
the notes at the end of the current FidoNet
nodelist.
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
#02 Zone 2 mail hour (02:30 - 03:30 UTC)
#09 Zone 1 mail hour (09:00 - 10:00 UTC)
#18 Zone 3 mail hour (18:00 - 19:00 UTC)
NOTE: When applicable, the mail period
flags may be strung together with no
intervening commas, eg. "#02#09". Only
mail hours other than that standard within a
node's zone should be given. Since
observance of mail hour within one's zone is
mandatory, it should not be indicated.
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 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. This string may not contain any flags
already defined in this document. FTSC makes
no guarantee that it will not assign an
unused letter/number to new flags. Certain
unused flags are already reserved - see the
FidoNews 5-49 Page 8 5 Dec 1988
list below.
The following flags are reserved for future planned
expansion of existing flags: Mx and Px (where 'x' is any
valid character). This is not meant to imply that FTSC will
not use any to use any other character sequences, and FTSC
reserves the right to assign any flag deemed necessary.
The FTSC recognizes that the FidoNet International
Coordinator is the ultimate authority over what appears in
the FidoNet nodelist. Also, the 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
the FTSC over the changes needed to this document to reflect
these temporary changes.
The following are examples of nodelist data lines:
With more than a thousand nodes, 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 subsequent 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
FidoNews 5-49 Page 9 5 Dec 1988
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 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.Ann, where nn are the last two digits of
day-of-year.
Don Daniels was last year's IFNA President, thus his name should
be the FidoNet equivalent of a "household word". (A "network
word"? A "system word"? A "dirty word"?) In spite of what some
might think, neither "Don" nor "Daniels" is a four-letter word.
Don started Fido 86 at Grumman Data Systems in October, 1984. He
selected Fido software because of the potential benefits of the
network support for a company distributed in so many locations.
The Grumman system is still running, plus two at Don's home.
Then there's the train. Don commutes to New York City via the
Long Island Railroad, and uses his laptop during those two hours
each day to access his mail. He has written a utility named
xOVER which he uses to keep straight the file attaches, special
files, and two independent messages bases (one on the laptop and
one on the home BBS). Don reports that his biggest fear is
getting so involved in what he's doing that he works right past
his stop.
Don's history in FidoNet began as an independent for quite a
while, finally joining net 107 in 1986. He was NC for a year or
so, during which time he operated as the Long Island Hub, a
position he still maintains. After surviving last year's stint
as President of IFNA, Don is still quite active in the organiza-
tion as a Director and member of the Executive Committee.
The year as President took its toll on time for traditional sysop
tasks, and everything else. Both of Don's BBS's have a general
PC-DOS flavor, the IEEE LI one being slanted toward users in the
IEEE community. Experimenting with a "life outside FidoNet", Don
has just re-started on a volleyball team, and is even looking
forward to possible time playing softball in the Spring! When
you spend 25 hours a day working as IFNA President, it does
impact almost everything else.
If we need a mascot for FidoNet, I'm happy to report that Don is
the owner of a black lab, named (what else?) Fido. The other
dog, a viszla named Rexx, is named after the IBM Real-time
Executive Language. A nice touch.
Since leaving Grumman, Don has been an independent computer
consultant, and he's presently on contract with the Jacob Javits
Convention Center in NYC, providing technical support for their
PC, Wang VS, and IBM mainframe systems. Having travelled a bit
in his younger days -- circling the world twice while working
overseas for seven years out a ten year span -- Don is currently
FidoNews 5-49 Page 11 5 Dec 1988
negotiating with the UN for a possible computer consultancy
contract in Kenya. Look for a new zone opening soon, near you!
-------------------
I want to add just a short author's comment. Response to this
column has been underwhelming, at best. Not that I expected
anything else, but sometimes it is nice to be surprised. I plan
to keep going for at least a few more weeks -- after all, I owe
it to the folks who went to the not-inconsiderable trouble to
send me information on themselves -- but when the material stops
coming in, the columns will stop going out. After all, this
ain't fiction. . .
All of the Regional Cordinators of FidoNet meet in a private echo
named RegCon. It is here that we discuss what needs to be done to
enhance FidoNet and help it grow, and to discuss our problems and
solutions to those problems. Very recently David Dodell was
placed in a position that allowed outside interference to affect
his actions and a few errors in judgement were the result. But
from those errors came a new intensity in communications within
RegCon and the development of an entirely new team concept.
There will be those who will immediately attempt to convince you
this can't possibly work because of the politics involved. We can
assure you the only politics involved will be from those who
accuse us of it.
RegCon will, as a team, endeavor to keep all FidoNet SysOps fully
informed of our work. We will do this via messages in a few of
the echoconferences and by a column in FidoNews. We ask that any
of our fellow SysOps feel free to communicate with your local Net
Coordinator and your Regional Coordinator at any time you feel it
necessary. We hope you will all keep your Net Coordinators fully
informed of your feelings and help your Net Coordinators to keep
us informed. If, at any time, you feel that chain of communi-
cations is failing we welcome your direct input with a request
for your concerns to be forwarded to RegCon. Please excuse us for
not responding to messages in any of the echoconferences, as less
than five percent of the net is represented in these areas and it
is not good time management for us to do so. If there is any
problem with this please let us know and we will restrict our
information flow to FidoNews only.
As our first effort to clear our communications channels we would
like to address the subject of the mandated technical require-
ments that were originally to take effect on January 1. That
mandate was rescinded weeks back and it appears we had an almost
total failure in communications when that took place. That
failure was within the RegCon team as it was our responsibility
to deliver the original mandate and our responsibility to commun-
icate to you that it had been rescinded. We are in the process of
informing all of the Net Coordinators and Regional Echo Coordin-
ators of the change to make sure all are aware and we apologize
if we failed to make it perfectly clear.
The Fidonet Technical Specifications Committee is presently
working on new specifications for the software used within the
net. When these specifications are available we will know what
capabilities we will have and will address the uses of those cap-
abilities. We all agree to the need for gating between FidoNet
and the other nets, and the need for good software to make this a
positive move and a move that will be of benefit to all. Trying
to make any decisions before the necessary software is available
was our error and we will do our best to avoid any reoccurances
of "putting the cart before the horse". You can be sure that
RegCon is fully supportive of the work being done by the FTSC and
we hope to see new specifications in the near future.
FidoNews 5-49 Page 13 5 Dec 1988
Remember, if you have any concerns we would appreciate it if you
would address them via NetMail so that we may respond quickly and
directly. We do want your input and we're working very hard to
assure a clear channel for communications for all.
("RegComm" will be a weekly column in FidoNews and your comments
are welcome. Please address your concerns and comments via
NetMail to your Net or Regional Coordinator, you should receive
an answer within a few days. It's your net and we are in need of
your input in order for us to fairly represent you.)
New Medical Echo: MEDLIT -- Medical Literature Discussions
Richard Kaplan
Medical Software Exchange
1:135/3
(305) 325-8709
I am organizing a new echo (MEDLIT) which will include
discussions of current papers in popular medical journals such as
JAMA and NEJM. I think electronic publishing ultimately could
revolutionize the way medical information is disseminated by
minimizing publication delays and providing for efficient
discussion of controversial theories, including direct
communication with authors. Perhaps FidoNet can in some way
contribute to this vision.
Think of MEDLIT as an electronic letters-to-the-editor section of
your favorite medical journal. If the echo is of high enough
quality and has enough participation, I would be willing to
compile the messages periodically and submit them to the editors
of the appropriate journals, similar to the publication of the
"Best of Bix" in Byte magazine at one time.
Let me know if you would like to link into this echo or if you
have any suggestions about organizing it. I am PC-PURSUITABLE,
but if you do not use PC PURSUIT then I will try to link you in
locally as the distribution list grows.
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
Hal DuPrie 1:101/106 Chairman of the Board
Bob Rudolph 1:261/628 President
Matt Whelan 3:3/1 Vice President
Ray Gwinn 1:109/639 Vice President - Technical Coordinator
David Garrett 1:103/501 Secretary
Steve Bonine 1:115/777 Treasurer
IFNA BOARD OF DIRECTORS
DIVISION AT-LARGE
10 Courtney Harris 1:102/732? Don Daniels 1:107/210
11 Bill Allbritten 1:11/301 Hal DuPrie 1:101/106
12 Bill Bolton 3:711/403 Mark Grennan 1:147/1
13 Rick Siegel 1:107/27 Steve Bonine 1:115/777
14 Ken Kaplan 1:100/22 Ted Polczyinski 1:154/5
15 Larry Kayser 1:104/739? Matt Whelan 3:3/1
16 Vince Perriello 1:141/491 Robert Rudolph 1:261/628
17 Rob Barker 1:138/34 Steve Jordan 1:102/2871
18 Christopher Baker 1:135/14 Bob Swift 1:140/24
19 David Drexler 1:19/1 Larry Wall 1:15/18
2 Henk Wevers 2:500/1 David Melnik 1:107/233
Membership for the International FidoNet Association
Membership in IFNA is open to any individual or organization that
pays a specified annual membership fee. IFNA serves the
international FidoNet-compatible electronic mail community to
increase worldwide communications.
Member Name _______________________________ Date _______________
Address _________________________________________________________
City ____________________________________________________________
State ________________________________ Zip _____________________
Country _________________________________________________________
Home Phone (Voice) ______________________________________________
Work Phone (Voice) ______________________________________________
Zone:Net/Node Number ____________________________________________
BBS Name ________________________________________________________
BBS Phone Number ________________________________________________
Baud Rates Supported ____________________________________________
Board Restrictions ______________________________________________
Your Special Interests __________________________________________
_________________________________________________________________
_________________________________________________________________
In what areas would you be willing to help in FidoNet? __________
_________________________________________________________________
_________________________________________________________________
Send this membership form and a check or money order for $25 in
US Funds to:
International FidoNet Association
PO Box 41143
St Louis, Missouri 63141
USA
Thank you for your membership! Your participation will help to
insure the future of FidoNet.
Please NOTE that IFNA is a general not-for-profit organization
and Articles of Association and By-Laws were adopted by the
membership in January 1987. The second elected Board of Directors
was filled in August 1988. The IFNA Echomail Conference has been
established on FidoNet to assist the Board. We welcome your
input to this Conference.
-----------------------------------------------------------------
FidoNews 5-49 Page 19 5 Dec 1988
INTERNATIONAL FIDONET ASSOCIATION
ORDER FORM
Publications
The IFNA publications can be obtained by downloading from Fido
1:1/10 or other FidoNet compatible systems, or by purchasing
them directly from IFNA. We ask that all our IFNA Committee
Chairmen provide us with the latest versions of each
publication, but we can make no written guarantees.
