Hello mark,

On Monday October 06 2014 15:34, you wrote to me:

 MvdV>> The meaning of the flag is indpendent of its position.

 ml> the meaning isn't the only thing, though... the positioning is
 ml> important... the first one listed is used as the prime connection
 ml> point...

As documented where?

 ml> binkd exhibits this very well...

Binkd does not use the nodelist. It uses its own configuration files. Apples an
oranges.

 ml>> it would be like listing three MXes and having everyone send to
 ml>> the last backup instead of to the main one...

 MvdV>> Wrong analogy. MXs carry a priority. There is no equivalent for
 MvdV>> that with IP connect information in the nodelist. There is

 ml> yes there is... the position of the item within the entity's line...

As documented where?

 MvdV>> possibility to list multiple addresses by repeating a flag with
 MvdV>> a different host name or IP address, but that's it. There is no
 MvdV>> implied priority by order. Wether the application uses the
 MvdV>> first, the last, tries them all or alternates in round robin
 MvdV>> fashion between sessions, is up to the implementation.

 ml> right but it is still positional as those that do support this start
 ml> with the first one and then cycle through the others if needed...

Some may do it, others may do it in a different way.

Listing multiple flags with different hostnames/ip-addresses BTW is not the
preferred way. The preferred way of listing a multi-homed system is to use one
host name and attach exta A or AAAA records to it.

 MvdV>> Sorry, but that is not how the system evolved.  Flag meaning is
 MvdV>> independant of flag order. It is not what I would have choosen,
 MvdV>> had the decision be mine, but it was not. When introducing the
 MvdV>> INA flag, always listing it before the associated protocol
 MvdV>> flags would have been a good start. But the nodelist clerks in
 MvdV>> their infinite wisdom decided otherwise and now there is no way
 MvdV>> back. We just have to live with that.

 ml> this happened because the nodelist clerks don't know these things...

It happened.

 ml> many just list shite in any old order and don't understand why some
 ml> things are listed in the first place...

True enough. It is beyond the powers of the FTSC however to control this. We
are at the mercy of the nodelist clerks.

 ml>> them to operate instead of being forced to operate in the way
 ml>> that others tell them to operate... many drop out because of
 ml>> things like this that can't be resolved to suit their needs...

 MvdV>> Then perhaps those people had there expectations set too high.

 ml> no, they want to connect and share like others but their circumstances
 ml> don't allow what could be allowed if the nodelist were handled
 ml> differently...

There will always be people whose (perceived) needs exceeds what the system can
offer and who refuse to adapt to the system but instead demand that the system
adapts to them. You can't please them all, trying to do that will result in a
bloathed system that pleases no one.

 MvdV>> Cooperation is the key word to the smooth operation of the
 MvdV>> network and cooperation is not a one way street. It also means
 MvdV>> that one can not always get what one wants. If one can not
 MvdV>> accept that one can ask too much, that what one wants, is too
 MvdV>> outlandish,  puts an unreasonable demand on the network, or
 MvdV>> even worse conflicts with the justifiable needs of others, then
 MvdV>> they will just have to choose between adapting or leaving...

 ml> i see no unreasonable demand being put on the network by allowing for
 ml> the flags to be used for each connection point that one may use to
 ml> connect with a system...

I do. The systyem as it has evolved does not provide for that. It can not
provide for that witout redefinig flag use. To demand that is unreasonable as
it is not backward compatible. It will make existing practise fail.

 MvdV>> The opportunity to introduce positional usage went out of the
 MvdV>> window when the nodelist clerks allowed listing the INA flag in
 MvdV>> an arbitrary position instead of only before the associated
 MvdV>> protocol flags. You should have spoken then. Now it is too
 MvdV>> late.

 ml> should have spoken to who?

To your NC/RC/ZC of course.

Ehh..  when was the last ZC2 election?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111