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

  This document is released to the public domain, and may be used,
  copied or modified for any purpose whatever.


  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

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

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

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:  IBN[:24554]
          (old flag from Argus: BND[:24554])
          BinkP protocol  IFC[:60179]
          Raw protocol as used by ifcico  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.  IVM[:3141]
          Vmodem protocol according to Ray Gwinn's SIO-package
          for OS/2  IP
          General flag for special protocol specifications, if
          the flags to 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 ( 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)
        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

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

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