FR>> Jerry Schwartz's Perl script is probably the most popular extraction FR>> tool used to generate this file. Up until July of this year a file FR>> created by this script was hatched into the I-BinkD file echo.
FR>> Carol's entry in that extraction of NodeList.224 is...
MR> This is what I've meant with the confusion about which "standard" applies. MR> Apparently Jerry's converter follows the undocumented feature Carol MR> mentioned.
no, it follows what was discussed 11+ years ago when he was working on it...
MR> So it would extract additional addresses which aren't intended for MR> binkp for a node entry following the FTSC docs (if listed take just MR> the address in the IBN flag).
wrong... it extracts the domain from the "system name" field, the INA flag(s) and the IBN flag(s)... the domains listed in the "system name" field and the INA flags are default domains to attempt a connection with... they are valid to use if the domains attached to any IBN flags fail to connect...
MR> How do we resolve this dilemma?
what delima?
MR> If all entries for Z1 nodes follow the undocumented feature then I MR> could add a special case to my tool to take also the addresses listed MR> in the INA flag. And Jerry would have to do the same, just the other MR> way around. The frustating thing is that it's hard for software MR> developers to know about undocumented features. Please tell the FTSC MR> about such stuff, so we are able to document that.
binkd_nodelister.pl has source available and it was distributed in the I-BINKD FDN so it would be available for others to use to generate their own FTN nodelist to binkd NODE list lists... no documentation necessary...
)\/(ark
Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... "Kala Khristougena kai Eftikhes to Neon Ethos." - Greek Christmas --- * Origin: (1:3634/12.73)
