= Сообщение: 4032 из 7124 ====================================== FTSC_PUBLIC = От : Wilfred van Velzen 2:280/464 06 Dec 18 19:37:00 Кому : Markus Reschke 06 Dec 18 19:37:00 Тема : Re: Candidates vision request FGHI : area://FTSC_PUBLIC?msgid=2:280/464+5c096e15 На : area://FTSC_PUBLIC?msgid=2:240/1661+5bfd8f71 = Кодировка сообщения определена как: UTF-8 ================================== ============================================================================== Hi Markus,
On 2018-12-06 18:05:22, you wrote to Fred Riccio:
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. So it would extract additional addresses which aren't intended MR> for binkp for a node entry following the FTSC docs (if listed take just the MR> address in the IBN flag). How do we resolve this dilemma? If all entries MR> for Z1 nodes follow the undocumented feature then I could add a special MR> case to my tool to take also the addresses listed in the INA flag. And MR> Jerry would have to do the same, just the other way around. The frustating MR> thing is that it's hard for software developers to know about undocumented MR> features. Please tell the FTSC about such stuff, so we are able to document MR> that.
Oh, pulllease, we don't need to ammend perfectly good standards with exceptions every time someone claims there is an "other standard", when they just made a little mistake, and don't want to admit it, because that would mean to lose face. They need to grow up, fix their shit, and don't bore the rest of us with their BS...
Bye, Wilfred.
--- FMail-lnx64 2.1.0.18-B20170815 * Origin: FMail development HQ (2:280/464)
