Hi All!

Some points in FTS-5004 seems to me ungrounded and unusable.

1. In my oppinion the first and main target for DDN is possibility for IP mailers to connect fidonet nodes using DNS resolving.
This may be implemented by public or private (local) DNS-zone build by nodelist (DDN).
Sometimes it's convenient to add additional information such as IP-addresses of points or short hostnames (aliases), such as "ic.ddn" as cname to "n0.n2.z2.ddn" or TXT comments or some other info. But FTS-5004 forbids such cases:
===
The only valid source for DDN records is FTS-5000 world nodelist.
Data from partial (network etc.) segments SHOULD NOT appear in
DDN until they get into world nodelist. Data from any sources
other than nodelist MUST NOT appear in DDN NS zones.
===
I do not see any reasons for this limitation and propose to remove it.
This extends definition of "DDN": many DNS zones that are not DDN according to the FTS (because contain additional info) are DDN actually, because thay automaticlly built by nodelist and contain all information about IP-addresses from the nodelist.

2. Following paragraph seems strange and harmful:
===
If the INA flag (or any of the protocol flags) of any node carries
host name built from the FTN address using DDN or any other method,
that node MUST be skipped and MUST NOT appear in resulting NS zone.
===
It's technically impossible to detect, was hostname built from the FTN address using "any other method" (such as concatenation, crc, hash etc) or not.
And I see no reasons why such hostnames should be skipped.
This limitation makes DDN unusable because not all nodes with published IP address will be accessible using the DDN.
I propose to remove this paragraph from the FTS.

3. "In general, such names SHOULD NOT appear in the nodelist".
I agree that hostnames from DDN domain is not suitable for nodelist, this makes infinite recursion.
But if the domain is not DDN, that it's fully correct to specify hostname built from my FTN address in my private domain or in public dyndns service as my hostname. It's clear and convenient.
I propose to change this sentense to "Hostnames from DDN zones SHOULD NOT appear in the nodelist" (or even "MUST NOT"), but do not forbid adding hostnames built from FTN address by "any method" if the address was configured explicitly in this domain and it's not DDN.

As an example, there is domain node.binkp.net which allows any fidonet sysop to specify or change address of his node with web interface (with authorization by fidonet netmail). Also there is domain dyn.binkp.net for dynamic IP nodes which set IP by binkp-protocol poll of some system address. These are free services for fidonet sysops that worked for many years (more than 10). But using of this services are forbidden by FTS-5004, and I think this was one of target for this FTS. Alexey Vissarionov now insists that using binkp.net by some sysops is XAB because this violates the FTS.
Moreover, sometime (many years ago) he mentioned as an argument agains binkp.net that this service is supported by ukrainian (and Alexey is russian) and even threatened to make DDoS attack to all NSs of binkp.net for thraw this service down (he repeated this threat several days ago in sysops echo).

What do you think about this?

Lucky carrier,
Pavel
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827
* Origin: Lucky Carrier BBS (2:463/68)

Hi Pavel,

Pavel wrote (2022-09-04):

Some points in FTS-5004 seems to me ungrounded and unusable.

1. In my oppinion the first and main target for DDN is possibility for IP mailers to connect fidonet nodes using DNS resolving. This may be implemented by public or private (local) DNS-zone build by nodelist
(DDN). Sometimes it's convenient to add additional information such as IP-addresses of points or short hostnames (aliases), such as "ic.ddn" as cname to "n0.n2.z2.ddn" or TXT comments or some other info. But FTS-5004 forbids such cases:
===
The only valid source for DDN records is FTS-5000
world nodelist. Data from partial (network etc.) segments SHOULD NOT appear in DDN until they get into world nodelist. Data from any sources other than nodelist MUST NOT appear in DDN NS zones.
===

I'm not sure ic.ddn would count as a DDN record, because it's not in the f*.n*.z*.ddn namespace. TXT records are also not covered by FTS-5004.

I do not see any reasons for this limitation and propose to remove it.

I believe the idea of that restriction is, that a DDN should not deviate from the "world nodelist". Not sure what a "DDN NS zones" is supposed to mean.

2. Following paragraph seems strange and harmful:
===
If the INA flag (or any of the protocol flags) of any node carries
host name built from the FTN address using DDN or any other method,
that node MUST be skipped and MUST NOT appear in resulting NS zone.
===
It's technically impossible to detect, was hostname built from the FTN address using "any other method" (such as concatenation, crc, hash etc)
or not. And I see no reasons why such hostnames should be skipped. This limitation makes DDN unusable because not all nodes with published IP address will be accessible using the DDN. I propose to remove this paragraph from the FTS.

I'm not even sure what they tried to express with this paragraph.

3. "In general, such names SHOULD NOT appear in the nodelist".
I agree that hostnames from DDN domain is not suitable for nodelist, this makes infinite recursion. But if the domain is not DDN, that it's fully correct to specify hostname built from my FTN address in my private
domain or in public dyndns service as my hostname. It's clear and convenient. I propose to change this sentense to "Hostnames from DDN
zones SHOULD NOT appear in the nodelist" (or even "MUST NOT"), but do not forbid adding hostnames built from FTN address by "any method" if the address was configured explicitly in this domain and it's not DDN.

Yes, there should be only hostnames in the nodelist that do resolve properly to the IP of the node. But that is something the sysops, the *Cs and the nodelist software are responsible for. If there would be something like

Hub,545,G_from_K,M,A_V,-Unpublished-,300,IBN:f545.n5020.z2.ddn.binkp.net

in the nodelist, the harm would already be done. CNAME recursions can happen anyway and any DNS client and server should be able to handle it.

As an example, there is domain node.binkp.net which allows any fidonet sysop to specify or change address of his node with web interface (with authorization by fidonet netmail). Also there is domain dyn.binkp.net for dynamic IP nodes which set IP by binkp-protocol poll of some system address. These are free services for fidonet sysops that worked for many years (more than 10). But using of this services are forbidden by FTS-5004, and I think this was one of target for this FTS.

The binkp FAQ says:

It is convenient to use the binkp.net domain as the root-domain for binkd (any DDN is also suitable for this role).
There are subdomains:
ddn.binkp.net - information from the nodelist (and only it);
node.binkp.net - addresses of nodes explicitly specified via http://binkp.net; dyn.binkp.net - dynamic IPs.
The main binkp.net zone contains a collection of information from these three sources.

(translated by https://www-binkp-net.translate.goog/faq.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_pto=wapp)

So anyone is free to use ddn.binkp.net as a standards compliant DDN. I don't see how FTS-5004 can forbid anything that doesn't even claim to be DDN.

Alexey Vissarionov now insists that using binkp.net by some sysops is XAB because this violates the FTS.

Like the existence of the Ukraine is extremely annoying for some Russians?

Is it also XAB if I remove all Russian nodes from the NODELIST and offer it as NORUSNDL?

Why I am not free to use the method of IP look up that I prefer?

I mean there are DNS services that blocks lookups of malicious host names or porn sites.

Moreover, sometime (many years ago) he
mentioned as an argument agains binkp.net that this service is supported by ukrainian (and Alexey is russian) and even threatened to make DDoS attack to all NSs of binkp.net for thraw this service down (he repeated this threat several days ago in sysops echo).

Alexey can go and violate Putin's dick or join Special Operation Cannon Fodder.

Btw, does he embed DDoS bots in the software he offers at
download.binkd.org
download.golded.org
download.huskyproject.org
? ;-)

What do you think about this?

What I find problematic is that binkd does use binkp.net as the default root-domain. And that you always will have outdated node records. Sysops find the binkp.net website, register, put something in the DB and than forget about it. Then one day the hostname in the nodelist gets changed, and the one in [node.]binkp.net is outdated. ddn/node/dyn.binkp.net is great, binkp.net only creates more problems.

---
* Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (2:280/464.47)

Hi Oli!

15 Sep 22, Oli ==> Pavel Gulchouck:

Some points in FTS-5004 seems to me ungrounded and unusable.

1. In my oppinion the first and main target for DDN is possibility for IP
mailers to connect fidonet nodes using DNS resolving. This may be
implemented by public or private (local) DNS-zone build by nodelist
(DDN). Sometimes it's convenient to add additional information such as
IP-addresses of points or short hostnames (aliases), such as "ic.ddn" as
cname to "n0.n2.z2.ddn" or TXT comments or some other info. But FTS-5004
forbids such cases:
===
The only valid source for DDN records is FTS-5000
world nodelist. Data from partial (network etc.) segments SHOULD NOT
appear in DDN until they get into world nodelist. Data from any sources
other than nodelist MUST NOT appear in DDN NS zones.
===

I'm not sure ic.ddn would count as a DDN record, because it's not in the f*.n*.z*.ddn namespace. TXT records are also not covered by
FTS-5004.

FTS-5004 specifies contents of a DNS zone for being DDN. And according to this FTS no records other than generated from the nodelist should appear in the zone. Formally even SOA record violates this FTS, and I think this should be fixed to allow additional information which may be useful.
Alexey (author of this FTS) told that DNS zone which contains additional information (such as IP addresses of points) is not DDN according by FTS-5004.

I do not see any reasons for this limitation and propose to remove it.

I believe the idea of that restriction is, that a DDN should not deviate from the "world nodelist". Not sure what a "DDN NS zones" is
supposed to mean.

DNS zone is well-known term (https://en.wikipedia.org/wiki/DNS_zone), and "DDN NS zone" is definitely not "set of records in DNS zone".

May be, we can change this paragraph to something like "DDN MUST contains all information about IP addresses from the world nodelist and MUST NOT modify this information. DDN CAN contain information from other sources (pointlists, fresh network segments etc) only in addition to information from the world nodelist".

The idea is that official nodelist issued only weekly (I know about daily nodelist, but FPD specified weekly), and update nodelist information sometimes can takes a time. NC can be on vacation or some other delays.
But DNS gives possibility to update IP address quickly, for hours or minutes, and automatically. It's dumb to disable such possibility.

2. Following paragraph seems strange and harmful:
===
If the INA flag (or any of the protocol flags) of any node carries
host name built from the FTN address using DDN or any other method,
that node MUST be skipped and MUST NOT appear in resulting NS zone.
===
It's technically impossible to detect, was hostname built from the FTN
address using "any other method" (such as concatenation, crc, hash etc)
or not. And I see no reasons why such hostnames should be skipped. This
limitation makes DDN unusable because not all nodes with published IP
address will be accessible using the DDN. I propose to remove this
paragraph from the FTS.

I'm not even sure what they tried to express with this paragraph.

They tried to forbid binkp.net as a service where any sysop can add IP address for their node even if binkp.net will use another method for generating hostname by FTN address. But they can not specify explicit service "binkp.net" in standard (and the service can be started on another domain), so they specify some secondary properties of this service. Like "featherless biped with nails" as specification of human.

[...]

The binkp FAQ says:

It is convenient to use the binkp.net domain as the root-domain for binkd (any DDN is also suitable for this role).
There are subdomains:
ddn.binkp.net - information from the nodelist (and only it); node.binkp.net - addresses of nodes explicitly specified via http://binkp.net;
dyn.binkp.net - dynamic IPs.
The main binkp.net zone contains a collection of information from these three sources.

(translated by https://www-binkp-net.translate.goog/faq.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_pto=wapp)

So anyone is free to use ddn.binkp.net as a standards compliant DDN. I don't see how FTS-5004 can forbid anything that doesn't even
claim to be DDN.

If a sysop creates a record in binkp.net zone, for example f68.n463.z2.node.binkp.net, then adding INA:f68.n463.z2.binkp.net or INA:f68.n463.z2.node.binkp.net to nodelist violates FTS-5004: "host name built from the FTN address using DDN or any other method ... SHOULD NOT appear in the nodelist" even though neiher node.binkp.net nor binkp.net are not DDN.
And this is absurdity.

Alexey Vissarionov now insists that using binkp.net by some sysops is XAB because this violates the FTS.

Like the existence of the Ukraine is extremely annoying for some Russians?

Is it also XAB if I remove all Russian nodes from the NODELIST and offer it as NORUSNDL?

Why I am not free to use the method of IP look up that I prefer?

I mean there are DNS services that blocks lookups of malicious host names or porn sites.

Sorry, it's not about using binkp.net by sysop in the mailer for resolve nodes. Sure, nobody can forbid it.
It's about using binkp.net in INA flag in the nodelist - Alexey says it's XAB because it violates FTS-5004.

What do you think about this?

What I find problematic is that binkd does use binkp.net as the default root-domain. And that you always will have outdated node
records. Sysops find the binkp.net website, register, put something in the DB and than forget about it. Then one day the hostname in
the nodelist gets changed, and the one in [node.]binkp.net is outdated. ddn/node/dyn.binkp.net is great, binkp.net only creates more
problems.

Good point, I agree, the problem exists. Thank you.
I think I should periodically check if address specified in the node.binkp.net and ddn.binkp.net accessible by binkp protocol, and if not during some period (week or two) then remove the address and notify sysop about it. It's not hard to implement.

Lucky carrier,
Pavel
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827
* Origin: Ä»δΓ - øΓ« Γ«, τΓ« ¼δ »«½πτáѼ ó¼ÑßΓ« Γ«ú«, τΓ« σ«Γѽ¿ (2:463/68)

Hey Pavel!

@CHRS: CP1125 2

Which FTS supports the above encoding?

* Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68)

Що ти хочеш?

Life is good,
Maurice

... Fidonet 4K - Sweet Sixteen Penguins of the Apocalypse.
--- GNU bash, version 5.1.16(1)-release (x86_64-znver2-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

Hey Maurice!

Що ти хочеш?

Все ... Я хочу все.

Life is good,
Maurice

... I've got squirrels in my pants!
--- GNU bash, version 5.1.16(1)-release (x86_64-znver1-linux-gnu)
* Origin: Little Mikey's EuroPoint @ (2:280/464.113)

Hello Pavel!

Pavel wrote (2022-09-16):

Hi Oli!

I'm not sure ic.ddn would count as a DDN record, because it's not
in the f*.n*.z*.ddn namespace. TXT records are also not covered by
FTS-5004.

FTS-5004 specifies contents of a DNS zone for being DDN. And according to this FTS no records other than generated from the nodelist should appear in the zone.

Is this how DNS is intended to work? The binkp client also does not care about anything that does not match *.f*.n*.z*.ddn-zone.

Formally even SOA record violates this FTS, and I think this
should be fixed to allow additional information which may be useful.

or MX, TXT records for SPF, ...

Alexey (author of this FTS) told that DNS zone which contains additional information (such as IP addresses of points) is not DDN according by FTS-5004.

Interesting. To quote FTS-5004:

P - Point Number:
If the system is a point rather than a node then
this is their point number at that node.
Optional. If ".P" is missing then assume 0 (node itself).

What is the point in mentioning points in the FTS, when there are no points in the world nodelist and everything else is forbidden? ;)

Not sure what a "DDN NS zones" is supposed to mean.

DNS zone is well-known term (https://en.wikipedia.org/wiki/DNS_zone), and "DDN NS zone" is definitely not "set of records in DNS zone".

In DNS-speak there is no such thing as a "NS zone". NS is short for nameserver and DNS stands for Domain Name System. There is the NS record. But "NS zone" does not compute. If people try to write standards, they should use words that have a defined meaning or it becomes a ambiguous mess free for interpretation.

I also think DNS zones and NS records are completely irrelevant for the DDN standard. We are talking about the DDN domain, not about zones.

"A domain is a logical division of the DNS name space whereas a zone is physical, as the information is stored in a file called a zone file."

But if the standard did really mean DNS zone, you would only need a NS record, that sets a boundary to the zone like

something.ddn.example.com IN NS ns2.example.com

"A zone is a domain less any sub-domains delegated to other DNS servers"

May be, we can change this paragraph to something like "DDN MUST contains all information about IP addresses from the world nodelist and MUST NOT modify this information. DDN CAN contain information from other sources (pointlists, fresh network segments etc) only in addition to information from the world nodelist".

Question is: if there were multiple DDN services, would it be okay that each one could have different additional records from other sources or should every DDN be exactly the same?

Sorry, it's not about using binkp.net by sysop in the mailer for resolve nodes. Sure, nobody can forbid it. It's about using binkp.net in INA flag in the nodelist - Alexey says it's XAB because it violates FTS-5004.

Now I get it. I would agree that it is problematic, because the z*.binkp.net namespace also includes records that are generated from the nodelist. Why not use *.dyn.binkp.net and *.node.binkp.net addresses in the nodelist -> problem solved.

(Still, threatening to DDoS binkp.net is dumb)

---
* Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (2:280/464.47)

Maurice wrote (2022-09-16):

Hey Pavel!

@CHRS: CP1125 2

Which FTS supports the above encoding?

FTS-5003:

4. Known character set identifiers
----------------------------------

This is a list of character set and character encoding scheme
identifiers that are known to be in use or to have been in use in
Fidonet. This list is not exhaustive and is not meant to be a list
of characters sets or character encoding identifiers that all must
be supported by an implementation. It is perfectly all right for
an implementation to only have partial support.

---
* Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (2:280/464.47)

Hey Oli!

It is perfectly all right for an implementation to only have
partial support.

Best of luck with that. Mind you there are a few similar ones that are even more obscure so overall it isn't as bad as it can be. Also worthy of note is that glibc's iconv had no issues with it.

Life is good,
Maurice

... Monig mon hæfð micel feax on foran heafde, 7 wyrð færlice calu.
Many a man has plenty of hair on his head, and suddenly goes bald.
--- GNU bash, version 5.1.16(1)-release (x86_64-lilmikii-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Maurice wrote (2022-09-16):

Hey Oli!

It is perfectly all right for an implementation to only have
partial support.

Best of luck with that. Mind you there are a few similar ones that are even more obscure so overall it isn't as bad as it can be. Also worthy
of note is that glibc's iconv had no issues with it.

You call the official Ukranian DOS codepage obscure? What's your recommendation for Golded? Should he use the Russian codepage? Or would cp1251 be better and less obscure?

---
* Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (2:280/464.47)

Hi Maurice!

16 Sep 22, Maurice Kinal ==> Pavel Gulchouck:

@CHRS: CP1125 2

Which FTS supports the above encoding?

No FTS, you can just ignore this control.

This codepage and this control line was widely used in fidonet messages long time before any FTS and even FSP about @CHRS were issued, and golded config files for support this codepage were published and used by sysops in our region. Moreover, even now this is the most used codepage for ukrainian language in fidonet, utf-8 for some reasons is not widely used for cyrillic messages.

I do not think I should stop using this codepage only because it was not included in the list of codepages in FTS-5003.
More reasonable, CP1125 should be added in the next version of the FTS-5003. Especially because
===
This document tries to describe the current
use, as well as standardising the parts of it that were ambiguously
defined.
===

https://en.wikipedia.org/wiki/Code_page_866#Ukrainian_and_Belarusian_variants https://www.ibm.com/docs/de/db2/11.1?topic=tables-code-page-1125-generic-system-1125

Ö« Γ¿ σ«τÑΦ?

I'll be glad if the FTS about DDN could be improved or corrected.
And the FTS about charsets too.

Lucky carrier,
Pavel
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827
* Origin: Lucky Carrier BBS (2:463/68)

Hi Oli!

16 Sep 22, Oli ==> Pavel Gulchouck:

[...]

Sorry, it's not about using binkp.net by sysop in the mailer for resolve
nodes. Sure, nobody can forbid it. It's about using binkp.net in INA flag
in the nodelist - Alexey says it's XAB because it violates FTS-5004.

Now I get it. I would agree that it is problematic, because the z*.binkp.net namespace also includes records that are generated from
the nodelist.

What problem do you see with this?
Obviously if it's address from node.binkp.net that it will work, and if not, that it is unresolvable address.
There will be no CNAME loop in generated binkp.net by nodelist with such INA.

Why not use *.dyn.binkp.net and *.node.binkp.net addresses in the nodelist -> problem solved.

Not solved, because using of *.dyn.binkp.net and *.node.binkp.net also violates FTS-5004.
These zones are not generates by nodelist, but they use the same hostname generation nNN.fFF.zZZ.domain which is prohibited in INA flag by the FTS.

Lucky carrier,
Pavel
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827
* Origin: Lucky Carrier BBS (2:463/68)

Hey Oli!

You call the official Ukranian DOS codepage obscure?

Yes. DOS has been stone cold dead for decades now. Where have you been hiding? I can also say the same about CP866 if that makes you feel any better but here it is CP437 that is the DOS encoding of 'choice' ... although lack of chaoice might be best to describe it and whatever other encodings IBM has claim to. Personally over all the years and decades ASCII is the clear choice but that hinders human communications.

What's your recommendation for Golded?

UTF-8. Also I wouldn't recommend Golded. UTF-8 with msged would be my recommendation if that were an option. Myself I just use vim which happens to be the same editor I use for email and all text editing I ever do. By default it uses UTF-8 but can also handle other encodings if it mattered at all ... which of course it doesn't. Also there are many others that can handle ALL of one's needs for such things.

Should he use the Russian codepage?

Which one? Definetly not CP866. Maybe KOI8-U instead? :::evil grin:::

Or would cp1251 be better and less obscure?

Probably less obscure but again I wouldn't recommend it ... UTF-8 is the clear and correct choice no matter where and no matter what ... even stinkin' web based formats such as html's and other such frivolity.

Life is good,
Maurice

... Fidonet 4K - Sweet Sixteen Penguins of the Apocalypse.
--- GNU bash, version 5.1.16(1)-release (x86_64-znver2-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

Hey Pavel!

No FTS, you can just ignore this control.

It turns out that glibc supports CP1125. I never heard of it before your posts here but it doesn't surprise me any. The conversion CP1125 <-> UTF-8 appears to be working 100% so far. However I don't see any mention of it at IANA; http://www.iana.org/assignments/character-sets

For the record I am keeping your MSGs as CP1125 and only do the conversions when I quote. I *NEVER* mess with the originals and neither does any code here that I am currently using.

Що ти хочеш?

I'll be glad if the FTS about DDN could be improved or corrected.

Understood. What do you need to make it happen? I am unsure what the real problem is and throwing Russians under the bus isn't going to help ... even if they deserve it. ;-)

And the FTS about charsets too.

Unfortunetly that one might be a tad harder to pull off especially if it isn't listed at IANA. As I said previously, it is an obscure encoding, or at least it is in this part of the world and without IANA support ... ????

Life is good,
Maurice

... Fidonet 4K - Sweet Sixteen Penguins of the Apocalypse.
--- GNU bash, version 5.1.16(1)-release (x86_64-znver2-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

Hi Oli!

16 Sep 22, Oli ==> Pavel Gulchouck:

I'm not sure ic.ddn would count as a DDN record, because it's not
in the f*.n*.z*.ddn namespace. TXT records are also not covered by
FTS-5004.

FTS-5004 specifies contents of a DNS zone for being DDN. And according to
this FTS no records other than generated from the nodelist should appear
in the zone.

Is this how DNS is intended to work? The binkp client also does not care about anything that does not match *.f*.n*.z*.ddn-zone.

Nodelist also contains not only information required for call a node, but some additional info such as "U,REC" flag or even comments that are not used by fidonet mailers but may be convenient.

Alexey (author of this FTS) told that DNS zone which contains additional
information (such as IP addresses of points) is not DDN according by
FTS-5004.

Interesting. To quote FTS-5004:

P - Point Number:
If the system is a point rather than a node then
this is their point number at that node.
Optional. If ".P" is missing then assume 0 (node itself).

What is the point in mentioning points in the FTS, when there are no points in the world nodelist and everything else is forbidden? ;)

Yes, it's interesting.

May be, we can change this paragraph to something like "DDN MUST contains
all information about IP addresses from the world nodelist and MUST NOT
modify this information. DDN CAN contain information from other sources
(pointlists, fresh network segments etc) only in addition to information
from the world nodelist".

Question is: if there were multiple DDN services, would it be okay that each one could have different additional records from other
sources or should every DDN be exactly the same?

Yes.
FTS-5004 specifies strict meaning: all DDN should be equal, so they should not contain any additional data.
I do not see reasons for this limitation: many existing domains are using as DDN are not DDN by this definition because contain extra info.

Also, many sysops want to create a service that is better than others, this is the goal. They create new features for areamgr, extra statistics, robots and other stuff. Standards specify only minimal requirements, and sysop can extend it. Strict limitations for areafix commands (which forbid extensions) and other node features could kill enthusiasm in setup fidonet node. What reasons for setup one more node which are equal to all existing?
The same is for DDN. If all DDN domains should be completely equal, what reasons for create and support one more? How can sysop apply their individuality in this? I think possibility to add some pointlist or other additional information can make each DDN unique and thereby solve the problem.

Lucky carrier,
Pavel
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827
* Origin: Lucky Carrier BBS (2:463/68)

Hi Maurice!

17 Sep 22, Maurice Kinal ==> Pavel Gulchouck:

No FTS, you can just ignore this control.

It turns out that glibc supports CP1125. I never heard of it before your posts here but it doesn't surprise me any. The conversion
CP1125 <-> UTF-8 appears to be working 100% so far. However I don't see any mention of it at IANA;
http://www.iana.org/assignments/character-sets

For the record I am keeping your MSGs as CP1125 and only do the conversions when I quote. I *NEVER* mess with the originals and
neither does any code here that I am currently using.

I'll be glad if the FTS about DDN could be improved or corrected.

Understood. What do you need to make it happen?
I am unsure what the real problem is

Three problems:
1. Disable to add additional information to DDN domain (such as pointlist or fresh network segment).
2. Requirement to skip and ignore addresses like f*.n*.z2.* and any other method built from FTN address from INA when building DDN.
3. Claim that such addresses should not appear in the nodelist even if the domain is not DDN (for example, f*.n*.z*.node.binkp.net or f*n*.z2.dyn.binkp.net).

I proposed changes to the FTS in a message before.

and throwing Russians under the bus isn't going to help ... even if they deserve it. ;-)

This is not related to the technical problems.
I mentoined this only for explain source of the technical problems (as I think) caused by this FTS.

And the FTS about charsets too.

Unfortunetly that one might be a tad harder to pull off especially if it isn't listed at IANA.
As I said previously, it is an obscure encoding, or at least it is in this part of the world and without IANA support ... ????

Some codepages listed in the FTS-5003 is not listed at IANA.
For example, cp848 which is not known by glibc or IANA, and I first heard about it from this FTS.

IANA documents related to Internet.
Traditionally on unix systems for russian language before utf-8 as 8-bit encoding used koi8-r, and on dos and os/2 - cp866.
Internet was based on unix, fidonet - on dos (and later os/2). Therefore as primary encoding for russian on Internet was koi8-r, and for fidonet - cp866.
Ukrainian modification of koi8-r is koi8-u (rfc2319), and modification of cp866 is cp1125 (registered as ibm codepage).
IANA documented koi8-u in internet standard, but we in fido should document cp1125 as used in fidonet.

Lucky carrier,
Pavel
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827
* Origin: Lucky Carrier BBS (2:463/68)

Hey Pavel!

Some codepages listed in the FTS-5003 is not listed at IANA.

I know. And whoever came up with that lame idea should be forced to chew on their phoney-baloney LATIN-1 encoding for all time. :::mutter, mutter, mutter:::

For example, cp848 which is not known by glibc or IANA,

In glibc it is known as IBM848. There is no corresponding IANA listing, not even an alias.

and I first heard about it from this FTS.

Hm. I think that should be indicative that something is horribly wrong. Most of the official MSGs coming from that direction appear to be CP866.

IANA documented koi8-u in internet standard, but we in fido
should document cp1125 as used in fidonet.

You are more than likely the best person for that task. For what it's worth I can offer my assistance in the way of proving that it is doable. I still think a proper IANA aknowledgement would have helped.

As far as I can tell the glibc cp1125 is valid although a proper mapping could be generated just to make sure ... if it ever comes to that. I have doubts but then again I don't live or operate from there so what the hell do I know about it.

Life is good,
Maurice

... Fidonet 4K - Sweet Sixteen Penguins of the Apocalypse.
--- GNU bash, version 5.1.16(1)-release (x86_64-znver2-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

Hi, Pavel!

16 ᥭ 22 18:39, Pavel Gulchouck -> Oli:

Good point, I agree, the problem exists. Thank you.
I think I should periodically check if address specified in the node.binkp.net and ddn.binkp.net accessible by binkp protocol, and if not during some period (week or two) then remove the address and notify sysop about it. It's not hard to implement.

Will there be support for IPv6 only nodes? How do you plan to determine when there is no binkp connection just for you, and when there is no answer at all at this address? I mean the case when there are currently fashionable IP restrictions.

Have nice nights.
Stas Mishchenkov.

--- ÅÑαóδ¼ »α¿º¡á¬«¼ ú½π»«ßΓ¿ ∩ó½∩ÑΓß∩ »«½¡«Ñ «ΓßπΓßΓó¿Ñ ßΓδñá. ç.öαÑ⌐ñ.
* Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)

Hi,

following the latest charset discussion, it came to my mind that it might be a nice idea, to promote the transition from legacy charsets to UTF-8 by editors automatically changing to charset on reply to UTF-8 for areas where UTF-8 seems to be acceptable. The idea is that this way to some extent tools with broad charset support convert the resulting threads at least partially for everybody else as long as UTF-8 support is not an issue for the readers.

Technically, the idea is to have a "preferred charset" setting per area and do the automatic transition only for messages where the destination area has this preference set to UTF-8. In some packages (like WP), this is probably a single line of code. For areas, where the audience is likely to use tools that cannot handle UTF-8, the area default may be set to something else (e.g., IBMPC) and no automatich charset change will happen. Currently, WP maintains the original message charset in replys (if it is supported by WP).

What do you think?

Best,
Tim
--- WinPoint 412.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

On 19 Sep 22 11:46:20, Tim Schattkowsky said the following to All:

following the latest charset discussion, it came to my mind that it might b nice idea, to promote the transition from legacy charsets to UTF-8 by edito automatically changing to charset on reply to UTF-8 for areas where UTF-8 seems to be acceptable. The idea is that this way to some extent tools with broad charset support convert the resulting threads at least partially for everybody else as long as UTF-8 support is not an issue for the readers.

Sounds good, but thats not an FTSC matter.

Nick

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

Hello Tim,

On Monday September 19 2022 11:46, you wrote to All:

following the latest charset discussion, it came to my mind that it
might be a nice idea, to promote the transition from legacy charsets
to UTF-8 by editors automatically changing to charset on reply to
UTF-8 for areas where UTF-8 seems to be acceptable.

I already have it configured like that for this area for a decade or so.

What do you think?

Good idea.

destination area has this preference set to UTF-8. In some packages
(like WP), this is probably a single line of code. For areas, where
the audience is likely to use tools that cannot handle UTF-8, the area default may be set to something else (e.g., IBMPC)

IBMPC is not a good idea as it is documented as obsolete, deprecated and ambiguous. It MUST NOT be used when creating new messages.

5. Obsolete indentifiers
------------------------

These indentifiers must not be used when creating new messages.
The following only applies to processing messages that were
created using old software.

Since the "IBMPC" identifier, initially used to indicate IBM
codepage 437, eventually evolved into identifying "any IBM
codepage", there exists in some implementations an additional
control line, "CODEPAGE", identifying the messages codepage:

"^ACODEPAGE: xxx

This use is deprecated in favour of the "CPxxx" identifiers
defined above. If found in incoming messages, however, it should
be used as an override of the "CHRS: IBMPC" identifier.



Cheers, Michiel

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

following the latest charset discussion, it came to my mind that it
might be a nice idea, to promote the transition from legacy charsets to UTF-8 by editors automatically changing to charset on reply to UTF-8 for areas where UTF-8 seems to be acceptable. The idea is that this way to some extent tools with broad charset support convert the resulting
threads at least partially for everybody else as long as UTF-8 support
is not an issue for the readers.

Excellent idea. But it's not really an FTSC matter. It's an FTN editor of your choice matter. My editor (I think it's shown below) has worked like that for 15+ years now. It's all about accepting the fact that some editors from the last century may not be worth clinging on to any more.


--
United we are strong, we win. Divided we are weak, we lose.

..

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

//Hello Bjoern,//

on *19.09.2022* at *13:17:44* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Automatically promote UTF-8 in editors?"*.

following the latest charset discussion, it came to my mind that it
might be a nice idea, to promote the transition from legacy charsets to
UTF-8 by editors automatically changing to charset on reply to UTF-8 for
areas where UTF-8 seems to be acceptable. The idea is that this way to
some extent tools with broad charset support convert the resulting
threads at least partially for everybody else as long as UTF-8 support
is not an issue for the readers.

Excellent idea. But it's not really an FTSC matter.

Fully agree. I just wanted some qualified opinions :)

Regards,
Tim

--- WinPoint 412.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

//Hello Michiel,//

on *19.09.2022* at *12:45:06* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Automatically promote UTF-8 in editors?"*.

What do you think?

MvdV> Good idea.

:)

destination area has this preference set to UTF-8. In some packages
(like WP), this is probably a single line of code. For areas, where the
audience is likely to use tools that cannot handle UTF-8, the area
default may be set to something else (e.g., IBMPC)

MvdV> IBMPC is not a good idea as it is documented as obsolete, deprecated
MvdV> and ambiguous. It MUST NOT be used when creating new messages.

I know.

Regards,
Tim

--- WinPoint 412.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hey Stas!

trans -b -no-ansi -s russian -t english "ÅÑαóδ¼ »α¿º¡á¬«¼ ú½π»«ßΓ¿ ∩ó½∩ÑΓß∩ »«½¡«Ñ «ΓßπΓßΓó¿Ñ ßΓδñá. ç.öαÑ⌐ñ."
The first sign of stupidity is the complete absence of shame. Z. Freud.

Personally I prefer;

trans -b -no-ansi -s english -t russian "Strong like bull, smart like tractor."
濽∞¡δ⌐ ¬á¬ íδ¬, ½«ó¬¿⌐ ¬á¬ Γαá¬Γ«α.

Not quite the same meaning but it works for me and provides me the opportunity to test utf8 <-> cp866. Thank you.

Life is good,
Maurice

... Fidonet 4K - Sweet Sixteen Penguins of the Apocalypse.
--- GNU bash, version 5.1.16(1)-release (x86_64-znver2-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

Hey Tim!

Currently, WP maintains the original message charset in replys (if it is supported by WP).

I seriously doubt that will work without restricting utf8 capable editors to a single 8-bit character set supported by whatever WP thinks is the correct one. Speaking of which what does WP think LATIN-1 *REALLY* is. I have yet to get a proper answer to this query.

Life is good,
Maurice

... Fidonet 4K - Sweet Sixteen Penguins of the Apocalypse.
--- GNU bash, version 5.1.16(1)-release (x86_64-znver2-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

//Hello Maurice,//

on *22.09.22* at *18:15:05* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Automatically promote UTF-8 in editors?"*.

I seriously doubt that will work without restricting utf8 capable editors to a single 8-bit character set supported by whatever WP thinks is the correct one. Speaking of which what does WP think LATIN-1 REALLY is. I have yet to get a proper answer to this query.

What are you trying to say and what query are you referring to?

Regards,
Tim

--- WinPoint 412.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hey Tim!

Speaking of which what does WP think LATIN-1 REALLY is. I have
yet to get a proper answer to this query.

What are you trying to say and what query are you referring to?

I was asking you what does WP think LATIN-1 REALLY is as shown above in the MK>> part.

Life is good,
Maurice

... Weorða ðe selfne godum dædum, ðenden ðin God recce.
Bring honour to yourself with good deeds, while God guides you.
--- GNU bash, version 5.1.16(1)-release (x86_64-lilmikii-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

//Hello Maurice,//

on *23.09.22* at *18:48:47* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Automatically promote UTF-8 in editors?"*.

I was asking you what does WP think LATIN-1 REALLY is as shown above in

ISO 8859-1

But the question somehow implies there is something interesting there ...

Regards,
Tim

--- WinPoint 412.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hey Tim!

ISO 8859-1

I was guessing you'd say that. Care to find a credible source that LATIN-1 is indeed an alias for ISO 8859-1? All my searches thus far show no such alias as LATIN-1 for anything, nevermind 8859-1. However there used to be an entry on iana that credited to win-3.11 which I found curious and could not find any other reference to this. If I can track it down again I will make a note of it just in case someone wants to know.

But the question somehow implies there is something interesting

Deepends on what you find interesting. Bottomline is that many say ISO 8859-1 but are actually delivering cp1252.

For the record, both iana and glibc claim LATIN1 is the correct alias for ISO 8859-1 as well as many, many other sources including at least one MS based site.

Interesting? I don't think so but if there is good reason to drop LATIN-1 then officially it should be done. There is too big a difference between ISO 8859-1 and CP1252 to continue ignoring this.

Life is good,
Maurice

... Heald hordlocan, hyge fæste bind mid modsefan.
Hold close the treasure-chest, bind your thoughts fast within the heart. --- GNU bash, version 5.1.16(1)-release (x86_64-lilmikii-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

//Hello Maurice,//

on *23.09.2022* at *21:27:08* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Automatically promote UTF-8 in editors?"*.

Hey Tim!

ISO 8859-1

I was guessing you'd say that. Care to find a credible source that LATIN-1 is indeed an alias for ISO 8859-1? All my searches thus far show no such alias as LATIN-1 for anything, nevermind 8859-1. However there used to be an entry on iana that credited to win-3.11 which I found curious and could not find any other reference to this. If I can track
it down again I will make a note of it just in case someone wants to
know.

I never noticed any lack of information in this regard.

Regards,
Tim

--- WinPoint 412.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

//Hello Maurice,//

on *23.09.2022* at *22:52:29* *Tim Schattkowsky* wrote in area *FTSC_PUBLIC*
to *you* about *"Re: Automatically promote UTF-8 in editors?"*:

Hello Maurice,

on 23.09.2022 at 21:27:08 You wrote in Area FTSC_PUBLIC to Tim Schattkowsky about "Automatically promote UTF-8 in editors?".

Hey Tim!

ISO 8859-1

I was guessing you'd say that. Care to find a credible source that
LATIN-1 is indeed an alias for ISO 8859-1? All my searches thus far
show no such alias as LATIN-1 for anything, nevermind 8859-1. However
there used to be an entry on iana that credited to win-3.11 which I
found curious and could not find any other reference to this. If I can
track it down again I will make a note of it just in case someone wants
to know.

I never noticed any lack of information in this regard.

I might add, that if you have any doubt, you may compare them one character at a time ;)

Regards,
Tim
--- WinPoint 412.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

//Hello Maurice,//

on *23.09.2022* at *21:27:08* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Automatically promote UTF-8 in editors?"*.

Interesting? I don't think so but if there is good reason to drop
LATIN-1 then officially it should be done. There is too big a difference between ISO 8859-1 and CP1252 to continue ignoring this.

I am not aware of anybody notable claiming CP1252 equals LATIN-1 ... because it does not. Some software messes things like this up, but that is simply a software defect.

Regards,
Tim

--- WinPoint 412.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hey Tim!

I am not aware of anybody notable claiming CP1252 equals LATIN-1

I am unsure of what "notable" means to you. A quick check of both iana and glibc doesn't yeild anything for LATIN-1. Both show LATIN1 as a valid alias for ISO-8859-1.

... because it does not.

Agreed.

Some software messes things like this up, but that is simply a
software defect.

Yes. I suggest we avoid those mess ups and a good place to start would to be giving LATIN-1 the heave-ho.

Life is good,
Maurice

... Feoh byþ frofur fira gehwylcum, sceal ðeah man... hyt dælan.
Wealth is a comfort to every man; but one should give it away.
--- GNU bash, version 5.1.16(1)-release (x86_64-lilmikii-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)