Hello everybody!

I have seen questions and differing thoughts on the use of certain
nodelist flags and their preferred or correct usage. A couple such
flags are INA and IBN and how each should be used to specify nodelist connectivity data. In looking through the current nodelist I see those
two flags used in a couple different ways.

Thoughts on which and why?


Jeff


--- Mystic v1.12 A47/LNX (2020/10/20) GoldED+/LNX 1.1.5-b20170303
* Origin: Region 14 IP Server - ftn.region14.org (1:14/5)

Hello, Jeff!

Thursday October 22 2020 01:01, from Jeff Smith -> All:

I have seen questions and differing thoughts on the use of certain nodelist flags and their preferred or correct usage. A couple such
flags are INA and IBN and how each should be used to specify nodelist connectivity data. In looking through the current nodelist I see those
two flags used in a couple different ways.
Thoughts on which and why?

INA flag tells you that the node supports IP connection and the address is provided. There used to be IP flag for the same reason but because the address itself was optional it is deprecated in favor of INA.

Here, the IBN flag specifies that the Binkp protocol is supported and optionally a non-standard port can be specified. Other supported protocol can be IFC (RAW ifcico), IFT, ITN, or IVM protocol.

It is that the IBN flag cannot include the host address itself, that is why we usually have a combination of INA+IBN in the nodelist.

Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: -=NIL BBS=- (2:5015/46)

Hello Nil,

On Saturday October 24 2020 07:29, you wrote to Jeff Smith:

It is that the IBN flag cannot include the host address itself, that
is why we usually have a combination of INA+IBN in the nodelist.

Wrong.

IBN:fido.vlist.eu or IBN:f5556.vlist.eu:24555 is perfectly valid.

This is shorter than using the INA,IBN combination.

Using the INA flag for the host addess is shorter when there are multiple protocol flags.

INA:fido.vlist.eu,IBN,ITN is fine as well.

It is all documented in FTS-5001.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello Jeff,

On Thursday October 22 2020 01:01, you wrote to All:

Thoughts on which and why?

,5,Region_14_IP_Server,Anoka_MN,Jeff_Smith,-Unpublished-,300,CM,XX,ITN,IFT,INA:ftn.region 14.org:24555,IBN

is wrong. There should be no port number on the INA flag.

The correct use is:

,5,Region_14_IP_Server,Anoka_MN,Jeff_Smith,-Unpublished-,300,CM,XX,INA:ftn.region14.org,I BN:24555,ITN,IFT

Is correct.

Assuming that the ITN andIFT are on the standard port for this node, which is probably not be the case because 1:14/0 uses the same host name but seems a different nod and thos standard ports are alrady in use for 14/0. If ITN and IFT are not on standard ports, it should be:

,5,Region_14_IP_Server,Anoka_MN,Jeff_Smith,-Unpublished-,300,CM,XX,INA:ftn.region14.org,I BN:24555,ITN:portnr,IFT:portnr

,1050,DARK_KNiGHT_BBS,Minneapolis_MN,Nicholas_Boie,-Unpublished-,300,CM,XX,IFT,ITN:60177, IBN:melon.rlaprise.net

This is wrong because the melon.rlaprise.net is only valid for IBN. Ther is np host name associated with IFT and ITN. The correst way:

,1050,DARK_KNiGHT_BBS,Minneapolis_MN,Nicholas_Boie,-Unpublished-,300,CM,XX,INA:melon.rlap rise.net,IBN,IFT,ITN:60177

See also FTS-5001.



Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello, Michiel!

Saturday October 24 2020 09:59, from Michiel van der Vlist -> Nil Alexandrov:

It is that the IBN flag cannot include the host address itself,
that is why we usually have a combination of INA+IBN in the
nodelist.

Wrong.

You are right. I have checked the FTS-5001 http://ftsc.org/docs/fts-5001.006 and these are examples

Example: IBN:host1.example1.tld,IBN:host2.example2.tld
Or: INA:host1.example1.tld,INA:host2.example2.tld,IBN

IBN:fido.vlist.eu or IBN:f5556.vlist.eu:24555 is perfectly valid.
This is shorter than using the INA,IBN combination.

The idea behind is that the node answers on INA defined hostname with different IBN/IFC/.. protocols. It is not that different protocols are served from different machines usually, so the hostname will be mentioned only once.

You can think of it in the following way: INA is the phone number and IBN/IFC/.. is the V32/V42/..

Using the INA flag for the host addess is shorter when there are
multiple protocol flags.

What if a node only supports BinkP protocol? Probably, a single IBN record can hold the hostname itself without additional INA flag, but it would be easier to add a new protocol flag in future.

INA:fido.vlist.eu,IBN,ITN is fine as well.
It is all documented in FTS-5001.

Agreed.

Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: -=NIL BBS=- (2:5015/46)

Jeff wrote (2020-10-22):

Hello everybody!

I have seen questions and differing thoughts on the use of certain nodelist flags and their preferred or correct usage. A couple such
flags are INA and IBN and how each should be used to specify nodelist connectivity data. In looking through the current nodelist I see those
two flags used in a couple different ways.

Thoughts on which and why?

The I?? flags standard is unnecessarily complicated, because someone thought it would be clever to invent different combination of the flags to save a few bytes in the nodelist. But in the real nodelist people often waste 4 bytes with the combination "INA:domain,IBN" (which could also be written as "IBN:domain"). The net result of this is additional complexity for the nodelist parser and the user without any real world savings (which wouldn't matter anyway).

To keep it simple, just ignore the INA flag and use

IBN:domain
or
IBN:domain:port (if your mailer is listening on another port than 24554)

or
IBN:domain,IFC:domain,...
(as there are practically no ifcico-only or EMSI/telnet-only nodes and binkp is the standard FTN TCP/IP protocol, IBN:domain[:port] is all we need).

* Origin: (2:280/464.47)

Nil,

What if a node only supports BinkP protocol? Probably, a single IBN
record can hold the hostname itself without additional INA flag, but it would be easier to add a new protocol flag in future.

New flags of that kind only serve a purpose if there's software to do something meaningful with it.

\%/@rd

--- DB4 - August 7 2020
* Origin: Black Olives Matter (2:292/854)

Nil wrote (2020-10-24):

What if a node only supports BinkP protocol? Probably, a single IBN record can hold the hostname itself without additional INA flag, but it would be easier to add a new protocol flag in future.

A new protocol flag for what purpose|protocol?

What is missing is a flag for binkps (binkp over TLS).

---
* Origin: (2:280/464.47)

Good ${greeting_time}, Oli!

25 Oct 2020 14:02:28, you wrote to Nil Alexandrov:

What if a node only supports BinkP protocol? Probably, a single IBN
record can hold the hostname itself without additional INA flag, but
it would be easier to add a new protocol flag in future.

A new protocol flag for what purpose|protocol?
What is missing is a flag for binkps (binkp over TLS).

TLS is artificially weakened by implanted security holes and barriers against making it a bit more secure. I don't see any good reason to use it for binkp.

However, SBN flag would once be announced... and there would be binkp, but no TLS or other insecure shit.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: ::1 (2:5020/545)

Hello, Alexey!

Sunday October 25 2020 17:13, from Alexey Vissarionov -> Oli:

TLS is artificially weakened by implanted security holes and barriers against making it a bit more secure.

NSA, Snowden, conspiracy theory? Moon landings were faked? Ah, this one is good - every McDonalds in Russian has a bunker under it.

Which part of TLS was screwed by NSA: methods for key exchanging, data encryption, data authentication integrity? How about switching from "weak" AES to GOST one?

However, SBN flag would once be announced... and there would be binkp,
but no TLS or other insecure shit.

As a side note, there was a movement led by a few R50 sysops to run binkp/binkd in I2P network about two years ago, though mostly rejected by the rest of sysops.

Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: -=NIL BBS=- (2:5015/46)

Nil wrote (2020-10-25):

As a side note, there was a movement led by a few R50 sysops to run binkp/binkd in I2P network about two years ago, though mostly rejected by the rest of sysops.

i2p makes a lot of sense. Easy to configure, no stupid certs, no DNS and solves the NAT problem automatically. It's a bit slow, but hey, fidonet has less traffic nowadays than in the 80s when we had dialup modem connections.

My point (and othernet node) is reachable via Tor onion service and i2p. A nodelist flag for overlay networks would be useful too (like IOV:hexhashaddr1.i2p,IOV:hexhashaddr2.onion or I2P:hexhashaddr1,ION:hexhashaddr2). Who cares if other sysops reject it as long as some nodes use it.

---
* Origin: (2:280/464.47)

Re: Nodelist Thoughts?
By: Jeff Smith to All on Thu Oct 22 2020 01:01 am

Hello everybody!

I have seen questions and differing thoughts on the use of certain
nodelist flags and their preferred or correct usage. A couple such
flags are INA and IBN and how each should be used to specify nodelist connectivity data. In looking through the current nodelist I see those
two flags used in a couple different ways.

Thoughts on which and why?

Jeff

The specs grew over time without a great deal of direction. There was an old FAQ back when such was new (no longer on the FTSC site, all the FAQs were removed).

In general there is a proper usage, but older patterns are still there.

If you look up 1:275/0 you will see a sample of a site with dual BINK protocol connection points. Sites that are setup to auto configure INA address will use shenks.synchro.net. Sites setup to auto configure IBN site, will hit shenks.dyndns.org. Both lead to here.

Conversely, 1:275/95 uses a special port for IBN.

xxcarol
--- SBBSecho 2.11-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Nodelist Thoughts?
By: Nil Alexandrov to Jeff Smith on Sat Oct 24 2020 07:29 am

Hello, Jeff!

Thursday October 22 2020 01:01, from Jeff Smith -> All:

I have seen questions and differing thoughts on the use of certain nodelist flags and their preferred or correct usage. A couple such flags are INA and IBN and how each should be used to specify nodelist connectivity data. In looking through the current nodelist I see those two flags used in a couple different ways.
Thoughts on which and why?

INA flag tells you that the node supports IP connection and the address is provided. There used to be IP flag for the same reason but because the addre itself was optional it is deprecated in favor of INA.

Here, the IBN flag specifies that the Binkp protocol is supported and optionally a non-standard port can be specified. Other supported protocol c be IFC (RAW ifcico), IFT, ITN, or IVM protocol.

It is that the IBN flag cannot include the host address itself, that is why usually have a combination of INA+IBN in the nodelist.

Best Regards, Nil

Actually Nil, the IBN can also specify an address. It is just redundant if the same one as the INA address so isn't used then.

xxcarol

PS: Z2 may have a zone rule that allows only 1 address but it's something you'd have to ask Ward about.
--- SBBSecho 2.11-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

The specs grew over time without a great deal of direction.
There was an old
FAQ back when such was new (no longer on the FTSC site, all
the FAQs were
removed).

In general there is a proper usage, but older patterns are
still there.

Thank you for the info Carol.


Does anyone happen to have a copy of the old FAQ's out there?


--- InterEcho 1.21
* Origin: Home Of InterMail/InterEcho (1:106/201)

Does anyone happen to have a copy of the old FAQ's out there?

This is what's in the nodelist now...

;S +---------------------------------------------------------------------- ;S | IP Flags
;S +---------------------------------------------------------------------- ;S | The IP-flag consists of two parts:
;S |
;S | A basic transport and an optional non-standard port, separated by
;S | a colon.
;S |
;S | IBN[:24554] ......... BinkP protocol
;S |
;S | IFC[:60179] ......... Raw protocol as used by ifcico
;S |
;S | IFT[:port] .......... Denotes a system that allows FTP
;S |
;S | ITN[:23] ............ Telnet protocol.
;S |
;S | IVM[:3141] .......... Vmodem protocol
;S |
;S | Note: the optional non-standard port for IBN, IFC, IFT, ITN and IVN
;S | ===== be substituted by an IP-address, in which case the syntax is
;S | follows:
;S |
;S | IBN[:IP-addres] ......... BinkP protocol
;S | IFC[:IP-addres] ......... Raw protocol as used by ifcico
;S | IFT[:IP-addres] ......... Denotes a system that allows
;S | ITN[:IP-addres] ......... Telnet protocol.
;S | IVM[:IP-addres] ......... Vmodem protocol
;S |
;S | IP .................. General flag for special protocol
;S | if the other IP-flags are not relevant.
;S |
;S | INA[:IP-addres] ..... Flag sets the default Internet address used for ;S | any non-email based IP-flag that does not
;S | its own.
;S |
;S | INO4 Indicates that an otherwise IP capable node is unable to
;S | accept incoming connections over IPv4. (FSP-1038)
;S +----------------------------------------------------------------------

The old faq did not have these which were in fact an extension of the old faq.
IBN[:IP-addres]
IFC[:IP-addres]
IFT[:IP-addres]
ITN[:IP-addres]
IVM[:IP-addres]

\%/@rd

--- DB4 - August 7 2020
* Origin: Black Olives Matter (2:292/854)

Ward wrote (2020-11-01):

Does anyone happen to have a copy of the old FAQ's out there?

This is what's in the nodelist now...

.... and it is misleading. This is what FTS-5001 defines:

| Internet Protocol flags use the syntax:
|
| <flag>[:<server address>][:<port>]

According to the nodelist comments a non-standard port is defined like

INA:123.45.67.89,IBN:24556
(only "IP-addres" (sic) are mentioned)

FTS-5001 also allows
IBN:example.com:24556

What a mess...

;S
+----------------------------------------------------------------------
;S | IP Flags ;S +----------------------------------------------------------------------
;S | The IP-flag consists of two parts: ;S |
;S | A basic transport and an optional non-standard port, separated by ;S | a colon.
;S |
;S | IBN[:24554] ......... BinkP protocol
;S |
;S | IFC[:60179] ......... Raw protocol as used by ifcico
;S |
;S | IFT[:port] .......... Denotes a system that allows FTP
;S |
;S | ITN[:23] ............ Telnet protocol.
;S |
;S | IVM[:3141] .......... Vmodem protocol
;S |
;S | Note: the optional non-standard port for IBN, IFC, IFT, ITN and IVN ;S | ===== be substituted by an IP-address, in which case the syntax is ;S | follows:
;S |
;S | IBN[:IP-addres] ......... BinkP protocol
;S | IFC[:IP-addres] ......... Raw protocol as used by ifcico ;S | IFT[:IP-addres] ......... Denotes a system
that allows ;S | ITN[:IP-addres] ......... Telnet protocol. ;S | IVM[:IP-addres] ......... Vmodem protocol
;S |
;S | IP .................. General flag for special protocol
;S | if the other IP-flags are not relevant.
;S |
;S | INA[:IP-addres] ..... Flag sets the default Internet address used for ;S | any non-email based IP-flag that does not ;S | its own.
;S |
;S | INO4 Indicates that an otherwise IP capable node is unable to ;S | accept incoming connections over IPv4. (FSP-1038)
;S
+----------------------------------------------------------------------

The old faq did not have these which were in fact an extension of the old faq. IBN[:IP-addres]
IFC[:IP-addres]
IFT[:IP-addres]
ITN[:IP-addres]
IVM[:IP-addres]

\%/@rd

--- DB4 - August 7 2020
* Origin: Black Olives Matter (2:292/854)

---
* Origin: (2:280/464.47)

Re: Nodelist Thoughts?
By: Dale Barnes to Carol Shenkenberger on Sat Oct 31 2020 11:40 am

The specs grew over time without a great deal of direction.
There was an old
FAQ back when such was new (no longer on the FTSC site, all
the FAQs were
removed).

In general there is a proper usage, but older patterns are
still there.

Thank you for the info Carol.

Does anyone happen to have a copy of the old FAQ's out there?

I don't. Fred Riccio doesn't and if not mistaken, Scott Little doesn't.

I have a draft sent to me by another (have to find their name) that looks like the roots were from the old FAQ. I have to find who sent it to me so I can credit or re-write it.

The old one was written in a day of cofusion and many arguements on how to list an ION. It clarified it in simple terms.

While it would need to be updated anyways, it would save work to have it as a template.

xxcarol
--- SBBSecho 2.11-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

This is what's in the nodelist now...

.... and it is misleading. This is what FTS-5001 defines:

I'm pretty certain there are a number of things in the definitions which are the private agenda of individuals without it being the general usage needing to be defined.

A while ago I did the count of listed sysops, which does not mean 'active' sysops and that count was a disappointment.

Because of these low counts I wonder what the added value is for the community whether or not something is represented in one way or the other way.

The fact is the critical mass of Fidonet has crashed a long time ago, there is no current technology which is going to signify a sudden rebounding of the network ... it's a polite way of saying that most such discussions are at the level of comparing penises.

\%/@rd

--- DB4 - August 7 2020
* Origin: Black Olives Matter (2:292/854)

Re: Nodelist Thoughts?
By: Alexey Vissarionov to Oli on Sun Oct 25 2020 05:13 pm

TLS is artificially weakened by implanted security holes and barriers agains making it a bit more secure. I don't see any good reason to use it for binkp

"implanted security holes"? What utter nonsense. Yes, TLS 1.0 and 1.1 have security holes. That's why they're not recommended for use. If TLS were to be used, 1.3 is the recommened version.

g.
--- SBBSecho 3.11-Win32
* Origin: The Retro Archive (1:138/142)

Hello Carol,

I have seen questions and differing thoughts on the use of certain
nodelist flags and their preferred or correct usage. A couple such
flags are INA and IBN and how each should be used to specify nodelist
connectivity data. In looking through the current nodelist I see those
two flags used in a couple different ways.

The specs grew over time without a great deal of direction. There was an old FAQ back when such was new (no longer on the FTSC site, all the FAQs were removed).
In general there is a proper usage, but older patterns are still there.
If you look up 1:275/0 you will see a sample of a site with dual BINK protocol >connection points. Sites that are setup to auto configure INA address will us
shenks.synchro.net. Sites setup to auto configure IBN site, will hit shenks.dyndns.org. Both lead to here.
Conversely, 1:275/95 uses a special port for IBN.

I lean toward using INA: to specify a FQDN/IP and IBN: to specify BinkP support.
There are some nodes that don't/can't support IBN but do support alternative protocols. In which case the appropriate flag is used. If a non-standard port is in use I use the syntax INA:FQDN/IP:<port>

Jeff

--- BBBS/Li6 v4.10 Toy-5
* Origin: Fidonet: The Ouija Board - Anoka, MN - bbs.ouijabrd.net (1:282/1031)

Hello Ward,

The fact is the critical mass of Fidonet has crashed a long time ago, there is
no current technology which is going to signify a sudden rebounding of the network ... it's a polite way of saying that most such discussions are at the level of comparing penises.

Do we have any volunteers to work up some sort of graphical chart to express the penis data? :)


Jeff


--- BBBS/Li6 v4.10 Toy-5
* Origin: Fidonet: The Ouija Board - Anoka, MN - bbs.ouijabrd.net (1:282/1031)

Hello Jeff,

On Saturday October 31 2020 12:38, you wrote to Carol Shenkenberger:

If a non-standard port is in use I use the syntax INA:FQDN/IP:<port>

Different protocols use different ports. A port is associated with one specific protocol and one protocol only. If a protocol uses a port not standard for that protocol that non standard port applies to that protocol only. Therefore a non standard port should be attached to the protocol flag.

The INA flag is not a protocol flag, but a server address flag. It never carries a port number, just an address.

So this:

,26,Stepping_Stone_BBS,Wichita_Kansas,Jon_Justvig,-Unpublished-,300,CM,INA::steppingstone bbs.com:24555,CM,ITN,IBN

... is wrong. (apart from the double CM flag) The proper way to list is:

,26,Stepping_Stone_BBS,Wichita_Kansas,Jon_Justvig,-Unpublished-,300,CM,INA:steppingstoneb bs.com,ITN,IBN:24555

The system is connectable via steppingstonebbs.com and supports two protocols: IBN and ITN. ITN via the standard port 23 and IBN via the non stamdard port 24555.


From FTS-5001.006:

==== quote == ====

There are five classes of Internet Capability flags:


.1 Internet Protocol Flags
--------------------------

Internet Protocol flags use the syntax:

<flag>[:<server address>][:<port>]

Where <server address> is:
* a fully qualified domain name (FQDN), or
* an IPv6 address encased in square brackets, or
* an IPv4 address in dotted-quad format

and <port> is the decimal service port number. A port number
should only be specified if it is not the default port number
for that protocol.


Default
Flag port Description
--------------------------


IBN 24554 Binkp (FTS-1026 - FTS-1030)
IFC 60179 RAW ifcico (FTS-1024)
IFT 21 FTP (RFC-0959); Note there is currently no widely
accepted authentication scheme for FTP transfers by
Fidonet mailers.
ITN 23 Telnet connection using FTS-1 or any other protocol
designed for classic POTS and modem.
IVM 3141 Vmodem connection using FTS-1 or any other protocol
designed for classic POTS and modem.
IP none Mostly used during the introduction of IP capable
systems to the nodelist. Denotes an unspecified
protocol. (Deprecated)


.2 Server Address Flags
-------------------------

Server address flags use the syntax:

<flag>:<server address>

Where <server address> is the same as for protocol flags.
These flags are used to specify a server address for Internet
Protocol Flags that do not specify an address themselves.

Flag Description
-------------------------

INA This flag sets a default server address used
for any Internet Protocol Flag that does not
specify its own.


.3 Internet Information Flags
-----------------------------

Internet Informations Flags use the syntax:

<flag>

These flags are used to signal additional information
regarding the internet connection.

Flag Description
-------------------------

INO4 Indicates that an otherwise IP capable node is
unable to accept incoming connections over IPv4.
(FRL-1038)
ICM Node accepts mail 24 hours a day using all listed
TCP/IP methods, but not all of the other listed
methods (such as PSTN/ISDN) and therefore cannot
be CM. See FRL-1017.
See also the CM flag under section 5.1



==== end quote ====

Hope this helps.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Ward wrote (2020-11-02):

This is what's in the nodelist now...

.... and it is misleading. This is what FTS-5001 defines:

The fact is the critical mass of Fidonet has crashed a long time ago, there is no current technology which is going to signify a sudden rebounding of the network ... it's a polite way of saying that most such discussions are at the level of comparing penises.

it's not about penises, it's about the incompetence of the guys who are responsible for compiling the NODELIST to put accurate information in the NODELIST and not something that differs from the FTS document about nodelist flags.

---
* Origin: (2:280/464.47)

Jeff,

Do we have any volunteers to work up some sort of graphical chart to express the penis data? :)

I looked in my inbound and it seems a volunteer just popped up.

\%/@rd

--- DB4 - August 7 2020
* Origin: Black Olives Matter (2:292/854)

Re: Nodelist Thoughts?
By: Oli to Ward Dossche on Thu Nov 19 2020 02:39 pm

Ward wrote (2020-11-02):

This is what's in the nodelist now...

.... and it is misleading. This is what FTS-5001 defines:

The fact is the critical mass of Fidonet has crashed a long time ago, there is no current technology which is going to signify a sudden rebounding of the network ... it's a polite way of saying that most suc discussions are at the level of comparing penises.

it's not about penises, it's about the incompetence of the guys who are responsible for compiling the NODELIST to put accurate information in the NODELIST and not something that differs from the FTS document about nodelist flags.

Oli, a lot of times thats the node changing and not letting the NC know.

xxcarol
--- SBBSecho 2.11-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)