Subj : Re: linked
To : Frank Vest
From : Bob Short
Date : Sat Dec 14 2002 10:38 am
On 13 Dec 02 18:37:39, Frank Vest said the following to Bob Short:
FV> BS> I have a lot of respect for you and your opinions on many topics, but
FV> BS> in this I think you are a bit blinded. Why, I have no idea. Nearly
FV> BS> everyone here has agreed that the current NLF is insufficient to deal
FV> BS> with current (much less emerging) technology.
FV> Agreement? Everyone?
Please read me correctly. I said 'nearly everyone'.
FV> Let me go through this a little better and see what gets stirred up.
OK... but you may not like licking the spoon. ;-)
FV> The Nodelist is a comma delimited file used by Fidonet mailers (and
FV> other programs) to determine /where/ to connect.
And 'how/to what extent' to connect.
FV> Now, using that and your statement, along with the arguments of others
FV> that the Nodelist can not show binkp, telnet and other connection
Correct... in it's current format.
FV> information or emerging technologies, I put it forth that the Nodelist
FV> could not and did not work properly with POTS to begin with. There is
I beg to differ. FTS were written FOR pots, and "adjusted" for IP. All
known analog modem connection methods can be so indicated in the NL.
FV> no indication that my POTS mailer can do emsi, zedzap or other
FV> protocols.
This is independant of the NL, as session protocols are inherently
negotiated at connect. No such info is needed in the NL (for POTS).
FV> The Nodelist gives information on where to contact Nodes. In the POTS
FV> realm, that is the phone number. In the IP world, that is the IP
FV> address or domain name. Protocols are not shown in the Nodelist, and
FV> for good reason. Imagine if there had to be a flag for emsi, zedzap
FV> and all the other POTS protocols. Taking this further, consider POTS
<handing over box of Kleenex>
You're making this sound more complex than it needs. This is because
you're putting different connection types in the same basket. I will
help by understanding that this is NOT about POTS, or POTS session
connect methods. Those are well documented and applied, and are not
in need of revision.
FV> Nodes with multiple phone lines. What if each one wanted to list each
FV> line with different protocols? One line does emsi only while others
FV> will handle other protocols. <whew!>
Again, this session information is automatically negotiated between the
two mailers (not users, btw). Why would one need to differentiate this
in the NL? If a particular mailer cannot negotiate a connection, it's
not writte within FTS specs.
<retrieving Kleenex, wiping brow>
FV> Of course, the argument is that with POTS, the protocols are
FV> negotiated upon connection. There is a thread in the FTSC_PUBLIC
FV> echo that is attempting to work out just such a thing for IP Nodes.
Been reading that, and there are some good ideas there... all of which
should follow the same methods as POTS... built into the mailer, not
the nodelist. I'm pretty sure that some of the IP authors neglected
to take into consideration future technologies, just as the FTSC...
which is why we are here today.
FV> but, if successful, this would remove the need for protocol flags in
FV> the Nodelist for IP Nodes (IE: IBN, IFT and such). This, in turn would
FV> bring the Nodelist back to what it should be. A comma delimited file
FV> for Fidonet mailers to determining "how" to contact other Fidonet
FV> mailers instead of what "protocols" to use to make contact.
I'm not sure this is entirely possible, or even desired. There are
too many factors in IP connection and transport. Too much depends
on 3rd parties (ISP's, DS's, FW's, etc) to incorporate every sort
of possible condition into a mailer(s). We'll still need the NL for
a good share of it.
FV> Even in the IP mailers, there is no indication that the telnet mailer
FV> can do emsi, zedzap or other protocols... but some can. :-)
Again, the abaility to determine that should be built into the mailers.
If it isn't, it's not compliant, and shouldn't be used.
FV> Now, put this into operation. Put the IP or domain in the "name" field
FV> of the Nodelist. Standardize an IP flag ("IP" would do) that tells IP
FV> mailers to access the finger daemon on the default "Fidonet" port at
FV> the IP/domain address listed to get the information on what the Node
FV> is capable of and what port(s).
Fine.... show me an example entry that can do this... without breaking
current software.
FV> To go one step further... It has been pointed out that many IP mailers
FV> don't rely on the Fidonet Nodelist anyway.
Don't they extract the IP info from the NL to create their proprietary
dialing list? If not, who/what tells them?
FV> To anyone that wants to chop this reply up and argue each paragraph,
<putting away jigsaw>
I did read your entire message before replying, as I usually do. :)
I'll leave the technical arguments to the techies, and try to learn
as I read. I don't perport to know a whole lot about the Inet end
of this debate... only that what we have isn't working, and will get
worse as time and technology progress.