Publication:    FSP-????
Revision:       1
Title:          Integration of IP-Nodes in the nodelist (FTS-0005)
Author:         Lothar Behet, 2:2446/301
Revision Date:  25 October 1998
Expiry Date:

1. Required fields according to FTS-0005, basic flags for ip-nodes
2. Optional extensions
3. Addendum

1.  Description of the nodelist format

Every node entry contains the following 8 fields:


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

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
	Note that these are user flags.
	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)
	Additional flags for ip-nodes are:  IBN[:24554] (Argus: BND[:24554])
	BinkP protocol  IFC[:60179]
	Raw protocol as used by ifcico  ITN[:23] (Argus: TEL[:23])
	Telnet protocol. Some variants of ifcico support Telnet
	on port 60177, which should be added as additional flag
	ITN:60177.  IVM[:3141]
	Vmodem protocol  IP
	General flag for special protocol specifications, if the
	flags conforming to to are not relevant.

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 ( to 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)

2.2.2.  ITX
	TransX, an Email based variant

2.2.3.  IUC
	Uuencoded packet (one packet per message)

2.2.4.  IEM
	Email based (generally, without exact specification at
	this moment)

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 as defined by this FSP.
BackGo Back