• Nodelist Thoughts?

    From Jeff Smith@1:14/5 to All on Thu Oct 22 01:01:54 2020

    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)
  • From Nil Alexandrov@2:5015/46 to Jeff Smith on Sat Oct 24 07:29:46 2020
    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)
  • From Michiel van der Vlist@2:280/5555 to Nil Alexandrov on Sat Oct 24 09:59:28 2020
    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)
  • From Michiel van der Vlist@2:280/5555 to Jeff Smith on Sat Oct 24 10:05:18 2020
    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)
  • From Nil Alexandrov@2:5015/46 to Michiel van der Vlist on Sat Oct 24 18:00:32 2020
    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)
  • From Oli@2:280/464.47 to Jeff Smith on Sat Oct 24 18:49:45 2020
    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)
  • From Ward Dossche@2:292/854 to Nil Alexandrov on Sat Oct 24 23:26:34 2020
    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)
  • From Oli@2:280/464.47 to Nil Alexandrov on Sun Oct 25 14:02:28 2020
    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)
  • From Alexey Vissarionov@2:5020/545 to Oli on Sun Oct 25 17:13:00 2020
    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)
  • From Nil Alexandrov@2:5015/46 to Alexey Vissarionov on Sun Oct 25 18:38:22 2020
    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)
  • From Oli@2:280/464.47 to Nil Alexandrov on Mon Oct 26 17:05:05 2020
    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)
  • From Carol Shenkenberger@1:275/100 to Jeff Smith on Sat Oct 31 11:36:21 2020
    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)
  • From Carol Shenkenberger@1:275/100 to Nil Alexandrov on Sat Oct 31 11:41:53 2020
    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)
  • From Dale Barnes@1:106/201 to Carol Shenkenberger on Sat Oct 31 11:40:52 2020

    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)
  • From Ward Dossche@2:292/854 to Dale Barnes on Sun Nov 1 01:08:21 2020
    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)
  • From Oli@2:280/464.47 to Ward Dossche on Sun Nov 1 11:14:03 2020
    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)
  • From Carol Shenkenberger@1:275/100 to Dale Barnes on Sun Nov 1 21:15:49 2020
    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)
  • From Ward Dossche@2:292/854 to Oli on Mon Nov 2 09:59:08 2020
    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)
  • From Gene Buckle@1:138/142 to Alexey Vissarionov on Tue Nov 10 06:53:02 2020
    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)
  • From Jeff Smith@1:282/1031 to Carol Shenkenberger on Sat Oct 31 12:38:06 2020
    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)
  • From Jeff Smith@1:282/1031 to Ward Dossche on Mon Nov 2 09:41:24 2020
    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)
  • From Michiel van der Vlist@2:280/5555 to Jeff Smith on Thu Nov 19 09:34:20 2020
    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)
  • From Oli@2:280/464.47 to Ward Dossche on Thu Nov 19 14:39:55 2020
    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)
  • From Ward Dossche@2:292/854 to Jeff Smith on Thu Nov 19 20:29:09 2020
    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)
  • From Carol Shenkenberger@1:275/100 to Oli on Sat Dec 26 13:20:07 2020
    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)