Hello mark,

On Sunday October 05 2014 12:13, you wrote to me:

 MvdV>> when the INA flag came into the picture over a decade ago, I
 MvdV>> proposed  having protocol flags inherit information from those
 MvdV>> preceding them as an alternative.

 ml> i remember... the problem with that is how to indicate a "no
 ml> capability"...

Eh? I do not understand. What do you mean by "indicating no capability"?

 ml> in the rewrite of the example i gave, you ended up listing the final
 ml> backup system as the main connection and that is not how that
 ml> connection's entity was designed...

You can change the order but it will not make any difference:

,12,some_system,some_location,a_sysop,#-###-###-####,33600,XA,V34,CM,
IBN:site1.tld,ITN:site2.tld,INA:site3.tld,IBN,ITN,IVM,PING

The meaning of the flag is indpendent of its position.

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

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

 ml> yes, the example given was on the ""extreme"" end of the
 ml> belt but it showed how explicitly listing and ordering of the flags
 ml> can be used so that one can set their systems they way they want/need

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

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

Then perhaps those people had there expectations set too high. When
interconnecting nodes in a network one has to abide by a set of common rules to
make it work. Adapting the rules when the network evolves is fine, but one has
to realise that one can not expect the whole network to bend over backwards to
instantly accomodate every demanding nerd's need. Real or perceived.
Cooperation is the key word to the smooth operation of the network and
cooperation is not a one way street. It also means that one can not always get
what one wants. If one can not accept that one can ask too much, that what one
wants, is too outlandish,  puts an unreasonable demand on the network, or even
worse conflicts with the justifiable needs of others, then they will just have
to choose between adapting or leaving...

 MvdV>> That was voted out/shouted down/ignored as well. Instead the
 MvdV>> system continued into one where flag meaning does not depend on
 MvdV>> order.

 ml> i never saw that... what i saw was positional usage which was promoted
 ml> more with the multiple INA flags capabilities...

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

 MvdV>> That happens, one can not always get the system to adopt what
 MvdV>> one thinks is the best way.

 ml> true...

QED

Cheers, Michiel

--- Fmail, Binkd, Golded