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 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. 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. 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, 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. Bob --- GEcho 1.00 * Origin: -= BS BBS =- Portland, OregUn (1:105/38) .