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)
