Feature request

[Michiel van der Vlist]

Hello Binkd team,

I request an option for the node keyword to force binkd into binkp 1.0 mode
when making a connection with the node in question.


-10 this option disables the negotiation that establishes if the remote
supports binkp 1.1 and forces binkd into binkp 1.0 mode when making
a connection with the node in question.
This may be useful when connecting with nodes that advertise 1.1
capability, but who are forced into 1.0 mode or who's binkp 1.1
implementation is flawed.



Cheers, Michiel

[Nicholas Boel]

Hello Michiel,

On 17 Mar 14 16:34, Michiel van der Vlist wrote to Binkd team:

MV> Hello Binkd team,

MV> I request an option for the node keyword to force binkd into binkp 1.0
MV> mode when making a connection with the node in question.


MV> -10 this option disables the negotiation that establishes if the
MV> remote
MV> supports binkp 1.1 and forces binkd into binkp 1.0 mode when
MV> making
MV> a connection with the node in question.
MV> This may be useful when connecting with nodes that advertise 1.1
MV> capability, but who are forced into 1.0 mode or who's binkp 1.1
MV> implementation is flawed.

Is it possible binkd already does something in this regard internally? I have
no problems connecting to IREX links, Argus/Taurus/Radius links, etc., and
never have.

Regards,
Nick

[mark lewis]

On Mon, 17 Mar 2014, Nicholas Boel wrote to Michiel van der Vlist:

MV> -10 this option disables the negotiation that establishes if the
MV> remote
MV> supports binkp 1.1 and forces binkd into binkp 1.0 mode when
MV> making
MV> a connection with the node in question.
MV> This may be useful when connecting with nodes that advertise 1.1
MV> capability, but who are forced into 1.0 mode or who's binkp 1.1
MV> implementation is flawed.

NB> Is it possible binkd already does something in this regard
NB> internally? I have no problems connecting to IREX links,
NB> Argus/Taurus/Radius links, etc., and never have.

you are missing the fact that mbcico, which is where this all started, has a
per node override to force mbcico to speak binkp1.0 with a node but mbcico
still advertises binkp1.1 capability... the above requested override will allow
binkd to be forced into binkp1.0 mode for a node so that they can communicate
with (at least) an overridden mbcico... that's the theory anyway...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

[Michiel van der Vlist]

Hello mark,

On Monday March 17 2014 22:54, you wrote to Nicholas Boel:

ml> you are missing the fact that mbcico, which is where this all started,
ml> has a per node override to force mbcico to speak binkp1.0 with a node
ml> but mbcico still advertises binkp1.1 capability... the above requested
ml> override will allow binkd to be forced into binkp1.0 mode for a node
ml> so that they can communicate with (at least) an overridden mbcico...
ml> that's the theory anyway...

Exactly.


Cheers, Michiel

[Nicholas Boel]

Hello mark,

On 17 Mar 14 22:54, mark lewis wrote to Nicholas Boel:

NB>> Is it possible binkd already does something in this regard
NB>> internally? I have no problems connecting to IREX links,
NB>> Argus/Taurus/Radius links, etc., and never have.

ml> you are missing the fact that mbcico, which is where this all started,
ml> has a per node override to force mbcico to speak binkp1.0 with a node
ml> but mbcico still advertises binkp1.1 capability... the above requested
ml> override will allow binkd to be forced into binkp1.0 mode for a node
ml> so that they can communicate with (at least) an overridden mbcico...
ml> that's the theory anyway...

I see why it is being asked. Basically for use with AWOL mbcico sysops that
can't be reached, the setting can be changed on your end instead of theirs.

In my next message I explained why this was a bad idea. It will only bring more
problems into the mix when people that don't know any better use that setting
and wonder why they can't connect to another binkp link. In other words, while
it may fix one problem (which is with links that are probably leaving Fidonet
anyways, apparantly) with unresponsive links, it will most likely create other
problems in the process.

Question is, is it really worth it?

Regards,
Nick

[Michiel van der Vlist]

Hello Nicholas,

On Monday March 17 2014 17:41, you wrote to me:

MV>> I request an option for the node keyword to force binkd into
MV>> binkp 1.0 mode when making a connection with the node in
MV>> question.
[...]

NB> Is it possible binkd already does something in this regard internally?
NB> I have no problems connecting to IREX links, Argus/Taurus/Radius
NB> links, etc., and never have.

I had problems connecting to nodes running mbcico who's sysop had configured a
manual override to connect to my system using 1.0 mode. If I am unable to wake
up that sysop, there is presently nothing I can do.

What I want is a switch that *I* can toggle in order to establish a connect
with that system. Without having to wait for the other sysop to wake up...


Cheers, Michiel

[Nicholas Boel]

Hello Michiel,

On 18 Mar 14 10:54, Michiel van der Vlist wrote to Nicholas Boel:

MV> I had problems connecting to nodes running mbcico who's sysop had
MV> configured a manual override to connect to my system using 1.0 mode.
MV> If I am unable to wake up that sysop, there is presently nothing I can
MV> do.

Sure, outside of sending them an email and putting them on hold.

MV> What I want is a switch that *I* can toggle in order to establish a
MV> connect with that system. Without having to wait for the other sysop
MV> to wake up...

The only question is, if this is to establish a connection with an unresponsive
sysop that you've mentioned in another message is probably leaving Fidonet soon
anyways, would this added option actually be worth the future headaches of
people accidentally or unknowingly setting it and wondering why the heck they
can't connect to a link when the only thing causing that failure is this
specific option?

I dunno about that, but sure.. whatever floats your boat, I guess. :)

Regards,
Nick

[Michiel van der Vlist]

Hello Nicholas,

On Tuesday March 18 2014 16:29, you wrote to me:

MV>> What I want is a switch that *I* can toggle in order to establish
MV>> a connect with that system. Without having to wait for the other
MV>> sysop to wake up...

NB> The only question is, if this is to establish a connection with an
NB> unresponsive sysop that you've mentioned in another message is
NB> probably leaving Fidonet soon anyways,

That was just an example. There can be other reasons for a sysop to be
unresponsive. In fact it can be an active sysop, who is just not aware that I
am trying to contact him/her.

NB> would this added option actually be worth the future headaches of
NB> people accidentally or unknowingly setting it

What headaches?

NB> and wondering why the heck they can't connect to a link when the only
NB> thing causing that failure is this specific option?

Accidentally setting the option should NOT be the cause of failed connects. Not
if it is done right and the system correctly identifies itself as binkp 1.0
when the option is set. All that happens then is that the extra features in 1.1
can not be used.


Cheers, Michiel

[Nicholas Boel]

Hello Michiel,

On 18 Mar 14 22:52, Michiel van der Vlist wrote to Nicholas Boel:

NB>> The only question is, if this is to establish a connection with
NB>> an unresponsive sysop that you've mentioned in another message is
NB>> probably leaving Fidonet soon anyways,

MV> That was just an example. There can be other reasons for a sysop to be
MV> unresponsive. In fact it can be an active sysop, who is just not aware
MV> that I am trying to contact him/her.

Ah, okay.

NB>> would this added option actually be worth the future headaches of
NB>> people accidentally or unknowingly setting it

MV> What headaches?

Only in the sense that someone doesn't know what it is actually supposed to do,
and decides to enable it anyways. But as you mention below, if it reports which
version it is using correctly, then any other mailer should not have an issue
with it.

NB>> and wondering why the heck they can't connect to a link when the
NB>> only thing causing that failure is this specific option?

MV> Accidentally setting the option should NOT be the cause of failed
MV> connects. Not if it is done right and the system correctly identifies
MV> itself as binkp 1.0 when the option is set. All that happens then is
MV> that the extra features in 1.1 can not be used.

Good point. This goes back to IREX and mbcico reporting the wrong version
number while the other one is being used.

Regards,
Nick