********************************************************************** FTSC FIDONET TECHNICAL STANDARDS COMMITTEE ********************************************************************** 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 -------------------------------------- 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 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: [:<@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 **********************************************************************