Dec 06 13:06 2018, Fred Riccio wrote to Markus Reschke:
MR>> How do we resolve this dilemma?
FR> FTSC needs to document current practice.
Which one? ;) Now we have two, partly contradicting.
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.
FR> Good luck getting ALL nodes to do anything. Why only zone 1? It FR> should apply to all FTN networks and zones.
I agree that we should have one standard for all nodes. But we have two now and have to figure how to merge them into one.
MR>> The frustating thing is that it's hard for software developers to MR>> know about undocumented features.
FR> Proper testing should uncover current practice. When you wrote your FR> tool, did you check it against BinkD.Txt (with diff, FC, or a similar FR> tool) to see if it was generating the same data file? How many FR> NodeLists did you compare?
I did comparisons with the output of other tools. The funny thing was that my tool extracted more binkp nodes. There are nodes with addresses hidden in the system name or telephone number, the DO4 user flag and more. Besides checking the FTSC docs I had to figure out what else is hidden in the nodelist.
MR>> Please tell the FTSC about such stuff, so we are able to MR>> document that.
FR> Ummm... I think I just did. With EchoMail to the FTSC chair in a FR> public echo conference. It even got the attention of an FTSC member FR> (you). The ball is in your court.
First we have to get all the details of the undocumented standard. How are port numbers handled? If we take Carol's nodelist entry as example and assume she runs binkd on port 8080 we would have: