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

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

    keyword,node_number,node_name,location,sysop_name,
    phone_number,baud_rate,flags

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

    1.1.8.1.  IBN[:24554] (Argus: BND[:24554])
    	BinkP protocol

    1.1.8.2.  IFC[:60179]
    	Raw protocol as used by ifcico

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

    1.1.8.4.  IVM[:3141]
    	Vmodem protocol

    1.1.8.5.  IP
    	General flag for special protocol specifications, if the
    	flags conforming to 1.1.8.1. to 1.1.8.4. 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 (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)

    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.

Go Back