Text 7382, 123 rader
Skriven 2014-10-06 15:34:21 av mark lewis (1:3634/12.71)
   Kommentar till text 7380 av Michiel van der Vlist (2:280/5555)
Ärende: FTSC-5001 question
==========================
On Mon, 06 Oct 2014, Michiel van der Vlist wrote to mark lewis:

 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"...

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

like when you stacked my example in reverse of the way it was intended to be
accessed... if the inheriting was done, it would indicate that the other sites
also had those capabilities...

 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...

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

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

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

the meaning isn't the only thing, though... the positioning is important... the
first one listed is used as the prime connection point... binkd exhibits this
very well...

 ml> it would be like listing three MXes and having everyone send to the
 ml> 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

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

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

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

 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

 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 flags
 MvdV> would have been a good start. But the nodelist clerks in their
 MvdV> infinite wisdom decided otherwise and now there is no way back.
 MvdV> We just have to live with that.

this happened because the nodelist clerks don't know these things... many just
list shite in any old order and don't understand why some things are listed in
the first place... they don't care as long as systems can connect... one
analogy here is politicians and traffic laws... another is engineers and
technicians trying to describe or work on some item...

 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...

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

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

 MvdV> When interconnecting nodes in a network one has to abide by a set
 MvdV> of common rules to make it work. Adapting the rules when the
 MvdV> network evolves is fine, but one has to realise that one can not
 MvdV> expect the whole network to bend over backwards to instantly
 MvdV> accomodate every demanding nerd's need.

no one is expecting that... the nodelist contains the information needed to
connect one mailer to another... it allows for multiple points of connecting
with a system and it should allow for the details to be used for each point
used...

 MvdV> Real or perceived.
 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 accept
 MvdV> that one can ask too much, that what one wants, is too
 MvdV> outlandish,  puts an unreasonable demand on the network, or even
 MvdV> worse conflicts with the justifiable needs of others, then they
 MvdV> will just have to choose between adapting or leaving...

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

 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...

 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 late.

should have spoken to who? i did speak to some and they adjusted things but who
should have spoken to whom? when? how? hell, the nodelist still has a lot of
junk and i know that numerous folks have had it pointed out to them... some
several years ago... 

)\/(ark

If you think it's expensive to hire a professional to do the job, wait until
you hire an amateur.

--- FMail/Win32 1.60
 * Origin:  (1:3634/12.71)