=============================================================================
* Forwarded by Vitaly Lunyov (2:5030/818)
* Area : SPB.SYSOP.INFO (SPB.SYSOP.INFO)
* From : NC5030, 2:5030/0 (12 Nov 98 18:59)
* Subj : ip nodes
=============================================================================
* Crossposted in SPB.SYSOP.INFO
вот. ждем-с.
---------------------------------------------------
From: Denis Saveliev
Area: WWB_SYSOP
Date: 12 Nov 98 00:27:46
From: Lothar Behet (2:2446/301)
To : All
Subj: IP-nodes in the nodelist
* Crossposted in WWB_COORD
* Crossposted in WWB_SYSOP
Hello All!
FYI :)
Regards Lothar
=============================================================================
* Weitergeleitet von Lothar Behet (2:2446/301)
* Area : mymail-lb (MyMail-lb)
* Von : Ward Dossche, 2:292/854 (12 Nov 98 00:12)
* An : Lothar Behet
* Thema : IP-nodes in the nodelist
=============================================================================
Lothar,
Since it's largely your work, you are the 1st-one to know ... this is going
to be distributed in a few minutes. Basically it means a 100% implementation
of your proposal.
Congratulations on the work that has been achieved.
BTW, have you considered the case of an ISDN-only which offers IP as well?
\x/ard
+ Originally to All in the REGCON.EUR echo.
Colleagues,
As of today the nodelist in zone-2 is now open for allowing IP-nodes in the
regular nodelist along the proposal which was drawn-up and refined by our
colleague Lothar Behet and so many helpfull people to whom thanks are due as
well.
Lothar's proposal is appended for those needing details.
The I-suite of flags from 1.1.8.1. through 1.1.8.5. has been implemented in
the flag-checker here and should make it to the world-nodelist, also in the
other zones, without problem as of immediately.
It is clear Lothar's text describes how IP-nodes will be noted in the nodelist,
it does not determine how they will function. Eg IP-only nodes will have to
make arrangements to collect/drop-off their mail.
Since this signals the end of the IP-test-period it is requested that the
people carrying 2:2/3xxx-numbers will be listed in their net-segment with an
IP-entry and when this is done, inform me to remove their 2:2/3xxx-entry.
\x/ard Dossche
ZC/2
************************* QUOTE *************************
> 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.
> 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.
************************ UNQUOTE ************************
