MR> This is what I've meant with the confusion about which "standard" MR> applies.
The standard is whatever "current practice" is. Binkd.Txt is in widespread use and could be considered current practice.
MR> How do we resolve this dilemma?
FTSC needs to document current practice.
MR> If all entries for Z1 nodes follow the MR> undocumented feature then I could add a special case to my tool to MR> take also the addresses listed in the INA flag.
Good luck getting ALL nodes to do anything. Why only zone 1? It should apply to all FTN networks and zones.
MR> And Jerry would have to do the same, just the other way around.
Jerry is no longer in FidoNet, but the source code is redily available. I've made several bug fixes to it for my own use.
MR> The frustating thing is that it's hard for software developers to MR> know about undocumented features.
Proper testing should uncover current practice. When you wrote your tool, did you check it against BinkD.Txt (with diff, FC, or a similar tool) to see if it was generating the same data file? How many NodeLists did you compare?
MR> Please tell the FTSC about such stuff, so we are able to MR> document that.
Ummm... I think I just did. With EchoMail to the FTSC chair in a public echo conference. It even got the attention of an FTSC member (you). The ball is in your court.
FYI, I agree that using two IBN records, as documented in FTS-5001, would have been a LOT cleaner than one INA and one IBN, but one of each DOES work. To quote a past FTSC chair, "If you do it this way, it will work".
--- Msged/NT 6.0.1 * Origin: Somewhere in New Hampshire's White Mountains (1:132/174)
