Publication: FSP-1012
Revision: 3
Title: Integration of IP-Nodes in the nodelist
Author: Lothar Behet
Revision Date: 27 June 1999
Expiry Date: 27 June 2001
----------------------------------------------------------------------
Contents:
1. Required fields according to FTS-0005, basic flags
for ip-nodes
2. Optional extensions
3. Addendum
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
A variety of nodelist flags designed to aid the transfer of FidoNet
Technology mail over IP links have entered common usage.
This document specifies a new protocol for handling a session
between two Fidonet Technology systems, and requests discussion
and suggestions for improvements from the Fidonet community.
1. Description of the nodelist format
--------------------------------------
Certain fields have defined values according to FTS-0005.
1.1. Implementation for IP-connectivity
Because of the limited characterset in the phone_field and
to avoid any misinterpretion by conventional dialing, the
ip-specific address-information is entered in another field
and there are additional flags required.
1.1.1. Field #1 (keyword) is PVT for an ip-only node without
conventional phone number related connectivity. In this
case, the phone field contains "-Unpublished-" according
to FTS-0005.
1.1.2. Field #2 (node_number) contains the node number within
his net and zone.
1.1.3. Field #3 (node_name) is used for the FQDN (Fully
Qualified Domain Name) or the static ip-address.
1.1.4. Field #4 (location) contains the geographical location
of the node. While some nets/regions cannot supply their
ip-only nodes with a adequate link, these nodes may be
collected in a seperate net or region, until their
original net/region support additional ip-connectivity.
This special net/region is definitely a temporary solution
for routing within a region or zone!
1.1.5. Field #5 (sysop_name) represants the name of the system
operator.
1.1.6. Field #6 (phone_number) contains the phone_number for
conventional connectivity. In case of an ip-only node
it must contain "-Unpublished-".
1.1.7. Field #7 (baud_rate) contains the maximum baud rate for
conventional connectivity or 300 in case of an ip_only
node.
1.1.8. Field #8 (flags) represents operational definitions for
the node. The ip-flags consist of two parts:
A basic transport and an optional non-standard port,
seperated by a colon.
The default port may be omitted, but is listed as
optional parameter in this document. In some cases,
two flag names are mentioned:
The second one is supported by some software nowadays,
but these values may conflict with other programs, which
not completely decode the length of each individual flag
(i.e. TELN conflicts with the T-flag for online-time)
The additional flags for ip-nodes are:
1.1.8.1. IBN[:24554]
(old flag from Argus: BND[:24554])
BinkP protocol
1.1.8.2. IFC[:60179]
Raw protocol as used by ifcico
1.1.8.3. ITN[:23]
(old flag from Argus: TEL[:23])
Telnet protocol. Some variants of ifcico support
Telnet on port 60177, which should be added as
additional flag ITN:60177.
1.1.8.4. IVM[:3141]
Vmodem protocol according to Ray Gwinn's SIO-package
for OS/2
1.1.8.5. IP
General flag for special protocol specifications, if
the flags 1.1.8.1. to 1.1.8.4. are not conclusive.
1.1.9. Comments on the proposed nodelist flags
The additional flagnames in () are supported at this
moment by Argus, based on the use in z2r50. But the
TEL[NET]-flag stays in conflict with the generally in
all zones and regions used T-flag (online time according
to FSC-0062).
2. Optional extensions for future use
--------------------------------------
While the above mentioned flags (1.1.8.1 to 1.1.8.4) define a
minimum set of operational flags for ip-nodes, several additions
are already foreseeable at this moment.
2.1. Additional sessions_handshake parameters
There is at least one program, which supports several
transport protocols according to chapter 1.1.8. on a
single port. If other programs should imitate this habit,
then the following extension to the flag suite 1.1.8.
(transport[:port[:handshake]]) is advised:
2.1.1. FTS-0001 session handshake: 1
2.1.2. Yoohoo session handshake : Y
2.1.3. EMSI sessions handshake : E
2.1.4. BinkP sessions handshake : B
2.2. Non-handshaking protocols
While the definitions until this chapter describe direct
handshaking sessions with optional password authentification,
there are several other methods for the tunneling of fidonet
data via the internet available.
The setup of these connections does not rely on the nodelist
(at this moment of writing), but we can think of standard
setup procedures to use the nodelist for configuration of
this additional transport methods.
Therefore the following flags 2.2.1. to 2.2.4. are advised
for at least informational purpose.
2.2.1. IFT
FTP (File Transfer Protocol)
generally FTP via "anonymous" access does not implement
any privacy or security, so it should just be used as an
informational flag for interested downlinks.
Session authentification can be arranged by individual
configuration for both participants.
2.2.2. ITX
TransX, an Email based method for mostly Uuencoded
data transfer of packets and files. TransX implements
transfer verification with optional acknowledgement
messages.
2.2.3. IUC
Uuencoded packet (one packet per message)
2.2.4. IMI
Mime based content encapsulation with standard
multipart messages
2.2.5. ISE
SEAT encapsulation with optional acknowledgement messages
2.2.6. IEM
Email based (generally, without exact specification at this
moment)
2.3. Address information for email based procedures
This can be stored on several places:
2.3.1. flag suffix this gives many possiblities, but may
interfere with the maximum length of a
nodelist entry (158 chars in case of
MakeNl).
General flag format: <flag>[:<@address]
flag: ITX,IUC,IMI,ISE,IEM
@address: an email address containing the "@" character
2.3.2. location Does not interfere with ip-mailer, but
suppresses another field in the nodelist
2.3.3. System_name prohibits ip-mailer operation at the same
time and requires additional logic for
a reliable retrieval
2.3.4. Hints for address specification (email flags)
According to the maximum line lenght of a nodelist entry,
IEM:<@address> should be prefered for several formats on
the same address, while each flag can hold its individual
address, if required.
If such an entry does not match the line length requirement,
then the location may be used for the most general address
(normally IEM:@address>).
This should allow a maximum flexibility for email
representation in the limited environment of the
St.Louis nodelist format.
3. Addendum
------------
This proposal is based on a maximum compatibility to generally used
definitions and standards within the Fidonet community.
Future developments might make additions necessary, if they can not
be expressed with the existing set of flags.
A. History
-----------
Rev.1, 991001: Initial public version prepared for FTSC
Rev.2, 990611: Moved 2.2.4 to 2.2.6
Added 2.2.4, 2.2.5, 2.3 and 4
Rev.3, 990627: Added some explanations in 2.2.1 to 2.2.5
