Hi for all candidates,

What is your vision for the future of the FTSC?

What do you want the members to be more proactive at?

How aware are you of the differences among other regions or zones?
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Hello Carol!

22 Nov 18 12:33, you wrote to all:

What is your vision for the future of the FTSC?

I believe that the FTSC needs to continue its work documenting existing standards. There are several BinkP options that are not fully documented at this time. An example would be the ND and NDA options.

What do you want the members to be more proactive at?

It seems that it takes a very long time to get anything done. It shouldn't take a year or more for a FidoNet Standards Proposal to be reviewed and adopted as a standard or filed in the reference library.

How aware are you of the differences among other regions or zones?

There have been differences between Zones for as long as the Zones have existed. Back in the POTS era, they were primarily driven by the differences in how the local telephone providers (be they for profit companies, the government monopoly, or whatever) worked. Here in the US, most if not all telephone companies offer free local calling and incoming calls. Overseas, this is often not the case. Points were much more popular in Europe than they ever were in the US and Canada.

I believe that the FTSC needs input from all Zones as far as any local differences. This is why the ZCs were made invited guests previously, and I think that practice should continue.

Regards,

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hi Andrew,

I believe that the FTSC needs input from all Zones as far as any local differences. This is why the ZCs were made invited guests previously,
and I think that practice should continue.

Do you have a position on censoring mail in general, and by the FTSC-administrator in particular ?

\%/@rd

--- D'Bridge 3.99 SR33
* Origin: If there's an elephant in the room, introduce him (2:292/854)

Hello Andrew,

If you were to become the moderator of a members only restricted distribution conference and an invited guest wrote this in that members only conference: ...

Before you address me on any matter in any conference under whatever
mandate you have, you will have to post an unqualified public apology in
the MAKENL_NG conference where you compared me to dictator Robert
Mugabe from Zimbabwe. Û

Until that day, your interventions do not exist for me ... not as a moderator here and elsewhere, not as the echo-coordinator here and elsewhere, nor as the election 'whatever' here and elsewhere.

... would you allow that writer to continue to participate as "invited guest"

or not?

Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Good ${greeting_time}, Carol!

22 Nov 2018 12:33:04, you wrote to All:

What is your vision for the future of the FTSC?

I'd like it to be the good source of technical expertise for the Fidonet community.

What do you want the members to be more proactive at?

I'd like people who are involved in the development to become FTSC members, raising the overall competence of the FTSC and providing the abovementioned technical expertise.

How aware are you of the differences among other regions or zones?

Some are developing, some are dying... that happens mostly for non-technical reasons, but timely adoption of some technical solutions could save some.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

Good ${greeting_time}, Michiel!

23 Nov 2018 11:51:52, you wrote to Andrew Leary:

MvdV> If you were to become the moderator of a members only restricted
MvdV> distribution conference and an invited guest wrote this in that
MvdV> members only conference: ...

Before you address me on any matter [...]
Until that day, your interventions do not exist for me

MvdV> ... would you allow that writer to continue to participate as
MvdV> "invited guest" or not?

If you'd ask me, I'd say I know at least one conference (here in R50) with members and guests, where guest status is:
* given, if someone of members invites that guest;
* revoked, if three or more members vote for that;
* recovered, if ten or more members vote for that.

Anyway, in a members-only conference the final decision is up to members.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

Hello Ward!

23 Nov 18 10:37, you wrote to me:

I believe that the FTSC needs input from all Zones as far as any
local differences. This is why the ZCs were made invited guests
previously, and I think that practice should continue.

Do you have a position on censoring mail in general, and by the FTSC-administrator in particular ?

Censoring of mail is absolutely not acceptable in my view, by any node. The same goes for adding nodes other than your own or your links to SEEN-BYs with the intent to stop any node from receiving any echo they are connected to.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Andrew!

23 Nov 18 08:50, Andrew Leary wrote to Ward Dossche:

Censoring of mail is absolutely not acceptable in my view, by any
node.

So what should happen with nodes doing that? What about nodes living in countries with laws requiring them to do so?


Regards,
Gerrit

... 6:04PM up 114 days, 1:09, 8 users, load averages: 0.14, 0.21, 0.18

--- Msged/BSD 6.1.2
* Origin: So come and try to tell me (2:240/12)

Good ${greeting_time}, Gerrit!

23 Nov 2018 18:04:32, you wrote to Andrew Leary:

Censoring of mail is absolutely not acceptable in my view,
by any node.

So what should happen with nodes doing that?

#include <FTA-1006>

Before any action could be performed, the facts _must_ be strictly proved.

What about nodes living in countries with laws requiring
them to do so?

If you'd ask me, there would be more than one answer:

0. Fuq those laws (while and where possible).
1. Arrange the echomail distribution to bypass such nodes.
2. Arrange the netmail routing in similar way.

And possibly some more.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... that's why I really dislike fools.
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

Re: Candidates vision request
By: Michiel van der Vlist to Andrew Leary on Fri Nov 23 2018 11:51 am

Hello Andrew,

If you were to become the moderator of a members only restricted distribution conference and an invited guest wrote this in that members

Actually, Andrew and all running, woould you allow a personal issue to intrupt the smooth operation of the FTSC?

Not saying which way either of the 3 running feels on thos one issue, but n general?

xxcarol

--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Hello Carol!

26 Nov 18 19:20, you wrote to Michiel van der Vlist:

Actually, Andrew and all running, woould you allow a personal issue to intrupt the smooth operation of the FTSC?

No. In my time in FidoNet, I've found a way to work with virtually everyone, even those whose beliefs I do not share.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Carol,

On Monday November 26 2018 19:20, you wrote to me:

Actually, Andrew and all running, woould you allow a personal issue to intrupt the smooth operation of the FTSC?

So... Suppose an invited guest brings a personal issue into the members only FTSC echo and refuses your request to drop it. How would you deal with that interuption of the smooth operation of the FTSC?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hi Carol,

So... Suppose an invited guest brings a personal issue into the members only FTSC echo and refuses your request to drop it. How would you deal
with that interuption of the smooth operation of the FTSC?

Hmmm ... here's another variation.

It's about a participant in the ENET.SYSOP-echo, who happens to be an RC and until a short while ago occupied a prominent role in the FTSC-process. At certain moments he posts statistics in said echo but was requested by its moderator to post it in another echo where such technical posts are more common

and make more sense ... The poster has never aknowledged the moderator post in the echo nor has responded to direct netmails ... He continues violating the moderator request as well as the echo rules, because he cannot be stopped...

Any similarity to known people, is not a coincidence ...

Someone must've been hit hard by the door on the way out to keep on harping in this fashion.

Take care,

\%/@rd

--- D'Bridge 3.99 SR33
* Origin: If there's an elephant in the room, introduce him (2:292/854)

Good ${greeting_time}, Michiel!

28 Nov 2018 11:46:56, you wrote to Carol Shenkenberger:

Actually, Andrew and all running, woould you allow a personal
issue to intrupt the smooth operation of the FTSC?

MvdV> So... Suppose an invited guest brings a personal issue into the
MvdV> members only FTSC echo and refuses your request to drop it. How
MvdV> would you deal with that interuption of the smooth operation of
MvdV> the FTSC?

Once the echoarea is members-only, the final decision is up to members.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... god@universe:~ # cvs up && make world
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

Re: Candidates vision request
By: Michiel van der Vlist to Carol Shenkenberger on Wed Nov 28 2018 11:46 am

Hello Carol,

On Monday November 26 2018 19:20, you wrote to me:

Actually, Andrew and all running, woould you allow a personal issue
to intrupt the smooth operation of the FTSC?

Note the question was to them.

So... Suppose an invited guest brings a personal issue into the members only FTSC echo and refuses your request to drop it. How would you deal with that interuption of the smooth operation of the FTSC?

My actions would have been very different from yours. You brought as much 'personal issue' in as Ward did but you then prevented any level of representation on where you were innaccurate.

It turns out later you failed due dilligence to notify the new Z1C that they had guest access which has since been repaired. I could be you felt that was not your job to notify them. I feel it was and if not, notification so others could fix it for you, was in order.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: Alexey Vissarionov to Michiel van der Vlist on Thu Nov 29 2018 10:52 pm

Actually, Andrew and all running, woould you allow a personal
issue to intrupt the smooth operation of the FTSC?

MvdV> So... Suppose an invited guest brings a personal issue into the MvdV> members only FTSC echo and refuses your request to drop it. How MvdV> would you deal with that interuption of the smooth operation of MvdV> the FTSC?

Once the echoarea is members-only, the final decision is up to members.

Agreed. It was for the members to decide.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Hello Carol,

On Saturday December 01 2018 21:25, you wrote to me:

Actually, Andrew and all running, woould you allow a personal
issue to intrupt the smooth operation of the FTSC?

Note the question was to them.

The question was to "Andrew and all running". You are running, you are part of "them". So now I am asking you.

So... Suppose an invited guest brings a personal issue into the
members only FTSC echo and refuses your request to drop it. How would
you deal with that interuption of the smooth operation of the FTSC?

My actions would have been very different from yours.

Of course. Predicting the past is easy. My way of dealing with an invited guest

digging up a personal issue and thereby disrupting the smooth operation of the FTSC obviously failed. Repeating a strategy that failed would be pretty stupid.

But I am not a candidate, you are. So I am asking /you/. How would /you/ handle

the presumed situation? You said you would not allow a personal issue to disrupt the smooth operation of the FTSC, but you have not answered the question of /HOW/ you would deal with it. So I ask you again:

Suppose an invited guest brings a personal issue into the members only FTSC echo and refuses your request to drop it. How would you deal with that disruption of the smooth operation of the FTSC?

It turns out later you failed due dilligence to notify the new Z1C
that they had guest access

Just FYI: Technically, he was invited. The door of my areamanger was unlocked. All he had to do was open it and enter.

which has since been repaired. I could be you felt that was not your
job to notify them. I feel it was

Now that you bring it up, what do you think IS the job of the FTSC administrator? Do you know where it is documented? Can you tell me what the job

desciption of the FTSC administrator says about invited guests? In casu: can you point me to the part where it says that it is the job of the FTSC administrator to take initiative in sending invitations to new invited guests?


Cheers, Michiel

--- Fmail, Binkd, Golded
* Origin: http://www.vlist.org (2:280/5555)

On Saturday December 01 2018 21:25, you wrote to me:

Note the question was to them.

So here is a question specifically addressed to you. The other candidates may press the "next" key.

Considering FTA-1000 paragraph 1.2

"Encouraging new technologies in Fidonet software development"

If elected, Will you lead by example and upgrade your system so that your binkp

server is connectable via IPv6?


Cheers, Michiel

--- Fmail, Binkd, Golded
* Origin: http://www.vlist.org (2:280/5555)

On 02 Dec 18 15:58:29, Michiel Van Der Vlist said the following to Carol Shenke

It turns out later you failed due dilligence to notify the new Z1C that they had guest access

Just FYI: Technically, he was invited. The door of my areamanger was unlock All he had to do was open it and enter.

There are MANY doors I can access, with all of the systems I connect with.

I believe in being polite and knock on the door first, or better, the owner of the door sends me an invitation to come on in.

I do not have time to run around knocking on or opening doors to see what I can access.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Re: Candidates vision request
By: Michiel van der Vlist to Carol Shenkenberger on Sun Dec 02 2018 04:46 pm

Considering FTA-1000 paragraph 1.2

"Encouraging new technologies in Fidonet software development"

If elected, Will you lead by example and upgrade your system so that your binkp
server is connectable via IPv6?

This guy just sounds like a prick.
--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Nick,

On Sunday December 02 2018 11:44, you wrote to me:

@MSGID: 1:229/426 2C0B4F9B

No reply kludge.
No TZUTC kudge
No CHRS kludge

Just FYI: Technically, he was invited. The door of my areamanger
was unlock

^^
Line truncated. "ed" missing.

I believe in being polite and knock on the door first,

But you didn't knock on my door. Instead you accepted an unauthorized link.

No brownie points for you.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello Carol,

And now... something completely different. A technical question.

,100,Shenks_Express,Virginia_Beach_VA,Carol_Shenkenberger,-Unpublished-, 300,XX,CM,INA:shenks.synchro.net,IBN:shenks.dyndns.org

Can you tell us according to what part(s) of which FTSC standard(s) this nodelist entry contains information that is never used by a properly configured
mailer?

Try to use less than 4096 bytes for your answer.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Re: Candidates vision request
By: Michiel van der Vlist to Carol Shenkenberger on Sun Dec 02 2018 03:58 pm

Note the question was to them.

The question was to "Andrew and all running". You are running, you are part of "them". So now I am asking you.

Ok, but you should ask them as well, not just me.

So... Suppose an invited guest brings a personal issue into the
members only FTSC echo and refuses your request to drop it. How
would you deal with that interuption of the smooth operation of the
FTSC?

I have dealt with similar over the decades. The frst was Cott Lang (original Regade author) then many tothers, including some very intersting ones when election coodinator for FN_SYSOP and some not well behaved people.

I never cut access then dissed them after leaving them no rebuttal. In fact, I never cut access. I was always handle to handle such with actually talking to the person. We are different. You see black and white and I see shades of grey. I work within that to create cooperation.

Suppose an invited guest brings a personal issue into the members only FTSC echo and refuses your request to drop it. How would you deal with

Best I can see is you accused Ward of being something like an infamous African dictator and he objected. I would have taken that offline and worked it out.

It turns out later you failed due dilligence to notify the new Z1C
that they had guest access

Just FYI: Technically, he was invited. The door of my areamanger was unlocked. All he had to do was open it and enter.

There is no 'mandate' to tell them. That document has not been looked at for revision since it happened just as you assumed office, so, didnt happen. This is an FTSC member failure and i am equally guilty as I didn't see it until we found a new ZC was not told. Did you bother to notify the Z4C? They changed too since you came in.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: Michiel van der Vlist to Carol Shenkenberger on Sun Dec 02 2018 04:46 pm

So here is a question specifically addressed to you. The other candidates may press the "next" key.

Considering FTA-1000 paragraph 1.2

"Encouraging new technologies in Fidonet software development"

If elected, Will you lead by example and upgrade your system so that your binkp server is connectable via IPv6?

Ths is not an available service in my area unless going commercial connectivity at *significant* cost. Initial foray locally showed close to 1,000$ a month but I can see that is breaking free in some areas here (USA/Canada). The time is not yet here but we have pockets of it. For now, no, I do not have that much money a month to go commercial.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Re: Candidates vision request
By: Nick Andre to Michiel Van Der Vlist on Sun Dec 02 2018 11:44 am

I believe in being polite and knock on the door first, or better, the owner of the door sends me an invitation to come on in.

Nick, I should have seen this and sorry I missed it. Did we miss Z4C as well?

I should have seen it but missed it and apologize and a FTSC memmber.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: Michiel van der Vlist to Carol Shenkenberger on Mon Dec 03 2018 03:37 pm

And now... something completely different. A technical question.

Why am I not suprized?

,100,Shenks_Express,Virginia_Beach_VA,Carol_Shenkenberger,-Unpublished-, 300,XX,CM,INA:shenks.synchro.net,IBN:shenks.dyndns.org

Can you tell us according to what part(s) of which FTSC standard(s) this nodelist entry contains information that is never used by a properly configured mailer?

What standards do you show to represent when a site has 2 resolving addresses, one preferred for IBN but the other for everything? Z1 practical resolution, yet another thing not documented. The world is not black and white.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Hi Carol!

Dec 04 21:46 2018, Carol Shenkenberger wrote to Michiel van der Vlist:

300,XX,CM,INA:shenks.synchro.net,IBN:shenks.dyndns.org

Can you tell us according to what part(s) of which FTSC standard(s)
this nodelist entry contains information that is never used by a
properly configured mailer?

What standards do you show to represent when a site has 2 resolving addresses, one preferred for IBN but the other for everything? Z1 practical resolution, yet another thing not documented. The world is
not black and white.

Putting on my software developer hat, I'm quite unhappy with such undocumented features. I've written a small tool to extract the binkp nodes from the nodelist. The FTSC documentation states that the IBN flag should carry a FQDN/IP when binkd is accepting calls only on that FQDN/IP and it's different from the FQDN/IP in the INA flag. Or in other words, the FQDN/IP in the IBN flag prevails and no other address should be called by binkd. In your case the tool would take just shenks.dyndns.org as explained above. But with the undocumented feature I would have to add a special case which also takes shenks.synchro.net as second address. The big problem is that I can't know which nodelist entry follows the FTSC docs and which one follows the undocumented feature. To resolve this delemma we would need a new flag indicating which method applies (standard or undocumented feature). Or we could
simply follow the FTSC documented standard. These are things we have to take into account when creating zone specific special features. They can lead to unexpected results. In this case no nodelist-to-binkd converter is able to extract the correct addresses because there is no way to figure out which "standard" was used for a specific node.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Hello Carol,

On Tuesday December 04 2018 21:46, you wrote to me:

,100,Shenks_Express,Virginia_Beach_VA,Carol_Shenkenberger,-Unpubl
ished-, 300,XX,CM,INA:shenks.synchro.net,IBN:shenks.dyndns.org

Can you tell us according to what part(s) of which FTSC
standard(s) this nodelist entry contains information that is
never used by a properly configured mailer?

FAIL.

From FTS-5001.006:

INA This flag sets a default server address used
for any Internet Protocol Flag that does not
specify its own.

So, a properly configured binkp mailer will see that the IBN flag carries a server address. It will use that and nothing alse to connect. A binkp mailer will NOT look at the INA flag since that is to be used for any other protocol who's flag has no server address of its own. But there are no other IP protocol

flags. So no mailer will ever use the server address from the INA flag. The INA

flag is dead wood. It is "unreachable code".

What standards do you show to represent when a site has 2 resolving addresses, one preferred for IBN but the other for everything? Z1 practical resolution, yet another thing not documented.

It /IS/ documented. FTS-5001.006:

Multihomed systems
------------------

Multihomed systems or systems that are otherwise reacheable by more
than one address, may - instead of adding another A or AAAA record
to the DNS zone of the host name - repeat the flag(s) carrying the
address with another address.

Example: IBN:host1.example1.tld,IBN:host2.example2.tld
Or: INA:host1.example1.tld,INA:host2.example2.tld,IBN


This was discussed by the FTSC members in the Private FTSC area in 2017. You are an FTSC member, you were there. Apparently you did not pay attention.

The world is not black and white.

Some things ARE black and white. A woman is either pregnant or she is not. One can not be a little bit pregnant.

FTS-5001 is clear. Sorry Carol, the listing for 1: 275/100 is not FTSC complient. And you failed to see why. You failed the test.



Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello Carol,

On Tuesday December 04 2018 21:32, you wrote to me:

If elected, Will you lead by example and upgrade your system so
that your binkp server is connectable via IPv6?

Ths is not an available service in my area unless going commercial connectivity at *significant* cost. Initial foray locally showed
close to 1,000$ a month but I can see that is breaking free in some
areas here (USA/Canada). The time is not yet here but we have pockets
of it. For now, no, I do not have that much money a month to go commercial.

I take that as a "no".

Question:

Are you aware that to help out those that can not get native IPv6 from there own ISP, there are providers that offer a so called "tunnel service" for free? Can you name one of hem?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello Carol,

On Tuesday December 04 2018 21:18, you wrote to me:

Did you bother to notify the Z4C? They changed too since you came in.

ZC4, both the present one and his predecessor have been asked by netmail if they were interested in an invitation. Not once, but several times over the years. There never was a response. Apparently they were not interested.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello Carol,

On Tuesday December 04 2018 21:18, you wrote to me:

The question was to "Andrew and all running". You are running,
you are part of "them". So now I am asking you.

Ok, but you should ask them as well, not just me.

You were the one bringing "personal issue" into the discussion. So I am asking you.

So... Suppose an invited guest brings a personal issue into the
members only FTSC echo and refuses your request to drop it. How
would you deal with that interuption of the smooth operation of
the FTSC?

I have dealt with similar over the decades. The frst was Cott Lang (original Regade author) then many tothers, including some very
intersting ones when election coodinator for FN_SYSOP and some not
well behaved people.

I specifically asked about the private FTSC echo. It is different from most other echos as it is a members and invited guests only echo.

Suppose an invited guest brings a personal issue into the members
only FTSC echo and refuses your request to drop it. How would you
deal with

Best I can see is you accused Ward of being something like an infamous African dictator and he objected.

Really? Did you actually see me use the word "dictator" in public or is your judgement based on hearsay? Whatever happened, it was not me that brought the alleged personal issue into th eprivate FTSC aera.

Anyway, I did not ask how you think I should have handled it. I am not a candidate. You are, so I am asking you how YOU would handle it.

I would have taken that offline and worked it out.

How would you do that? "take it offline"? It takes two to tango. How do you do that if the party concerns refuses to cooperate in "taking it offline"?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello Markus,

On Wednesday December 05 2018 21:10, you wrote to Carol Shenkenberger:

The big problem is that I can't know which nodelist entry follows the
FTSC docs and which one follows the undocumented feature. To resolve
this delemma we would need a new flag indicating which method applies (standard or undocumented feature). Or we could simply follow the FTSC documented standard.

One of the reasons for having standards is to ensure that software behaves in a

predictable and reliable way. We should not have this discussion at all.

While Fidonet is divided into zones, it is technically one network and so the same technical standards must apply network wide. To ensure the smooth operation of the network, nodelist clerks must follow the FTSC standards. Period. No discussion. No "Zx does it different" nonsense.

If the *C is also an FTSC member, ignorance is no excuse. FTSC members should know the standards. If (s)he is a candidate for the chair....

I will leave the judgement to the reader...


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

06 Dec 18 00:38, Michiel van der Vlist wrote to Carol Shenkenberger:

,100,Shenks_Express,Virginia_Beach_VA,Carol_Shenkenberger,-Unpubl
ished-, 300,XX,CM,INA:shenks.synchro.net,IBN:shenks.dyndns.org

[ ... ]

MvdV> So, a properly configured binkp mailer will see that the IBN flag
MvdV> carries a server address. It will use that and nothing alse to
MvdV> connect. A binkp mailer will NOT look at the INA flag since that is
MvdV> to be used for any other protocol who's flag has no server address
MvdV> of its own. But there are no other IP protocol flags. So no mailer
MvdV> will ever use the server address from the INA flag. The INA flag is
MvdV> dead wood. It is "unreachable code".

I beg to differ. I know I don't have to explain to you that BinkD (the de-facto standard) does NOT use the raw nodelist to get the IP address. It CAN, if properly configured, use Binkd.Txt, an extraction of BinkP nodes from the NodeList.

Jerry Schwartz's Perl script is probably the most popular extraction tool used to generate this file. Up until July of this year a file created by this script was hatched into the I-BinkD file echo.

Carol's entry in that extraction of NodeList.224 is...

Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -

which is causes BinkD to try the dyndns.org host first, if it doesn't resolve it tries the synchro.net address.

The data attached to the INA flag in this example is NOT dead wood. It is usable if you use the software I have mentioned above.

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Hello Fred!

Dec 06 10:58 2018, Fred Riccio wrote to Michiel van der Vlist:

Jerry Schwartz's Perl script is probably the most popular extraction
tool used to generate this file. Up until July of this year a file created by this script was hatched into the I-BinkD file echo.

Carol's entry in that extraction of NodeList.224 is...

Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -

This is what I've meant with the confusion about which "standard" applies. Apparently Jerry's converter follows the undocumented feature Carol mentioned. So it would extract additional addresses which aren't intended for binkp for a node entry following the FTSC docs (if listed take just the address in the IBN flag). How do we resolve this dilemma? If all entries for Z1 nodes follow the undocumented feature then I could add a special case to my tool to take also the addresses listed in the INA flag. And Jerry would have to do the same, just
the other way around. The frustating thing is that it's hard for software developers to know about undocumented features. Please tell the FTSC about such
stuff, so we are able to document that.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

06 Dec 18 18:05, Markus Reschke wrote to Fred Riccio:

Carol's entry in that extraction of NodeList.224 is...

Typo. NodeList.334

Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -

This is what I've meant with the confusion about which "standard" applies.

The standard is whatever "current practice" is. Binkd.Txt is in widespread use
and could be considered current practice.

How do we resolve this dilemma?

FTSC needs to document current practice.

If all entries for Z1 nodes follow the
undocumented feature then I could add a special case to my tool to
take also the addresses listed in the INA flag.

Good luck getting ALL nodes to do anything. Why only zone 1? It should apply to all FTN networks and zones.

And Jerry would have to do the same, just the other way around.

Jerry is no longer in FidoNet, but the source code is redily available. I've made several bug fixes to it for my own use.

The frustating thing is that it's hard for software developers to
know about undocumented features.

Proper testing should uncover current practice. When you wrote your tool, did you check it against BinkD.Txt (with diff, FC, or a similar tool) to see if it was generating the same data file? How many NodeLists did you compare?

Please tell the FTSC about such stuff, so we are able to
document that.

Ummm... I think I just did. With EchoMail to the FTSC chair in a public echo conference. It even got the attention of an FTSC member (you). The ball is in
your court.


FYI, I agree that using two IBN records, as documented in FTS-5001, would have been a LOT cleaner than one INA and one IBN, but one of each DOES work. To quote a past FTSC chair, "If you do it this way, it will work".

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Hi Markus,

On 2018-12-06 18:05:22, you wrote to Fred Riccio:

Jerry Schwartz's Perl script is probably the most popular extraction
tool used to generate this file. Up until July of this year a file
created by this script was hatched into the I-BinkD file echo.

Carol's entry in that extraction of NodeList.224 is...

Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -

This is what I've meant with the confusion about which "standard" applies. Apparently Jerry's converter follows the undocumented feature Carol mentioned. So it would extract additional addresses which aren't intended for binkp for a node entry following the FTSC docs (if listed take just

the

address in the IBN flag). How do we resolve this dilemma? If all entries for Z1 nodes follow the undocumented feature then I could add a special case to my tool to take also the addresses listed in the INA flag. And Jerry would have to do the same, just the other way around. The frustating thing is that it's hard for software developers to know about undocumented features. Please tell the FTSC about such stuff, so we are able to

document

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)

Jerry is no longer in FidoNet, but the source code is readily available. I've made several bug fixes to it for my own use.

Same here.

http://eljaco.se/FILES/bnl.rar



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Hello Fred!

Dec 06 13:06 2018, Fred Riccio wrote to Markus Reschke:

How do we resolve this dilemma?

FTSC needs to document current practice.

Which one? ;) Now we have two, partly contradicting.

If all entries for Z1 nodes follow the
undocumented feature then I could add a special case to my tool to
take also the addresses listed in the INA flag.

Good luck getting ALL nodes to do anything. Why only zone 1? It
should apply to all FTN networks and zones.

I agree that we should have one standard for all nodes. But we have two now and

have to figure how to merge them into one.

The frustating thing is that it's hard for software developers to
know about undocumented features.

Proper testing should uncover current practice. When you wrote your tool, did you check it against BinkD.Txt (with diff, FC, or a similar tool) to see if it was generating the same data file? How many
NodeLists did you compare?

I did comparisons with the output of other tools. The funny thing was that my tool extracted more binkp nodes. There are nodes with addresses hidden in the system name or telephone number, the DO4 user flag and more. Besides checking the FTSC docs I had to figure out what else is hidden in the nodelist.

Please tell the FTSC about such stuff, so we are able to
document that.

Ummm... I think I just did. With EchoMail to the FTSC chair in a
public echo conference. It even got the attention of an FTSC member (you). The ball is in your court.

First we have to get all the details of the undocumented standard. How are port

numbers handled? If we take Carol's nodelist entry as example and assume she runs binkd on port 8080 we would have:

INA:shenks.synchro.net,IBN:shenks.dyndns.org:8080

Does the port 8080 also apply to shenks.synchro.net? Or is the standard binkp port assumed for shenks.synchro.net?

FYI, I agree that using two IBN records, as documented in FTS-5001,
would have been a LOT cleaner than one INA and one IBN, but one of
each DOES work. To quote a past FTSC chair, "If you do it this way,
it will work".

Contradicting standards aren't very helpful.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

06 Dec 18 19:44, Markus Reschke wrote to Fred Riccio:

I did comparisons with the output of other tools. The funny thing was that my tool extracted more binkp nodes. There are nodes with
addresses hidden in the system name or telephone number, the DO4 user flag and more. Besides checking the FTSC docs I had to figure out
what else is hidden in the nodelist.

It sounds like you have a problem. If you are looking for BinkP nodes, you should ONLY be checking for an IBN flag (with or without a host name). The addresses "hidden" in other places could be for some other protocol.

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Hello Fred,

On Thursday December 06 2018 10:58, you wrote to me:

MvdV>> So, a properly configured binkp mailer will see that the IBN
MvdV>> flag carries a server address. It will use that and nothing
MvdV>> alse to connect. A binkp mailer will NOT look at the INA flag
[..]

Jerry Schwartz's Perl script is probably the most popular extraction
tool used to generate this file. Up until July of this year a file created by this script was hatched into the I-BinkD file echo.

My guess is that the binkp.net method is the most popular method to let binkd make use of the connect info in the nodelist. IIRC there is also a German program to male a binkp.txt.

Carol's entry in that extraction of NodeList.224 is...

Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -

which is causes BinkD to try the dyndns.org host first, if it doesn't resolve it tries the synchro.net address.

Then obviously the combination of Jerry's script and binkd does not qualify as a properly configured FTSC complient software.

The data attached to the INA flag in this example is NOT dead wood.
It is usable if you use the software I have mentioned above.

One can always create cheats that will make non complient stuff work. Such cheats are detrimental to the smooth operation of the network.

One can make a car that turns left when the steering wheel is turned right. Someone who has never drive a car before can easely be trained to drive it. However having two conflicting standards for steering a car is detrimental to road safety.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello Markus,

On Thursday December 06 2018 18:05, you wrote to Fred Riccio:

This is what I've meant with the confusion about which "standard"
applies. Apparently Jerry's converter follows the undocumented feature Carol mentioned. So it would extract additional addresses which aren't intended for binkp for a node entry following the FTSC docs (if listed take just the address in the IBN flag). How do we resolve this
dilemma?

We should not even try. Adding exceptions every time some idiot creates a deviation from the established standard is undoable. Yes, in theory one could create a flag to signal which interpretation of the INA flag is tio be used, Schwartz or FTS-5001. But than we'd have to agree on the flag. And then what if someone uses the same flag with exactly the oppostie meaning. Well, we could

create another flag to signal which interpreation of the flag that signals which interpreation of the INA flag is to be used. Etc, etc...

If all entries for Z1 nodes follow the undocumented feature
then I could add a special case to my tool to take also the addresses listed in the INA flag. And Jerry would have to do the same, just the other way around.

This is an unworkable situation. Once a standard is established, all shoukld follow it and one should not create new interpretations that conflict with the existing standard.

The frustating thing is that it's hard for sortware developers to know about undocumented features.

It is not just hard, it is impossible to keep up with all the exceptions and upgrade the software if there is no limit imposed on it.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello Fred,

On Thursday December 06 2018 13:06, you wrote to Markus Reschke:

The standard is whatever "current practice" is.

The FTSC documents "current practise". But once it is documented as a standard,

one should not change it every time some idiot says something else that conflicts with existing practise.

How do we resolve this dilemma?

FTSC needs to document current practice.

That is impossible if current practise keeps changing because people refuse to follow documented practise.

FYI, I agree that using two IBN records, as documented in FTS-5001,
would have been a LOT cleaner than one INA and one IBN, but one of
each DOES work.

The Schwartz way does not work.

.....300,INA:fido.vlist.net,IBN:fido.vlist.eu,ITN,IVM

With the Schwartz interpretation, how does one signal, that fido.vlist.eu is to

be used for ITN and IVM and fido.vlist.eu for IBN but fido.vlist.net is NOT to be used for IBN?

To quote a past FTSC chair, "If you do it this way, it will work".

But if one does NOT do it this way and makes something else, it may not work. Having two conflicting interpretations of the same flag does not work.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello Markus,

On Thursday December 06 2018 19:44, you wrote to Fred Riccio:

How do we resolve this dilemma?

FTSC needs to document current practice.

Which one? ;) Now we have two, partly contradicting.

[..0

Contradicting standards aren't very helpful.

Having conflicting standards creates an unstable network. The only way out is to make a choice. The FTSC has made that choice on 2017-08-13 with the publishing of FTS-5001.006


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello Fred,

On Thursday December 06 2018 13:06, you wrote to Markus Reschke:

Jerry is no longer in FidoNet, but the source code is redily
available. I've made several bug fixes to it for my own use.

So fix that other bug, so that it complies with FTS-5001.


Cheers, Michiel


--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hi Fred!

Dec 06 15:13 2018, Fred Riccio wrote to Markus Reschke:

I did comparisons with the output of other tools. The funny thing was
that my tool extracted more binkp nodes. There are nodes with
addresses hidden in the system name or telephone number, the DO4 user
flag and more. Besides checking the FTSC docs I had to figure out
what else is hidden in the nodelist.

It sounds like you have a problem. If you are looking for BinkP
nodes, you should ONLY be checking for an IBN flag (with or without a host name). The addresses "hidden" in other places could be for some other protocol.

... or for binkp. ;) We have several entries in the nodelist which aren't following standards. Some nodes forgot to update their entries when new flags, like IBN, were added. Or they apply their own undocumented standards. When writing a conversion tool for binkp you have to find all the oddities besides what's in the FTSC docs. Or you cling on the FTSC standards and miss some nodes.

The idea of standards is to agree on a common set of rules, a specific syntax and what have you to build compatible systems. If people add new things without

consulting the standards comitee they might break the compatibility with other systems. Unfortunately this happens all the time because someone thinks he has the best idea since sliced bread, and the other parties have to find workarounds or other solutions to keep their systems somewhat compatible. It gives you a nice headache every time.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Hi Michiel!

Dec 06 21:01 2018, Michiel van der Vlist wrote to Fred Riccio:

MvdV> My guess is that the binkp.net method is the most popular method to
MvdV> let binkd make use of the connect info in the nodelist. IIRC there
MvdV> is also a German program to male a binkp.txt.

Two or three. nl2binkd is my attempt. ;)

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Hi Michiel!

Dec 06 21:10 2018, Michiel van der Vlist wrote to Markus Reschke:

MvdV> This is an unworkable situation. Once a standard is established,
MvdV> all shoukld follow it and one should not create new interpretations
MvdV> that conflict with the existing standard.

We like to suffer from our human ego. It would work if would be Vulcans. :)

The frustating thing is that it's hard for sortware developers to
know about undocumented features.

MvdV> It is not just hard, it is impossible to keep up with all the
MvdV> exceptions and upgrade the software if there is no limit imposed on
MvdV> it.

Exactly! It's a never ending story.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Hello Michiel!

06 Dec 18 21:01, Michiel van der Vlist wrote to Fred Riccio:

MvdV> My guess is that the binkp.net method is the most popular method to
MvdV> let binkd make use of the connect info in the nodelist. IIRC there
MvdV> is also a German program to male a binkp.txt.

I briefly checked what is in the binkp.net DNS. I don't think it supports multi-homed systems at all. My system is multi-homed using example #1 from FTS-5001. Binkp.net shows only one of the two addresses. I had expected to see two CN records with 2 different host names.

I'll do some more digging tomorrow, but based on what I found today, I consider

binkp.net to be NOT following the standard, unless you can point out a nodelist

entry where BOTH host names show up in binkp.net

As far as the german program goes, where can I find it? Does it run under windows? I'm not even going to try setting it up unless it has english docs. Maybe someone else could do that.

Carol's entry in that extraction of NodeList.224 is...

Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -

which is causes BinkD to try the dyndns.org host first, if it doesn't
resolve it tries the synchro.net address.

MvdV> Then obviously the combination of Jerry's script and binkd does not
MvdV> qualify as a properly configured FTSC complient software.


YOUR opinion DOES NOT define current practice. The software in use does.

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Re: Candidates vision request
By: Markus Reschke to Carol Shenkenberger on Wed Dec 05 2018 09:10 pm

300,XX,CM,INA:shenks.synchro.net,IBN:shenks.dyndns.org

Can you tell us according to what part(s) of which FTSC standard(s)
this nodelist entry contains information that is never used by a
properly configured mailer?

What standards do you show to represent when a site has 2 resolving
addresses, one preferred for IBN but the other for everything? Z1
practical resolution, yet another thing not documented. The world
is not black and white.

Putting on my software developer hat, I'm quite unhappy with such undocumented features. I've written a small tool to extract the binkp nodes from the nodelist. The FTSC documentation states that the IBN flag should carry a FQDN/IP when binkd is accepting calls only on that FQDN/IP and it's different from the FQDN/IP in the INA flag. Or in other words, the FQDN/IP in the IBN flag prevails and no other address should be called by binkd. In your case the tool would take just shenks.dyndns.org as explained above. But with the undocumented feature I would have to add a special case which also takes shenks.synchro.net as second address. The big problem is that I can't know which nodelist entry follows the FTSC docs and which one follows the undocumented feature. To resolve this delemma we would need a new flag indicating which method applies (standard or undocumented feature). Or we could simply follow the FTSC documented standard. These are things we have to take into account when creating zone specific special features. They can lead to unexpected results. In this case no nodelist-to-binkd converter is able to extract the correct addresses because there is no way to figure out which "standard" was used for a specific node.

Yes Markus, we live in an imperfect world. I want to help refine how a dual adress is listed. To not list the secondary (when outage of the primary) is a problem.

Like 'MOB' we have an undocumented difference.

xxcarol

--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

On 06 Dec 18 21:10:45, Michiel Van Der Vlist said the following to Markus Res

The frustating thing is that it's hard for sortware developers to know about undocumented features.

It is not just hard, it is impossible to keep up with all the exceptions an upgrade the software if there is no limit imposed on it.

Well now, hopefully you can see things from my perspective.

You are quick to quote the missing REPLY (which I explained logically) and the CHRS and PID kludges. You sure do love posting about IPV6, so I assume from an emotional perspective that the topic "means something" to you.

So lets try it from this angle.

If I am not made aware that I am in violation of some standard, because my software does not have the CHRS or PID kludge, because it has not been made open-source or the Fido portion maintained for decades... really am I to blame for that? Am I deserving of flames, attacks from URL-happy Russian Sysops?

Let me rephrase - a Sysop who ran a popular BBS in 1993-1995 who decides to restore from backup his working system, gets on Fido, then discovers his software is in violation of some missing kludge, gets flamed, etc, by others, do you think thats fair for someone participating in a hobby they once loved dearly?

What should they do? Be forced to dump it, screw it, fuck it, go with Mystic or Synchronet? "Can't drive the Ford model-T on a modern road" to badly paraphrase what you said to me before?

What do I tell Toronto-area Sysops who ask me about their Apple and Commodore BBS's they want to fire up again? Sorry you can't, because your system does not adhear to some (IMO) foolish/lazy/ignorant MSGID/REPLY kludge?

I thought that kind of snobbery/arrogance was what you get with the Internet?

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Re: Candidates vision request
By: Michiel van der Vlist to Carol Shenkenberger on Thu Dec 06 2018 12:38 am

So, a properly configured binkp mailer will see that the IBN flag carries a server address. It will use that and nothing alse to connect. A binkp mailer will NOT look at the INA flag since that is to be used for any other protocol who's flag has no server address of its own. But there are no other IP protocol flags. So no mailer will ever use the server address from the INA flag. The INA flag is dead wood. It is "unreachable code".

I suspect you missed that both work for that here.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: Michiel van der Vlist to Carol Shenkenberger on Thu Dec 06 2018 01:00 am

If elected, Will you lead by example and upgrade your system so
that your binkp server is connectable via IPv6?

Ths is not an available service in my area unless going commercial
connectivity at *significant* cost. Initial foray locally showed
close to 1,000$ a month but I can see that is breaking free in some
areas here (USA/Canada). The time is not yet here but we have
pockets of it. For now, no, I do not have that much money a month
to go commercial.

I take that as a "no".

I do not thnk ANYONE here is going to spend the costs for commercial links of te local area. It will come, but is not here yet.

Question:

Are you aware that to help out those that can not get native IPv6 from there own ISP, there are providers that offer a so called "tunnel service" for free? Can you name one of hem?

Yes several. They are posted in the Fidonews. I can not get native IPV6 here yet at a reasonable cost and that is true of much of Z1. There it no gain in a tunnel of IPV6 to an IPV4 setup.

What I hope is the next FTSC chair thinks to ask about such availabilty before assuming 'just tunnel it' works.

Do we even have IPV6 in Z4? I do not know what they have access to it at all. Eventually we all will, but it will take time.

xxcarol


--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: Michiel van der Vlist to Carol Shenkenberger on Thu Dec 06 2018 10:18 am

Did you bother to notify the Z4C? They changed too since you came
in.

ZC4, both the present one and his predecessor have been asked by netmail if they were interested in an invitation. Not once, but several times over the years. There never was a response. Apparently they were not interested.

And yet you apparently missed Ward (per his report) and Nick Andre? Since Z3C was already linked, you rack up as 0 for 2 ZC's. Z4C is an ok miss if you actually tried.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: Michiel van der Vlist to Carol Shenkenberger on Thu Dec 06 2018 10:23 am

Anyway, I did not ask how you think I should have handled it. I am not a candidate. You are, so I am asking you how YOU would handle it.

I would have taken that offline and worked it out.

How would you do that? "take it offline"? It takes two to tango. How do

I take it to netmail and am efficent at working with people.

Now can we stop the bear baiting you are doing on me? I assure you, everyone sees it. Perhaps some of them besides Rob Swindel will chime in too.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: Michiel van der Vlist to Markus Reschke on Thu Dec 06 2018 03:35 pm

Hello Markus,

On Wednesday December 05 2018 21:10, you wrote to Carol Shenkenberger:

The big problem is that I can't know which nodelist entry follows

One of the reasons for having standards is to ensure that software behaves in a predictable and reliable way. We should not have this discussion at all.

So, you missed we did not have a standard that matched all zones? MOB is the same as it doesn't match.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Hello Carol,

On Thursday December 06 2018 20:43, you wrote to me:

I do not think ANYONE here is going to spend the costs for commercial links of te local area.

No one asked you to do that.

Question:

Are you aware that to help out those that can not get native IPv6
from there own ISP, there are providers that offer a so called
"tunnel service" for free? Can you name one of hem?

Yes several. They are posted in the Fidonews. I can not get native
IPV6 here yet at a reasonable cost and that is true of much of Z1.

It is true for most of the world, not just Z1. But that was not my question.

There it no gain in a tunnel of IPV6 to an IPV4 setup.

Eh?

What I hope is the next FTSC chair thinks to ask about such
availabilty before assuming 'just tunnel it' works.

"Just tunnel it" DOES work. That is not an assumption that is researched knowledge. Tunnels are available for everyone on earth with an internet connection with a public IPv4 address. It DOES work. For free. For you too.

What I hope is the next FTSC chair thinks to ask about what a tunnel actually is before rejecting the idea out of hand.

Do we even have IPV6 in Z4?

Irrelevant for the question at hand. But yes. See the list of IPv6 nodes in Fidonews.

Anyway... I conclude that the answer to my question ....

If elected, Will you lead by example and upgrade your system so
that your binkp server is connectable via IPv6?

.... is "no", I will not lead by example.

Thanks for answering.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

06 Dec 18 18:05, Markus Reschke wrote to Fred Riccio:

Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -

This is what I've meant with the confusion about which "standard" applies. Apparently Jerry's converter follows the undocumented
feature Carol mentioned. So it would extract additional addresses
which aren't intended for binkp for a node entry following the FTSC
docs (if listed take just the address in the IBN flag). How do we
resolve this dilemma?

It seems that we have at least two methods that are used to deal with multi-homed systems, both methods are currently used and very popular.

Jerry's script processes one INA and one IBN record (both with addresses) as multi-homed. Binkp.net seems to ignore the fact that multi-homed systems even exist, it returns only one address for all combinations of INA/IBN. We haven't

been told what Markus' and Uli's tools do, so there may be two other methods. FTS-5001 does not document either one of these methods.

How will you clean this up? Be specific. "Change FTS-5001" isn't a good answer. Tell us WHAT you will change and what you will change it to. Keep in mind that FTSC standards document "current practice".

Answer quickly... There are only 2 days left in the voting period.

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Hello Fred,

On Thursday December 06 2018 17:16, you wrote to me:

MvdV>> My guess is that the binkp.net method is the most popular method to
MvdV>> let binkd make use of the connect info in the nodelist. IIRC there
MvdV>> is also a German program to male a binkp.txt.

I briefly checked what is in the binkp.net DNS. I don't think it
supports multi-homed systems at all.

So it would seem...

My system is multi-homed using example #1 from FTS-5001.

[nitpicking mode on]

Strictly speaking your system is not multi homed. Both host names point to the same IP address. It is multi DNS.

The two hostenames listed for my system return different IP numbers.

[nitpickkihg mode off]

Binkp.net shows only one of the two addresses. I had expected to see
two CN records with 2 different host names.

Things do not always work as expected.

I'll do some more digging tomorrow, but based on what I found today, I consider binkp.net to be NOT following the standard,

Binkp.net extracts a valid address from the nodelist that can be used by binkd to make a connection.

The standard documents a way to list multiple host names. It does not say that applications MUST use this feature and try them all. I see no conflict with the

standard.

As far as the german program goes, where can I find it? Does it run
under windows?

Ask Markus.

Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Fred,

How will you clean this up? Be specific. "Change FTS-5001" isn't a good answer. Tell us WHAT you will change and what you will change it to.
Keep in mind that FTSC standards document "current practice".

Hoping to beat someone else by saying this, but is that part of the job-description for an FTSC-administrator ?

\%/@rd

--- D'Bridge 3.99 SR33
* Origin: When there's an elephant in the room, introduce him (2:292/854)

07 Dec 18 18:36, Ward Dossche wrote to Fred Riccio:

How will you clean this up? Be specific. "Change FTS-5001" isn't a
good answer. Tell us WHAT you will change and what you will change it
to. Keep in mind that FTSC standards document "current practice".

Hoping to beat someone else by saying this, but is that part of the job-description for an FTSC-administrator ?

Not written in the FTA, but it is what has been done in practice.

During my tenure as a FTSC member, the administrator controlled the work flow, deciding which standard or proposal would be tackled next. Some valid proposals were simply ignored, while other ideas (proposed by the chair) were put on top of the list. The Chair also edited and hatched the documents, giving him the final word in regards to the content of the work. Even proposed

changes like spelling and punctuation were ignored if they were not agreeable to the administrator. I hope to draw out a sense of willingness of the candidates to listen to other people's ideas and not be a dictator.

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Hello Fred,

On Thursday December 06 2018 17:16, you wrote to me:

MvdV>> Then obviously the combination of Jerry's script and binkd does
MvdV>> not qualify as a properly configured FTSC complient software.

FTSC complient as documented by the FTSC in FTS-5001.

YOUR opinion DOES NOT define current practice. The software in use
does.

So you say, but that is just YOUR opinion.

Documenting current practise and calling it a standard is fine as long as current practise is unambiguous and consistent.

Unfortunately there is not one single current practice. There are softwares around that do things in conflicting ways. Documenting all of it as a standard is unworkable. Making standards is making choices between incompatible alternatives.

Demanding that the FTSC documents all current parctises as standards is asking for a mission impossible.


Cheers, Michiel

--- Fmail, Binkd, Golded
* Origin: http://www.vlist.org (2:280/5555)

Hallo Michiel!

07.12.2018 20:28, Michiel van der Vlist schrieb an Fred Riccio:

Unfortunately there is not one single current practice. There are softwares around that do things in conflicting ways. Documenting all
of it as a standard is unworkable. Making standards is making choices between incompatible alternatives.

Well, all ibn flag specific stuff is in some way documentable.
But the document won't be understandable, because there are some very special entrys inside the nodelist. All the exeptions make it hard to figure out a proper ibn entry for a binkp compatible list.

Currently my nodelist-tool uses 23 select to figure out a simple ibn flag.

Demanding that the FTSC documents all current parctises as standards
is asking for a mission impossible.

To do it human understandable, yes.

Cheers, Michiel

Bye/2 Torsten

... MAILBOX01 on OS2: up 0d 23h 03m load: 37 proc, 151 threads (tbupv1.1)
--- GoldED+ 1.1.5-18
* Origin: DatenBahn BBS Hamburg (2:240/5832)

Re: Candidates vision request
By: Michiel van der Vlist to Carol Shenkenberger on Fri Dec 07 2018 10:13 am

Anyway... I conclude that the answer to my question ....

If elected, Will you lead by example and upgrade your system so
that your binkp server is connectable via IPv6?

.... is "no", I will not lead by example.

The answer is no for now, I will as soon as it becomes largely available for a reasonable price. The same as everyone else here I assume.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

The answer is no for now, I will as soon as it becomes largely available for a reasonable price. The same as everyone else here I assume.

I'm discovering I may have IPv6 in Belgium without paying extra.

Maybe come to live here, there are 3 American bases here...

\%/@rd

--- D'Bridge 3.99 SR33
* Origin: When there's an elephant in the room, introduce him (2:292/854)

Hallo Ward!

08.12.2018 00:08, Ward Dossche schrieb an Carol Shenkenberger:

I'm discovering I may have IPv6 in Belgium without paying extra.

German telekom offers a full ipv6 stack without any cost.
Also vodafone germany and vodafone cable offer a full featured ipv6 stack.
As far as I know, Spain Telefonica and France Telekom also ported their system to IPv6 without any cost. AFAIK, if you want a ipv4 address, you have to pay a extra fee with spain telekom.

An IPv4 stack is a dieing stack in central europe. ;-)

Maybe come to live here, there are 3 American bases here...

Sure? Localized to belgium or europe? ;-)

Scr, but there are 56 us bases in europe.

In germany there are:

=##= Anfang "usbases.txt" =##=

8.1 Baden-Württemberg
8.1.1 Böblingen
8.1.2 Mannheim
8.1.3 Müllheim (Baden)
8.1.4 Stuttgart / Leinfelden-Echterdingen
8.2 Bayern
8.2.1 Ansbach-Katterbach
8.2.2 Garmisch-Partenkirchen
8.2.3 Grafenwöhr
8.2.4 Hohenfels
8.2.5 Illesheim
8.2.6 Oberammergau
8.2.7 Vilseck
8.3 Hessen
8.3.1 Wiesbaden
8.3.2 Griesheim
8.4 Nordrhein-Westfalen
8.4.1 Bielefeld
8.4.2 Dülmen
8.4.3 Geilenkirchen
8.4.4 Gütersloh
8.4.5 Minden
8.4.6 Mönchengladbach
8.4.7 Münster
8.4.8 Paderborn
8.4.9 Uedem
8.4.10 Wulfen
8.5 Rheinland-Pfalz
8.5.1 Baumholder
8.5.2 Germersheim
8.5.3 Kaiserslautern
8.5.4 Landstuhl
8.5.5 Miesau
8.5.6 Pirmasens
8.5.7 Ramstein
8.5.8 Spangdahlem
8.5.9 Wackernheim
8.5.10 Mainz

=##= Ende "usbases.txt" =##=

I guess, we are lucky to got some more us-bases in europe than three. Also some
canadian, australian, british, brasilian, argentinian fellows.
We got also a us/british/french/german fast reaction force.
Just for information.

Because of this all bases, carol got plenty of choices to move abroad. ;-)


Anyway, this stuff is offtopic, and I stuck my nose again inside some fidonet source code and shut my mouth.

\%/@rd

Bye/2 Torsten

... MAILBOX01 on OS2: up 0d 23h 03m load: 37 proc, 151 threads (tbupv1.1)
--- GoldED+ 1.1.5-18
* Origin: DatenBahn BBS Hamburg (2:240/5832)

Re: Re: Candidates vision request
By: Ward Dossche to Carol Shenkenberger on Sat Dec 08 2018 12:08 am

The answer is no for now, I will as soon as it becomes largely
available for a reasonable price. The same as everyone else here I
assume.

I'm discovering I may have IPv6 in Belgium without paying extra.

Cool! I think the same will happen here but not just yet. I've been looking over information on it for the last 2 months and what software changes I might need to make. Same as I have been looking at VM setups so as to free the Battlenet league off XP.

Sametime, I have been working up a list of softwares that Thom Lacosta might find fits his needs (as of yesterday) and fit his 'simple level desire'.

Maybe come to live here, there are 3 American bases here...

Smile, my moving days are over but I have always wanted to go to Europe. It's the continent I never got to in my 26 years (outside Antartica have at least been on a plane that landed for a few hours in the others).

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Hello Fred,

On Friday December 07 2018 12:55, you wrote to Ward Dossche:

Keep in mind that FTSC standards document "current practice".

[..]

I hope to draw out a sense of willingness of the candidates to listen
to other people's ideas and not be a dictator.

Normally I would say "you are entitled to your opinion".

However... ATM you are not just a sysop expressing an opinion, you are the election coordinator in an ongoing election. Your job is to count the votes. You are supposed to be independent and do your job without prejudice or bias towards those that depend on you managing a fair and honest election. You are in a position of trust.

How can I trust you now that you have openly expressed an opinion on how the next FTSC admnistrator should do his/her job and what was wrong with the previous one?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

08 Dec 18 12:16, Michiel van der Vlist wrote to Fred Riccio:


MvdV> However... ATM you are not just a sysop expressing an opinion, you
MvdV> are the election coordinator in an ongoing election.

<nit-pick>

I am the Independant Enumerator.

Coordinating all membership nominations and voting is the responsibility
of the Administrator (FTA-1001 and election rules). There is currently
no Administrator.

</nit-pick>



Mvdv> Your job is to
MvdV> count the votes. You are supposed to be independent and do your job
MvdV> without prejudice or bias towards those that depend on you managing
MvdV> a fair and honest election. You are in a position of trust.

My opinions have no bearing on my ability to count votes. I will count them accurately and save enough documentation to prove it if it comes to that.


MvdV> How can I trust you now that you have openly expressed an opinion
MvdV> on how the next FTSC admnistrator should do his/her job and what
MvdV> was wrong with the previous one?

Regardless of my opinions I can stiil count.

End of topic. The time period for contesting the results is 10 December 2018 through 16 December 2018 at 20:00 UTC

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Re: What would YOU do?
By: Fred Riccio to The Candidates on Fri Dec 07 2018 10:05 am

Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -

This is what I've meant with the confusion about which "standard"
applies. Apparently Jerry's converter follows the undocumented
feature Carol mentioned. So it would extract additional addresses
which aren't intended for binkp for a node entry following the FTSC
docs (if listed take just the address in the IBN flag). How do we
resolve this dilemma?

It seems that we have at least two methods that are used to deal with multi-homed systems, both methods are currently used and very popular.

Jerry's script processes one INA and one IBN record (both with addresses) as multi-homed. Binkp.net seems to ignore the fact that multi-homed systems even exist, it returns only one address for all combinations of INA/IBN. We haven't been told what Markus' and Uli's tools do, so there may be two other methods. FTS-5001 does not document either one of these methods.

How will you clean this up? Be specific. "Change FTS-5001" isn't a good answer. Tell us WHAT you will change and what you will change it to. Keep in mind that FTSC standards document "current practice".

This may be a case of a proposal to standardize it. If we have at least one functional tool that uses the dual listing, that can be a base for an actual FTS instead of a FSP.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Re: What would YOU do?
By: Fred Riccio to Ward Dossche on Fri Dec 07 2018 12:55 pm

Hoping to beat someone else by saying this, but is that part of the
job-description for an FTSC-administrator ?

Not written in the FTA, but it is what has been done in practice.

During my tenure as a FTSC member, the administrator controlled the work flow, deciding which standard or proposal would be tackled next. Some valid proposals were simply ignored, while other ideas (proposed by the chair) were put on top of the list. The Chair also edited and hatched the documents, giving him the final word in regards to the content of the work. Even proposed changes like spelling and punctuation were ignored if they were not agreeable to the administrator. I hope to draw out a sense of willingness of the candidates to listen to other people's ideas and not be a dictator.

Agreed that has been our history for several years.

I have thought about it and no matter who wins, I want to see us FTSC make a sort of list at what areas we feel best at in documentation them comb them
over with those who are best at it. See what we thinks needs to be fixed the present it back.

When I started as a guest member we had a bunch of FTSC echos. We devolved to one later but we lost something along the way. We might just need some side chatter dedicated to specifics without thr baiting because no one knows it all.

The job of the coodinator is an admin position, not a techicnical one. It is to assist the members with working it all out. Guidance, not mandates.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: Michiel van der Vlist to Fred Riccio on Fri Dec 07 2018 08:28 pm

MvdV>> Then obviously the combination of Jerry's script and binkd does MvdV>> not qualify as a properly configured FTSC complient software.

FTSC complient as documented by the FTSC in FTS-5001.

YOUR opinion DOES NOT define current practice. The software in use
does.

So you say, but that is just YOUR opinion.

The simple addition of the standing ZC's makes this a very simple process. That is why they were added about 2003. If we have a mismatch in how 2 zones do thing, we then work with them.

We are now fixing getting the ZC's in. Z1C is. Z2C is. Z3 is. Z4 is not known.

Next up we work on MOB and dual listings as the zones do not do them the same. We find out why then come up with a mutual pattern. Its not rocket science.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: What would YOU do?
By: Michiel van der Vlist to Fred Riccio on Sat Dec 08 2018 12:16 pm

Keep in mind that FTSC standards document "current practice".

[..]

I hope to draw out a sense of willingness of the candidates to
listen to other people's ideas and not be a dictator.

Normally I would say "you are entitled to your opinion".

However... ATM you are not just a sysop expressing an opinion, you are the
election coordinator in an ongoing election. Your job is to count the votes. You are supposed to be independent and do your job without prejudice or bias towards those that depend on you managing a fair and honest election. You are in a position of trust.

Well, moved the bear baiting off me but now on innocent Fred eh?

What I want for the FTSC, no matter WHO wins, is an end to that attack. It started when you were elected and I am not the only one tired of it. Not one of the 3 running supported how you dealt with Ward. We all agreed it was something the FTSC members should have discussed before you rendered him 'read only'. Note that was fixed post-haste.

In your black and white world, I think you missed guest users and someplace, we didn't document all standing ZC's are guest members. You WERE told though in the echo.

For me, happy to work well with whoever wins.

xcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Hi Carol!

Dec 08 18:07 2018, Carol Shenkenberger wrote to Fred Riccio:

How will you clean this up? Be specific. "Change FTS-5001" isn't a
good answer. Tell us WHAT you will change and what you will change it
to. Keep in mind that FTSC standards document "current practice".

This may be a case of a proposal to standardize it. If we have at
least one functional tool that uses the dual listing, that can be a
base for an actual FTS instead of a FSP.

Wouldn't we get two FTS docs contradicting each other then???

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Hi Fred!

06 Dec 2018 17:16, from Fred Riccio -> Michiel van der Vlist:

As far as the german program goes, where can I find it?

It is written by our fellow FTSC member Markus Reschke.
You can frequ it from him, or search the web for nl2binkd

Does it run under windows?

It is a bash script.
I assume somebody compiled bash for windows ... or it may be part of the new posix windows layer thingy.

CU, Ricsi

... A WHISPER - The fastest method of circulating a secret yet devised!
--- GoldED+/LNX
* Origin: I won't use Windows, I won't use Windows, I won't... (2:310/31)

Hello Carol,

On Saturday December 08 2018 19:06, you wrote to me:

I hope to draw out a sense of willingness of the candidates to
listen to other people's ideas and not be a dictator.

Well, moved the bear baiting off me but now on innocent Fred eh?

Innocent? So the use of the word "dictator" is OK with you?

For me, happy to work well with whoever wins.

As long as it isn't me. I see...


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Re: What would YOU do?
By: Markus Reschke to Carol Shenkenberger on Sun Dec 09 2018 09:22 am

Hi Carol!

Dec 08 18:07 2018, Carol Shenkenberger wrote to Fred Riccio:

How will you clean this up? Be specific. "Change FTS-5001" isn't a
good answer. Tell us WHAT you will change and what you will change
it to. Keep in mind that FTSC standards document "current
practice".

This may be a case of a proposal to standardize it. If we have at
least one functional tool that uses the dual listing, that can be a
base for an actual FTS instead of a FSP.

Wouldn't we get two FTS docs contradicting each other then???

Not if we align them. Take what is in existing use, see what the differences are, then what tools already use them and see what works.

This isn't a really common thing to see (a site with 2 lookup addresses). I'd say most of us with 2 have a reason for it. Mine is backup connectivity for the most part. I've had one or the other go off for a bit and with the game league (Battlenet) that can get nasty fast.

Either way, I've been dual listed for probabaly 6 years now? I've had the synchro.net address since 2007 (though it probably dropped out when I was moving back stateside) and I picked up the DYNDNS address around 2010 or so, listed it later. Folks who connect to the game league here give me conflicting reports on which seems to work better with a very nominal edge towards Synchro is in north america and a reverse for overseas. The pool though is too small to show anything real there. Folks in my league just know if one 'seems out' to 'try the other'. Unless my actual local gear is powered down or without ISP access, it's very rare to have a problem and if so, never both at once.

Justanet (Gert?) may be able to explain how rapid fire BRE nets can get. 2,000 packets a day is not uncommon here. Things backlog fast if there is 'blip'.

7 games with 25 sites sending a nominal 1 packet per game per hour is 4,200 packets inbound. Those are then replicated outbound to 24 sites.... It's not actually that much (fewer nodes now for one) and they are all small packets, but it adds up to a traffic jam inbound here.

xxcarol

--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: What would YOU do?
By: Michiel van der Vlist to Carol Shenkenberger on Sun Dec 09 2018 10:32 am

Innocent? So the use of the word "dictator" is OK with you?

I think you need to take that back to Fred. As to claims of 'dictator', from what I gather you started that when you called Ward one related to some african nation.

For me, happy to work well with whoever wins.

As long as it isn't me. I see...

You are not running. I however have tried hard to work with you for more than a decade. I assume that will continue.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

On 2018 Dec 04 21:46:24, you wrote to Michiel van der Vlist:

,100,Shenks_Express,Virginia_Beach_VA,Carol_Shenkenberger,-Unpublishe
d-,300,XX,CM,INA:shenks.synchro.net,IBN:shenks.dyndns.org

Can you tell us according to what part(s) of which FTSC standard(s)
this nodelist entry contains information that is never used by a
properly configured mailer?

What standards do you show to represent when a site has 2 resolving addresses, one preferred for IBN but the other for everything? Z1 practical resolution, yet another thing not documented.

this multiple domain resolution thing is built into some mailers... it is not available for others... those mailers that can see and use multiple domains will cycle through them trying each one in succession until a connection is made or a number-of-tries counter has been reached... this works also with a domain name in the "system name" field if one were to use that field for a domain name instead of a system name... one could also use additional IBN flags

to indicate more than the possible three domains when using the available fields where a domain name is able to be listed...

the following would be a valid entry for a system with five domains available for connection...

,100,domain1.invalid,Virginia_Beach_VA,Carol_Shenkenberger,-Unpublished-,300,XX,CM,INA:domain2.invalid,IBN:domain3.invalid,IBN:domain4.invalid,IBN:domain5.invalid

The world is not black and white.

very true...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Can Harrison Ford the river?
---
* Origin: (1:3634/12.73)

On 2018 Dec 05 21:10:56, you wrote to Carol Shenkenberger:

What standards do you show to represent when a site has 2 resolving
addresses, one preferred for IBN but the other for everything? Z1
practical resolution, yet another thing not documented. The world is
not black and white.

Putting on my software developer hat, I'm quite unhappy with such undocumented features.

what undocumented features? IIRC, binkd was the first to offer this capability... you can easily list multiple semicolon separated domains in the NODE lines...

I've written a small tool to extract the binkp nodes from the
nodelist. The FTSC documentation states that the IBN flag should carry
a FQDN/IP when binkd is accepting calls only on that FQDN/IP and it's different from the FQDN/IP in the INA flag. Or in other words, the
FQDN/IP in the IBN flag prevails and no other address should be called
by binkd.

that's now how binkd works... it cycles through the presented domains...

In your case the tool would take just shenks.dyndns.org as explained above. But with the undocumented feature I would have to add a special case which also takes shenks.synchro.net as second address.

binkd (and argus/radius/taurus) nodelist tools do this without any problem... i

remember when Jerry Schwartz was writing the binkd_nodelister.pl script and how

he asked questions of the FTSC about this very thing with multiple domains in a

nodelist line... it was decided at that time to list all the domains found in the specified fields and write them in a semicolon separated list to the binkd configuration file like binkd worked with... other nodelist convertors would list the multiple domains in a manner consistent with the mailer(s) they support... if the mailer doesn't have support for multiple domains, then the convertor tool would choose the proper one for that mailer...

The big problem is that I can't know which nodelist entry follows the
FTSC docs and which one follows the undocumented feature. To resolve
this delemma we would need a new flag indicating which method applies (standard or undocumented feature). Or we could simply follow the FTSC documented standard.

this additional flag thing is overengineering... it isn't needed... mailers use

the available domains listed in the specified nodelist fields... they've done this for a long time... i tested argus/radius/taurus with multiple domains and also POTS and they cycled through each domain and the POTS until a connection was made... binkd does the same except that it doesn't do POTS...

These are things we have to take into account when creating zone
specific special features. They can lead to unexpected results. In
this case no nodelist-to-binkd converter is able to extract the
correct addresses because there is no way to figure out which
"standard" was used for a specific node.

really??? these 81 multiple domain entries from BINKD.TXT would seem to disagree with you...

$ egrep -e "^Node .*;" BINKD.TXT
Node 1:103/17@fidonet nix.synchro.net;nix.synchro.net -
Node 1:213/0@fidonet net213.rail-city.net;71.83.99.146 -
Node 1:11/0@fidonet ftn.rocasa.net;198.144.184.12 -
Node 1:11/11@fidonet ftn.rocasa.net;198.144.184.12 -
Node 1:120/0@fidonet ftn.rocasa.net;198.144.184.12 -
Node 1:120/302@fidonet mojo.synchro.net;bbs.mojosworld.net -
Node 1:120/310@fidonet bbs.ghostopera.org;bbs.ghostopera.org -
Node 1:120/544@fidonet ftn.rocasa.net;ftn.rocasa.net;198.144.184.12 -
Node 1:120/546@fidonet bbbs.rocasa.biz;192.210.236.220 -
Node 1:220/40@fidonet daliscat.synchro.net;216.80.116.211 -
Node 1:227/70@fidonet bbs.thehomesteadinghippy.com;199.21.199.227 -
Node 1:2320/200@fidonet Slasho.me_BBS;slasho.me -
Node 1:229/981@fidonet bbs.digitalgatehouse.com;bbs.digitalgatehouse.com

-
Node 1:249/206@fidonet mccarragher.org;mccarragher.org -
Node 1:249/207@fidonet bbs.jonwatson.ca;bbs.jonwatson.ca -
Node 1:109/201@fidonet bbs.cyberchatnet.com;bbs.cyberchatnet.com -
Node 1:109/567@fidonet bbsdoors.com;www.bbsdoors.com -
Node 1:275/96@fidonet GCOMMLIVE.com;gcommlive.dynu.com -
Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -
Node 1:275/201@fidonet bbs.cyberchatnet.com;mystic.dynu.net -
Node 1:132/0@fidonet net132.ddns.net;ullr.thinksnow.net -
Node 1:132/174@fidonet fido132174.duckdns.org;ullr.thinksnow.net -
Node 1:340/201@fidonet fluxcap.dynv6.net;fluxcap.synchro.net -
Node 1:116/28@fidonet magnum.synchro.net;magnum.synchro.net -
Node 1:124/0@fidonet pbmystic.rdfig.net:24555;pbmystic.rdfig.net:24:24555

-
Node 1:124/5014@fidonet pbmystic.rdfig.net:24555;pbmystic.rdfig.net:24:24555

-
Node 1:124/5015@fidonet pbmystic.rdfig.net:24554;pbmystic.rdfig.net:1023:24554

-
Node 1:124/5016@fidonet ipv4.endofthelinebbs.com:24554;ipv4.endofthelinebbs.com:24554 -
Node 2:240/12@fidonet stts.no-ip.org;stts.no-ip.org -
Node 2:240/1120@fidonet AMBROSIA60.dd-dns.de;ambrosia60.goip.de -
Node 2:2437/224@fidonet travelbit.servebeer.com;travelbit.spdns.de -
Node 2:2452/202@fidonet strickeranderl.org;strickeranderl.org -
Node 2:2452/250@fidonet ftn.doene.de;ftn.doene.de -
Node 2:25/0@fidonet applewoodbbs.linkpc.net;81.174.171.9: -
Node 2:250/0@fidonet applewood.linkpc.net;81.174.171.9: -
Node 2:250/1@fidonet applewoodbbs.linkpc.net;81.174.171.9: -
Node 2:250/25@fidonet pavelreich.org;fido.pavelreich.org -
Node 2:263/0@fidonet applewood.linkpc.net;81.174.171.9: -
Node 2:28/0@fidonet fido.vlist.eu;fido4to6.vlist.eu -
Node 2:280/5555@fidonet fido.vlist.eu;fido4to6.vlist.eu -
Node 2:291/0@fidonet fido.tsoh.be;tsoh.fidonode.be: -
Node 2:291/1@fidonet fido.tsoh.be;tsoh.fidonode.be: -
Node 2:301/520@fidonet fido.baboon.ch;fido.baboon.ch -
Node 2:301/812@fidonet fifi.woody.ch;fifi.woody.ch -
Node 2:310/31@fidonet fido.ricsi.priv.at;fido.ricsi.priv.at -
Node 2:40/0@fidonet server.vbd.su;2992.mooo.com: -
Node 2:400/0@fidonet server.vbd.su;2992.mooo.com: -
Node 2:400/2992@fidonet server.vbd.su;2992.mooo.com: -
Node 2:4500/0@fidonet f1.n4500.z2.fidonet.by;f1.n4500.z2.fidonet.by -
Node 2:4500/1@fidonet f1.n4500.z2.fidonet.by;f1.n4500.z2.fidonet.by -
Node 2:460/777@fidonet 188.17.156.216;f777.n460.z2.binkp.net -
Node 2:4614/20@fidonet cservice.ddns.ukrtel.net;cservice.ddns.ukrtel.net

-
Node 2:480/124@fidonet uucp.freebsd.lublin.pl;uucp.freebsd.lublin.pl -
Node 2:480/138@fidonet fido.chmurka.net;fido.chmurka.net -
Node 2:50/72@fidonet s.system.pvt;fido72.shad.su -
Node 2:5000/22@fidonet f22.n5000.z2.binkp.net;f22.n5000.z2.binkp.net -
Node 2:5010/352@fidonet f352.sage.su;f352.sage.su -
Node 2:5020/1906@fidonet binkp.nauchi.ru;binkp.nauchi.ru -
Node 2:5020/11200@fidonet f11200.metal.ru;f11200.metal.ru -
Node 2:5020/4441@fidonet 195.24.225.1;fido.ym-com.net -
Node 2:5020/540@fidonet binkd.piafi.ru;binkd.piafi.ru -
Node 2:5020/921@fidonet fido.nln.ru;fido.nln.ru -
Node 2:5020/1313@fidonet fido.stabilis.ru;fido.stabilis.ru -
Node 2:5020/2142@fidonet fido.axi.ru;fido.axi.ru -
Node 2:5020/1042@fidonet f1042.ru;f1042.ru;fido.delin.ru:;f1042.n5020.z2.binkp.net: -
Node 2:5020/828@fidonet f828.n5020.z2.binkp.net;f828.n5020.z2.binkp.net -
Node 2:5020/2047@fidonet ae-nest.com;ftn.ae-nest.com -
Node 2:5020/2065@fidonet f2065.no-ip.org;f2065.no-ip.org -
Node 2:5030/786@fidonet G.Style_BBS;elvete.com -
Node 2:5030/1900@fidonet D.J._BoaRD;ftn.kawai.spb.ru -
Node 2:5030/1957@fidonet fido.stpeteclub.ru;fido.stpeteclub.ru -
Node 2:5031/77@fidonet G.FREEMAN;188.166.66.123 -
Node 2:5061/7@fidonet f7.n5061.z2.binkp.net;samael.chimfak.rsu.ru -
Node 2:5061/58@fidonet f58.n5061.z2.binkp.net;vpn.rfniias.ru -
Node 2:5080/102@fidonet nodelist.grumbler.org:443;binkd.node.grumbler.org:443;binkp.vashadmin.su:443 -
Node 2:5083/89@fidonet ImPressed.31;vsa1987.no-ip.info -
Node 2:5090/958@fidonet fido.ridi24.ru;f958.n5090.z2.binkp.net: -
Node 2:6035/5@fidonet f5.n6035.z2.binkp.net;f5.n6035.z2.binkp.net -
Node 2:6056/1@fidonet 1.fido6056.int.ru;1.fido6056.int.ru -
Node 3:712/0@fidonet sysgod.org;ftn.sysgod.org -
Node 3:712/848@fidonet sysgod.org;ftn.sysgod.org -


the distributed ARGUS.TXT also has multiple domain entries but that convertor script seems to miss the INA entries... maybe it is protocol oriented so it only works with the domains attached to an IP flag?? if that's the case, it also misses the entries with the domain in the system field (not attached to a flag) as well as those attached to the INA flag... i don't know for sure as i've not used the convertor that scott little uses to create said distributed file... scott would have the answer as to why argus.txt has different output than binkd.txt...

$ egrep -e ",BND.*,BND" argus.txt
1:282/1056|"crystalp.duckdns.org",BND,CM "crystalp.duckdns.org",BND,CM "crystalp.duckdns.org",IFC,CM
1:282/1058|"oldhabitsbbs.com",BND,CM "oldhabitsbbs.com",BND,CM "oldhabitsbbs.com",TEL,CM "oldhabitsbbs.com",IFC,CM 1:15/4|"region15.net",BND,CM "region15.net"_24556,BND,CM "region15.net"_60177,TEL,CM "region15.net",IFC,CM 1:132/0|"net132.ddns.net",BND,CM "ullr.thinksnow.net",BND,CM 1:132/174|"fido132174.duckdns.org",BND,CM "ullr.thinksnow.net",BND,CM 2:28/0|"fido.vlist.eu",BND,CM "fido4to6.vlist.eu",BND,CM 2:280/5555|"fido.vlist.eu",BND,CM "fido4to6.vlist.eu",BND,CM 2:5080/102|"binkd.node.grumbler.org",BND "binkd.node.grumbler.org"_443,BND


)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... In the beginning there was nothing, which exploded.
---
* Origin: (1:3634/12.73)

On 2018 Dec 06 00:38:36, you wrote to Carol Shenkenberger:

From FTS-5001.006:

INA This flag sets a default server address used
for any Internet Protocol Flag that does not
specify its own.

So, a properly configured binkp mailer will see that the IBN flag
carries a server address. It will use that and nothing alse to
connect.

i think you mean a properly programmed binkp mailer...

A binkp mailer will NOT look at the INA flag since that is to be used
for any other protocol who's flag has no server address of its own.

binkd doesn't know anything about nodelist flags... it (mainly) depends on its nodelist... a nodelist that is created by some convertor tool... the most commonly used tool pulls and lists all the domains from the proper fields and flags and lists them in the NODE lines... multiple domains separated by semicolons are no problem for binkd...

But there are no other IP protocol flags. So no mailer will ever use
the server address from the INA flag. The INA flag is dead wood. It is "unreachable code".

sorry but it is not...

What standards do you show to represent when a site has 2 resolving
addresses, one preferred for IBN but the other for everything? Z1
practical resolution, yet another thing not documented.

It /IS/ documented. FTS-5001.006:

Multihomed systems
------------------

Multihomed systems or systems that are otherwise reacheable by more
than one address, may - instead of adding another A or AAAA record
to the DNS zone of the host name - repeat the flag(s) carrying the
address with another address.

Example: IBN:host1.example1.tld,IBN:host2.example2.tld
Or: INA:host1.example1.tld,INA:host2.example2.tld,IBN

well, there ya go... there's nothing wrong with xxcarol's nodelist line...

This was discussed by the FTSC members in the Private FTSC area in 2017. You are an FTSC member, you were there. Apparently you did not pay attention.

or maybe she didn't retain that just like you don't always remember things... or have you also not been paying attention in the past? like maybe back in 2005-2007 when Jerry Schwartz was working on the binkd_nodelister.pl script which is now the standard conversion script from the St.Louis nodelist format to the binkd node list format??

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Buy a rope and shoot yourself where the water is deepest.
---
* Origin: (1:3634/12.73)

On 2018 Dec 06 01:00:44, you wrote to Carol Shenkenberger:

Are you aware that to help out those that can not get native IPv6 from there own ISP, there are providers that offer a so called "tunnel service" for free? Can you name one of hem?

what does this have to do with the FTSC??

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... 3 certainties: Death, taxes & lost data. Guess which has occurred?
---
* Origin: (1:3634/12.73)

On 2018 Dec 06 10:18:50, you wrote to Carol Shenkenberger:

Did you bother to notify the Z4C? They changed too since you came in.

ZC4, both the present one and his predecessor have been asked by
netmail if they were interested in an invitation. Not once, but
several times over the years. There never was a response. Apparently
they were not interested.

or they didn't receive the messages... it is all too easy for netmails to go into a blackhole in todays BSO driven world...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... SKIER: Someone who pays an arm and a leg to break them.
---
* Origin: (1:3634/12.73)

On 2018 Dec 06 10:23:06, you wrote to Carol Shenkenberger:

The question was to "Andrew and all running". You are running,
you are part of "them". So now I am asking you.

Ok, but you should ask them as well, not just me.

You were the one bringing "personal issue" into the discussion. So I am asking you.

it seems to me that you brought that when asking what others would do in that situation... that personal situation is what started this whole election thing anyway...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Never knew my Dad, til I saw him on COPS on TV.
---
* Origin: (1:3634/12.73)

On 2018 Dec 06 15:35:22, you wrote to Markus Reschke:

If the *C is also an FTSC member, ignorance is no excuse. FTSC members should know the standards. If (s)he is a candidate for the chair....

did you ever stop to think that the only reason others ran was to force an election?

I will leave the judgement to the reader...

same here...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Chocolate makes the world go 'round - and me too!
---
* Origin: (1:3634/12.73)

On 2018 Dec 06 18:05:22, you wrote to Fred Riccio:

Jerry Schwartz's Perl script is probably the most popular extraction
tool used to generate this file. Up until July of this year a file
created by this script was hatched into the I-BinkD file echo.

Carol's entry in that extraction of NodeList.224 is...

Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -

This is what I've meant with the confusion about which "standard" applies. Apparently Jerry's converter follows the undocumented feature Carol mentioned.

no, it follows what was discussed 11+ years ago when he was working on it...

So it would extract additional addresses which aren't intended for
binkp for a node entry following the FTSC docs (if listed take just
the address in the IBN flag).

wrong... it extracts the domain from the "system name" field, the INA flag(s) and the IBN flag(s)... the domains listed in the "system name" field and the INA flags are default domains to attempt a connection with... they are valid to

use if the domains attached to any IBN flags fail to connect...

How do we resolve this dilemma?

what delima?

If all entries for Z1 nodes follow the undocumented feature then I
could add a special case to my tool to take also the addresses listed
in the INA flag. And Jerry would have to do the same, just the other
way around. The frustating thing is that it's hard for software
developers to know about undocumented features. Please tell the FTSC
about such stuff, so we are able to document that.

binkd_nodelister.pl has source available and it was distributed in the I-BINKD FDN so it would be available for others to use to generate their own FTN nodelist to binkd NODE list lists... no documentation necessary...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... "Kala Khristougena kai Eftikhes to Neon Ethos." - Greek Christmas
---
* Origin: (1:3634/12.73)

On 2018 Dec 06 19:44:42, you wrote to Fred Riccio:

First we have to get all the details of the undocumented standard.

there is no such thing...

How are port numbers handled?

like normal...

If we take Carol's nodelist entry as example and assume she runs binkd
on port 8080 we would have:

INA:shenks.synchro.net,IBN:shenks.dyndns.org:8080

Does the port 8080 also apply to shenks.synchro.net?

no...

Or is the standard binkp port assumed for shenks.synchro.net?

yes unless there's an IBN:8080 flag to which the default domain from the "system name" field or the INA flag would apply... since she is using the standard ports, this question doesn't even apply to her nodelist entry...

FYI, I agree that using two IBN records, as documented in FTS-5001,
would have been a LOT cleaner than one INA and one IBN, but one of
each DOES work. To quote a past FTSC chair, "If you do it this way,
it will work".

Contradicting standards aren't very helpful.

i don't see any contradiction... what i do see is that *Cs need to have a good understanding about the nodelist flags, how they are applied, and how they are used... going IP has increased the complexity of indicating a system's capabilities via nodelist lines... it is no longer just a matter of which mailer you use (for the X* flags) or which modem protocols but now also multpile domains and ports, too...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... We are in the Cooking Section, save your fantasies for Unmitigated Sex!
---
* Origin: (1:3634/12.73)

On 2018 Dec 06 21:01:08, you wrote to Fred Riccio:

Carol's entry in that extraction of NodeList.224 is...

Node 1:275/100@fidonet shenks.dyndns.org;shenks.synchro.net -

which is causes BinkD to try the dyndns.org host first, if it doesn't
resolve it tries the synchro.net address.

Then obviously the combination of Jerry's script and binkd does not qualify as a properly configured FTSC complient software.

it is absolutely properly configured... it works exactly as binkd intends it to

work... the result is also exactly as intended, too... that result is that xxcarol's system is available via another domain name if one of them fails for some reason (eg: dyns updater doesn't update the domain entry)... if both/all domains are unresponsive, then sure, there may be a problem on that system... if only one dyns updater fails, it is not as big a problem because the other domain should still be working... radius/argus/taurus all work the same way except they also have finer capabilities in that they handle more protocols than just IBN so their node list format is more detailed and their convertor(s)

may not use the same data in the same way... they should but those mailer devs are quite quiet in recent years and i'm not sure who is maintaining their convertors... scott little would know more on that since he generates the distributed ARGUS.TXT file...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... smoke gets in your eyes....
---
* Origin: (1:3634/12.73)

On 2018 Dec 06 21:22:06, you wrote to Fred Riccio:

The Schwartz way does not work.

.....300,INA:fido.vlist.net,IBN:fido.vlist.eu,ITN,IVM

With the Schwartz interpretation, how does one signal, that fido.vlist.eu is to be used for ITN and IVM and fido.vlist.eu for IBN but fido.vlist.net is NOT to be used for IBN?

take off the INA and move the domain to those two flags... the "system name" field and the INA flag signal the default domain to use... in your example IBN is not supported on the default domain so you cannot use a default domain entry

in the "system name" field or the INA flag... you have to list the domain on the flags for the protocols... the question then is "are both ITN and IVM supported on fido.vlist.net as well as fido.vlist.eu?"... since your IBN knocks

out the ability to use the default domain, you would list two ITN and two IVM flags with the two domains... i fail to see how this is any sort of alternate interpretation or understanding of the documentation...

To quote a past FTSC chair, "If you do it this way, it will work".

But if one does NOT do it this way and makes something else, it may not work. Having two conflicting interpretations of the same flag does not work.

i don't understand what conflicting interpretations of which flag there are...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Disclaimer: We've no idea how the hell this happened (hee hee titter).
---
* Origin: (1:3634/12.73)

On 2018 Dec 07 20:28:38, you wrote to Fred Riccio:

MvdV>>> Then obviously the combination of Jerry's script and binkd does
MvdV>>> not qualify as a properly configured FTSC complient software.

FTSC complient as documented by the FTSC in FTS-5001.

YOUR opinion DOES NOT define current practice. The software in use
does.

So you say, but that is just YOUR opinion.

no, it is the opinion of many others, too...

Documenting current practise and calling it a standard is fine as long
as current practise is unambiguous and consistent.

that is not the fidonet way... fidonet is about experimenting...

"Very simple; it is a hobby, a non-commercial network of computer
hobbiests ("hackers", in the older, original meaning) who want to
play with, and find uses for, packet switch networking. It is not
a commercial venture in any way; FidoNet is totally supported by
it's users and sysops, and in many ways is similar to ham radio,
in that other than a few "stiff" rules, each sysop runs their
system in any way they please, for any reason they want."
- FidoHist.Txt, 7/14/85, Tom Jennings, the founder of Fidonet

there has been a slow and exorable movement to try to narrow fidonet's capabilities and stifle experimentation and development of newer capabilities for moving traffic from one system to another...

Unfortunately there is not one single current practice.

as it should be... they are all common/current practise...

There are softwares around that do things in conflicting ways.
Documenting all of it as a standard is unworkable.

the FTSC doesn't document software... it is easy enough to put in a note "if you use such'n'such mailer, you need to do this intead" or similar...

Making standards is making choices between incompatible alternatives.

that's why there are multiple standards... software chooses which standards they will follow... those they do not choose to follow do not apply to them no matter what others' think...

Demanding that the FTSC documents all current parctises as standards
is asking for a mission impossible.

who is demanding such? the FTSC set the goal themselves when the group was first put together... that goal has remained the same ever since...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Have a day - manic depressive.
---
* Origin: (1:3634/12.73)

Hi Carol!

Dec 09 11:49 2018, Carol Shenkenberger wrote to Markus Reschke:

Wouldn't we get two FTS docs contradicting each other then???

Not if we align them. Take what is in existing use, see what the differences are, then what tools already use them and see what works.

The FTSC documented one:
- if there's an address in the IBN flag use that one and only that one
- if the IBN flag doesn't include an address take all the addresses from all INA flags

The undocumented standard:
- take all addresses in IBN and INA flags

Q: How ports are handled by the undocumented standard? If we have INA:my-bbs.ddns.org and IBN:my-bbs.dyndns.com:8080 for example, does the port number also apply the the address in the INA flag?

This isn't a really common thing to see (a site with 2 lookup
addresses). I'd say most of us with 2 have a reason for it. Mine is backup connectivity for the most part. I've had one or the other go
off for a bit and with the game league (Battlenet) that can get nasty fast.

Over here most of the distribution nodes have several FQDNs for resilience. If one dyn-DNS service fails the node is still reachable via its second FQDN.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Hello Mark!

Dec 09 10:28 2018, mark lewis wrote to Markus Reschke:

Putting on my software developer hat, I'm quite unhappy with such
undocumented features.

what undocumented features? IIRC, binkd was the first to offer this capability... you can easily list multiple semicolon separated
domains in the NODE lines...

It seems that you have misunderstood me completely. I was not talking about that nodes with multiple FQDNs aren't standard. We are discussing the way multiple FQDNs are listed in the nodelist. Carol told me Z1 puts the FQDNs in the IBN and INA flags, i.e. both should be used. The documented way is to use either multiple INA flags or multiple IBN flags based on the specific situation.

BTW, my tool follows the FTSC documented method, and if there are 20 INA flags it will take all 20 addresses, same for IBN. But if there's an address in a IBN
flag that one prevails and the address from the INA flag is discarded.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Hi Mark!

Dec 09 11:33 2018, mark lewis wrote to Markus Reschke:

So it would extract additional addresses which aren't intended for
binkp for a node entry following the FTSC docs (if listed take just
the address in the IBN flag).

wrong... it extracts the domain from the "system name" field, the INA flag(s) and the IBN flag(s)... the domains listed in the "system name" field and the INA flags are default domains to attempt a connection with... they are valid to use if the domains attached to any IBN flags fail to connect...

Sorry, you got that totally wrong. We're talking about the way multiple addresses are listed in the IBN and INA flags. And we found out that there are two ways, one documented in a FTSC doc and the other one undocumented.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Hi Mark!

Dec 09 11:40 2018, mark lewis wrote to Markus Reschke:

First we have to get all the details of the undocumented standard.

there is no such thing...

So there's only FTS-5001? What about the method Carol explained?

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Re: Candidates vision request
By: mark lewis to Carol Shenkenberger on Sun Dec 09 2018 10:20 am

,100,Shenks_Express,Virginia_Beach_VA,Carol_Shenkenberger,-Unpublis
he d-,300,XX,CM,INA:shenks.synchro.net,IBN:shenks.dyndns.org

Can you tell us according to what part(s) of which FTSC standard(s)
this nodelist entry contains information that is never used by a
properly configured mailer?

What standards do you show to represent when a site has 2 resolving
addresses, one preferred for IBN but the other for everything? Z1
practical resolution, yet another thing not documented.

this multiple domain resolution thing is built into some mailers... it is not available for others... those mailers that can see and use multiple domains will cycle through them trying each one in succession until a connection is made or a number-of-tries counter has been reached... this works also with a domain name in the "system name" field if one were to use that field for a domain name instead of a system name... one could also use additional IBN flags to indicate more than the possible three domains when using the available fields where a domain name is able to be listed...

Yup, old school to use the BBS name field. One of the earlierst methods and even allows a static IP.

I think the issue is software differences. In a purist stance, if they all resolve to the same place and that one *critically* is always up with no outages, then listing or even having others becomes moot.

That however is the perfect world scenario.

the following would be a valid entry for a system with five domains available for connection...

,100,domain1.invalid,Virginia_Beach_VA,Carol_Shenkenberger,-Unpublished-,3 00,XX,CM,INA:domain2.invalid,IBN:domain3.invalid,IBN:domain4.invalid,IBN:d omain5.invalid

And would cycle though them (if having a mailer who did that). I assume domain2 first then 3-5 and *may* catch domain 1 with other mailers? Older ones may only see 3-5 unless using a parsed list like I-Argus or one of the I-BINK types.

The world is not black and white.

very true...

Occasonally helpful for those with a mailer that can take advantage of it. Others may have to manually look up a site to see if there is a alternate path if something seems offline. It's all about communication and anything that helps that in the nodelist, works for me.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: mark lewis to Michiel van der Vlist on Sun Dec 09 2018 11:26 am

Are you aware that to help out those that can not get native IPv6
from there own ISP, there are providers that offer a so called
"tunnel service" for free? Can you name one of hem?

what does this have to do with the FTSC??

I rather like Hurricane Electric and have been poking at it for some time. DYNDNS I think has it also but haven't checked deeper there.

2-3 months ago when checking, myy local ISP's limited this to commercial accounts to have a true IPV6. Internet searches show there is an apparent difference in a tunnel IPV6 and a true IPV6. Comments in other areas seem to lead to same. My 'pokes' have not been extensive but then, no one is trying to connect to me via IPV6.

Humm... Dyndns may be a good route. I may be able to get it cheaper there since I am a regular customer already.

No rush. I paid my 55$ for the year for my dyndns.org account just a few days ago.

xxcarol

--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: Markus Reschke to mark lewis on Sun Dec 09 2018 19:19:46

BTW, my tool follows the FTSC documented method, and if there are
20 INA flags it will take all 20 addresses, same for IBN.

i see no problem with that...

But if there's an address in a IBN flag that one prevails and the
address from the INA flag is discarded.

you should rethink that... the INA is a default but having it as well as an IBN with an attached domain does not negate one or the other domain... both are still valid... now, if they are the same domain, then sure, filter out one of them but if they are different, both are still valid...

i do not see where the spec differs from that...


)\/(ark
--- SBBSecho 3.06-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Hello Markus!

09 Dec 18 19:04, you wrote to Carol Shenkenberger:

The FTSC documented one:
- if there's an address in the IBN flag use that one and only that one
- if the IBN flag doesn't include an address take all the addresses from all INA flags

The undocumented standard:
- take all addresses in IBN and INA flags

Putting the hostname in the system field was a kludge needed at the time.
With the introduction of hostnames in the IBN: an INA: flags, putting a
hostname in the system field should be discouraged.

Undoubtedly there is still software around that will for a hostname in
the system field. The system field should be reverted to its original
purpose, even if only for folklore.

Whatever the docoments say. My understanding of where hostnames are listed,
is, when only one protocol is supported, list it with the protocol flag.
When more protocols are listed and supported on the same host, list the
hostname with the INA flag. If hostnames are different for the protocols
list the hostnames with the protocols. Listing a protocol port with with
INA makes no sense, as that would mean that multiple protocols use
the same port. Off standard port numbers should be listed with their
protocol flags.

It makes sense that software that reads the nodelist, cares for the misuse
that some software and peolple have introduced. This misuse may be docomented,
but should not be included in a standard.

Just my two cents.

Defining some program that has been built long ago, as how a standard
should be set, should be out of the question.

And yes, I do not use any of the programs laying around to create my own
binkd nodelist.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Mark!

Dec 09 11:57 2018, mark lewis wrote to Michiel van der Vlist:

i don't understand what conflicting interpretations of which flag
there are...

Let's try some example. ;) Carol's nodelist entry includes:

INA:shenks.synchro.net,IBN:shenks.dyndns.org

Carol has explained that in Z1's view both FQDNs should be used for binkp.

Based on the FTSC doc multiple addresses should be listed either as

INA:shenks.synchro.net,INA:shenks.dyndns.org,IBN

or as

IBN:shenks.synchro.net,IBN:shenks.dyndns.org

The INA flag is meant to list a common FQDN for all protocols/services. If the IBN flag carries an address it should be used for binkp. It prevails any common
address(es) from the INA flag(s) because it's specific to binkp. But this contradicts the method Carol has explained.

A nodelist converter for binkd following FTSC-5001 would extract just shenks.dyndns.org since it's the binkp specific address. And based on the undocumented way the tool would extract shenks.dyndns.org and shenks.synchro.net. Maybe you'll understand the problem now.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Hello Carol!

Dec 09 13:41 2018, Carol Shenkenberger wrote to mark lewis:

Yup, old school to use the BBS name field. One of the earlierst
methods and even allows a static IP.

I haven't checked the current nodelist, but we also have?/had IP addresses encoded as telephone number.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

Re: Candidates vision request
By: mark lewis to Markus Reschke on Sun Dec 09 2018 11:33 am

binkd_nodelister.pl has source available and it was distributed in the I-BINKD FDN so it would be available for others to use to generate their own FTN nodelist to binkd NODE list lists... no documentation necessary...

About 2 months ago I worked a feed for one of the I-BINK lists. There are more than one. I was slowly checking for differences and looking to reverse engineer an understanding of them.

It's a courtesy feed, not to be sent out from here as the hatch list name duplicates another.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: FTS-5001
By: mark lewis to Markus Reschke on Sun Dec 09 2018 11:40 am

i don't see any contradiction... what i do see is that *Cs need to have a good understanding about the nodelist flags, how they are applied, and how they are used... going IP has increased the complexity of indicating a system's capabilities via nodelist lines... it is no longer just a matter of which mailer you use (for the X* flags) or which modem protocols but now also multpile domains and ports, too...

Yes. That is why I hunted forthe old FAQ I wrote on how to teach a *C on it. That FAQ is no longer on the FTSC site. It went away sometime between Scott Little and MVDL. The situation has changed so it would need editing anyways.

What it was, was a set of 'preferred listing types' that matched mailers of the time.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Hi Kees!

Dec 09 19:57 2018, Kees van Eeten wrote to Markus Reschke:

It makes sense that software that reads the nodelist, cares for the misuse that some software and peolple have introduced. This misuse
may be docomented, but should not be included in a standard.

Yep! All nodelist-to-binkp converters do exactly that. Some check only one or two old/odd/misused fields, some check more. There's also the DO4 user flag.

ciao,
Markus

---
* Origin: *** theca tabellaria *** (2:240/1661)

On 2018 Dec 09 19:04:02, you wrote to Carol Shenkenberger:

Not if we align them. Take what is in existing use, see what the
differences are, then what tools already use them and see what works.

The FTSC documented one:
- if there's an address in the IBN flag use that one and only that one

the phrase "only that one" does not appear in FTS-5001.006... yes, if there's a

domain attached to the IBN flag, use it...

i think that the two examples given using two of the same flag should be expanded to show how to use two or more other flags with attached domains as well... i don't understand why this is so hard...

- if the IBN flag doesn't include an address take all the addresses
from all INA flags

yes...

The undocumented standard:
- take all addresses in IBN and INA flags

that's not undocumented... if there are domains listed on the flags, they are all taken and considered for the final output... the decision making tree for that is different for different mailers... some are protocol oriented, some do not recognise INA, some use INA as well as the domains attached to other flags...

Q: How ports are handled by the undocumented standard? If we have INA:my-bbs.ddns.org and IBN:my-bbs.dyndns.com:8080 for example, does the port number also apply the the address in the INA flag?

This isn't a really common thing to see (a site with 2 lookup
addresses). I'd say most of us with 2 have a reason for it. Mine is
backup connectivity for the most part. I've had one or the other go
off for a bit and with the game league (Battlenet) that can get nasty
fast.

Over here most of the distribution nodes have several FQDNs for

resilience.

If one dyn-DNS service fails the node is still reachable via its second FQDN.

that's exactly what xxcarol is doing with her INA/IBN entries...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... My kid wanted a watch for Christmas, so we let him.
---
* Origin: (1:3634/12.73)

On 2018 Dec 09 19:19:46, you wrote to me:

Putting on my software developer hat, I'm quite unhappy with such
undocumented features.

what undocumented features? IIRC, binkd was the first to offer this
capability... you can easily list multiple semicolon separated
domains in the NODE lines...

It seems that you have misunderstood me completely.

maybe...

I was not talking about that nodes with multiple FQDNs aren't
standard. We are discussing the way multiple FQDNs are listed in the nodelist. Carol told me Z1 puts the FQDNs in the IBN and INA flags,

yes... the other zones do the same thing, too... i don't see a problem...

i.e. both should be used.

that's up to the decision tree in the software...

The documented way is to use either multiple INA flags or multiple IBN flags based on the specific situation.

right... nothing is said that you cannot use mixed flags or multiples of such...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... An occasional BUTT whooping helps a child stay in line.
---
* Origin: (1:3634/12.73)

On 2018 Dec 09 19:32:22, you wrote to me:

So it would extract additional addresses which aren't intended for
binkp for a node entry following the FTSC docs (if listed take just
the address in the IBN flag).

wrong... it extracts the domain from the "system name" field, the INA
flag(s) and the IBN flag(s)... the domains listed in the "system name"
field and the INA flags are default domains to attempt a connection
with... they are valid to use if the domains attached to any IBN flags
fail to connect...

Sorry, you got that totally wrong.

no i didn't... i explained how binkd_nodelister.pl pulls the domains from the St.Louis nodelist lines...

We're talking about the way multiple addresses are listed in the IBN
and INA flags.

i know this... the "system name" field must also be considered since it was the

first "default" domain to use...

And we found out that there are two ways, one documented in a FTSC doc
and the other one undocumented.

ARAICT, they are all documented right there in FTS-5001.006 and they're all perfectly viable and operational...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... My idea of housework is to sweep the room with a glance.
---
* Origin: (1:3634/12.73)

On 2018 Dec 09 19:37:06, you wrote to me:

First we have to get all the details of the undocumented standard.

there is no such thing...

So there's only FTS-5001? What about the method Carol explained?

what about it? it is also listed in FTS-5001... you have the entry for IBN and you have the entry for INA... looks like they're both documented to me...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... The first fall hurts. The others harden.
---
* Origin: (1:3634/12.73)

Re: What would YOU do?
By: Markus Reschke to Carol Shenkenberger on Sun Dec 09 2018 07:04 pm

Not if we align them. Take what is in existing use, see what the
differences are, then what tools already use them and see what
works.

The FTSC documented one:
- if there's an address in the IBN flag use that one and only that one
- if the IBN flag doesn't include an address take all the addresses from all INA flags

The undocumented standard:
- take all addresses in IBN and INA flags

We have mailers who use the second one already. That practice does not harm a mailer using just IBN and defaulting back to the INA flag.

It could be the wording is bad. When it was written, the FTSC meant is there was an address on IBN, it would priority over the INA address. If no address on IBN, it would use INA. If only a port on IBN, use INA but the port on IBN.

Humm, bit of work to be done.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

or they didn't receive the messages... it is all too easy for netmails to go into a blackhole in todays BSO driven world...

Follow the tree and such crap doesn't happen ... and when it does it's easy to figure out...

\%/@rd

--- D'Bridge 3.99 SR40
* Origin: The best gold is at the bottom of barrels of crap (2:292/854)

Re: Candidates vision request
By: Markus Reschke to mark lewis on Sun Dec 09 2018 07:19 pm

It seems that you have misunderstood me completely. I was not talking about that nodes with multiple FQDNs aren't standard. We are discussing the way multiple FQDNs are listed in the nodelist. Carol told me Z1 puts the FQDNs in the IBN and INA flags, i.e. both should be used. The documented way is to use either multiple INA flags or multiple IBN flags based on the specific situation.

Mistranslation. I said both *can* be used, not should. Most people have only 1 FQDN/ aka look up address for a protocol. When we do see a site with multiples, then the rules are a bit vague.

xxcarol

--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Candidates vision request
By: Markus Reschke to Carol Shenkenberger on Sun Dec 09 2018 08:13 pm

Yup, old school to use the BBS name field. One of the earlierst
methods and even allows a static IP.

I haven't checked the current nodelist, but we also have?/had IP addresses
encoded as telephone number.

Yes. It was an early version as well to place one there al=s an alertnative for ION's. Very messy.

Then we had 0000-0-0-0-0 as an unvaried string in the phone field. That was also in the FAQ series, now gone. Latwr adopted by Z6 and Z1 until use of Makenl features made it redundant.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

On 2018 Dec 09 14:56:42, you wrote to Markus Reschke:

It could be the wording is bad.

agreed...

When it was written, the FTSC meant is there was an address on IBN, it would priority over the INA address. If no address on IBN, it would
use INA. If only a port on IBN, use INA but the port on IBN.

and if there is INA and IBN both with domains, use the IBN domain first and then the INA one... if the IBN contains a port number, use it for both...



PS: i've just sent you a direct netmail from this point. i watched it get delivered and am writing this just as a "head's up! please check your netmail or unsecure inbound."... it is a message forwarded from the mystic echo that was written back in july 2018...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Shop at Wal-Mart. Hail Satan.
---
* Origin: (1:3634/12.73)

Re: What would YOU do?
By: mark lewis to Carol Shenkenberger on Mon Dec 10 2018 10:13 am

It could be the wording is bad.

agreed...

When it was written, the FTSC meant is there was an address on IBN,
it would priority over the INA address. If no address on IBN, it
would use INA. If only a port on IBN, use INA but the port on IBN.

and if there is INA and IBN both with domains, use the IBN domain first and then the INA one... if the IBN contains a port number, use it for both...

I belive the intent was for 2 different domains in that scenerio (like mine).
I suspect if IBN had a port number and INA didn't then the port number should only be used with that domain. I need to go back and read the relevant documents to see how that was handled and if it was clear.

PS: i've just sent you a direct netmail from this point. i watched it get delivered and am writing this just as a "head's up! please check your netmail or unsecure inbound."... it is a message forwarded from the mystic echo that was written back in july 2018...

Ok, will look for it. THats just before I joined zone21 where I get most of my mystic information.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

On 2018 Dec 10 17:35:54, you wrote to me:

When it was written, the FTSC meant is there was an address on IBN,
it would priority over the INA address. If no address on IBN, it
would use INA. If only a port on IBN, use INA but the port on IBN.

and if there is INA and IBN both with domains, use the IBN domain
first and then the INA one... if the IBN contains a port number, use
it for both...

I belive the intent was for 2 different domains in that scenerio (like mine).

yes, exactly... mine will be like that shortly, too... then i'll be dropping back to just one after the first of the year...

I suspect if IBN had a port number and INA didn't then the port number should only be used with that domain.

INA can't have a port number anyway ;)

I need to go back and read the relevant documents to see how that was handled and if it was clear.

i think the main thing is the example only shows two INA together and two IBN together... they can also be mixed... convertors should only be limited by the capabilities of the mailer they are converting for... if the argus/radius/taurus family can't handle multiple domains, then that one convertor should not put in multiple domains... we already know that binkd can work with them and the binkd_nodelister script is the base convertor used for the binkd.txt distributed node list...

PS: i've just sent you a direct netmail from this point. i watched it
get delivered and am writing this just as a "head's up! please check
your netmail or unsecure inbound."... it is a message forwarded from
the mystic echo that was written back in july 2018...

Ok, will look for it. THats just before I joined zone21 where I get most of my mystic information.

did you find it?

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Don't tell me how the clock works, just what time it is.
---
* Origin: (1:3634/12.73)

Re: What would YOU do?
By: mark lewis to Carol Shenkenberger on Tue Dec 11 2018 10:31 am

When it was written, the FTSC meant is there was an address on
IBN, it would priority over the INA address. If no address on IBN,
it would use INA. If only a port on IBN, use INA but the port on
IBN.

and if there is INA and IBN both with domains, use the IBN domain
first and then the INA one... if the IBN contains a port number,
use it for both...

I belive the intent was for 2 different domains in that scenerio
(like mine).

yes, exactly... mine will be like that shortly, too... then i'll be dropping back to just one after the first of the year...

I recall looking at examples and asking some questions. I've been what I call 'dual-homed' like that for a decade or so now but I don't recall when I actually added it to my listing. Only that I added it later.

I suspect if IBN had a port number and INA didn't then the port
number should only be used with that domain.

INA can't have a port number anyway ;)

Lol well I did say I needed to brush up on that set again. I guess because it's not really tied to a specific so that went only on the IBN, ITN etc spots.

I need to go back and read the relevant documents to see how that
was handled and if it was clear.

i think the main thing is the example only shows two INA together and two IBN together... they can also be mixed... convertors should only be limited by the capabilities of the mailer they are converting for... if the argus/radius/taurus family can't handle multiple domains, then that one convertor should not put in multiple domains... we already know that binkd can work with them and the binkd_nodelister script is the base convertor used for the binkd.txt distributed node list...

Yes. I believe my old FAQ (long gone) also showed the pattern I use based off the Binkd system.

Since I don't connect to any systems set like mine, I can't see if it cycles through or not. My ARGUS may well predate that. Had a node in my Battlenet league though who did exactly that and would alert me if one seemed down. He'd send me a log snippet showing the offender's issues then the other working flawlessly. Not a common problem but for 55$ a year, my folks have an option. I mean really, less than 5$ a month. I'm good with that.

PS: i've just sent you a direct netmail from this point. i watched
it get delivered and am writing this just as a "head's up! please
check your netmail or unsecure inbound."... it is a message
forwarded from the mystic echo that was written back in july
2018...

Ok, will look for it. THats just before I joined zone21 where I
get most of my mystic information.

did you find it?

Yup! You addressed it to xxcarol (snicker). My system doesn't know who that is so it wasn't obvious. Thanks though! I'm pending netmail or email back from Leslie now. He's been polling me so there wasn't any backlog to alert me.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

On 2018 Dec 11 17:42:26, you wrote to me:

did you find it?

Yup! You addressed it to xxcarol (snicker). My system doesn't know
who that is so it wasn't obvious.

if you are running the latest sbbs 3.17a code, you can run exec/echocfg, go into the netmail settings and add xxcarol as a sysop alias... those netmails will be dropped into your mailbox... i figured you were using it as your name or handle on your setup...

Thanks though! I'm pending netmail or email back from Leslie now.
He's been polling me so there wasn't any backlog to alert me.

yeah... i saw the email but nothing else so far but that's fine, too :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... REAL programmers write self-modifying code.
---
* Origin: (1:3634/12.73)