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.
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?
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.
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.
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.
@CHRS: CP1125 2
* Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68)
Що ти хочеш?
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.
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.
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".
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.
Hey Pavel!
@CHRS: CP1125 2
Which FTS supports the above encoding?
It is perfectly all right for an implementation to only have
partial support.
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.
@CHRS: CP1125 2
Which FTS supports the above encoding?
?
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.
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?
No FTS, you can just ignore this control.
Що ти хочеш?
I'll be glad if the FTS about DDN could be improved or corrected.
And the FTS about charsets too.
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.
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? ;)
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?
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 ... ????
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 documented koi8-u in internet standard, but we in fido
should document cp1125 as used in fidonet.
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.
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.
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.
What do you think?
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)
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.
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.
What do you think?
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)
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.
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?
ISO 8859-1
But the question somehow implies there is something interesting
I was asking you what does WP think LATIN-1 REALLY is as shown above in
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 369 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 96:44:01 |
| Calls: | 7,897 |
| Files: | 12,968 |
| Messages: | 5,793,330 |