I do not want to continue this discussion with you, Andrew. It seems you
have switched to personal attack at me, instead of constructive
discussion about how to make it working.
I am software engineer only, not someone paid to read and study IETF
drafts, learn terminology of very different topics and then make some
proposals. Yes, I am aware my knowledge is not perfect. But I would
expect more inclusive environment at IETF. Is it common to shame
newcomers, because they have not spent dozens of years before they dare
to make some suggestion? Is that written in dnsop charter? I admit I did
not study that in detail, but would be very surprised to find something
there.
I do not like the way you react to me. How are you looking for my lack
of precise terminology instead of helping me to define it how it should
be. Are you shaming me for a reason?
On 25/11/2025 02:10, Andrew Sullivan wrote:
Hi,
On Tue, Nov 25, 2025 at 01:40:46AM -0500, Petr Menšík wrote:
Python3 says ZWJ is not printable.
Mmmmm. And yet, if you don't render it when you are dealing with a
stream of octets that represent UTF-8 encoded Unicode characters, when
the string in question requires a ZWJ, then the join is elided and the
resulting string doesn't render correctly.
I am not unicode specialist. I do not know all unicode characters and
how they are used in different languages. I do not think it is needed to
be involved in a discussion, why only ASCII characters are considered
printable now.
These definitions are corner cases.
The ZWJ is a corner case to you because your particular writing system
doesn't use it. It seems to me elsewhere in this thread you have
accused people of not caring about those whose first language isn't US
English as the reason why anyone could be opposed to your suggestion
to modify, without any kind of versioning control, the semantics of
zone file entries. But if you can't even be bothered to understand
_why_ the question I asked was one that has some consequences for your
position, I submit that it is you who is ignoring the issues related
to at least some non-ASCII-using writing systems.
It is up to higher layers to render text. That is job of GUI
toolkits, terminal emulators and similar.
Great. So what problem is it you're trying to solve by insisting on
an interpretation of the octets that come through from a zone? Surely,
whatever else is the case, we can agree that DNS zone files are some
distance off from the "higher layers", GUI toolkits, and so on?
I only insist that UTF-8 encoded text is a text, not random binary
content, which should be displayed in base64. How to choose set of
forbidden unicode characters can be discussed once we agree some unicode
characters can be rendered as text.
I think in native code iswprint() should be used to guess
So now you want to make all of these decisions subject to whatever
biases are implicit in some programming language's design?
I am proposing concrete way to solve it. In a safe way in my opinion.
Sure, there might be better set. Very likely libidn2 contains already
something similar and could be reused. If we discuss
PRECIS or RFC 9839 is an implementation detail.
Perhaps, but the fact that you need one of these things to specify
your subset is _not_ a detail, but a fundamental issue.
Yes, agreed on that. I do not care which standard is used as long as it
uses unicode.
utf-8 encoded text as a normal text. If a domain name can contain
socks icon, why not a TXT record? Why are no emoticons rendered?
Emojis are not good identifiers because there is no conceptual
character behind them. The UTC is _usually_ crystal clear about this.
Not sure what are you referring to.
URI can have normalized form of only A-label input with percent
encoded path characters in URI.
The above suggests to me that you don't know what an A-label is, either.
I know there is ascii only form of a hostname and locale
Frankly, I don't know why I am bothering to continue to pursue this
discussion, since you seem completely immune to the suggestion that
perhaps the topic is rather more complicated than you appear to think,
and that knowing even a little bit about it before pontificating about
the obvious right solution might help make your position a little bit
more defensible. It doesn't especially matter to me anyway: I'm not
really an active participant in the IETF these days, and I've no
reason to suppose that will change. But your proposal is, to be
blunt, uninformed codswallop, and I urge you to go learn some things
about the topic of writing systems before proposing again something
with a bunch of hand-waving about how trivial it is.
Best regards,
A
Yes, thank you for suggesting I am too stupid to be involved in this
discussion. However there were no-one smarter leading the subject and I
tried. Instead of constructive discussion I am avoiding personal
attacks. I am not sure if my english grammar mistakes are triggering
you. Yes, I am not seasoned IETF member with a bunch of drafts
transformed into published RFC.
But I do not want to continue this fight. This is the most discouraging
discussion I have met at IETF. I am still convinced DNS utilities should
be able to present UTF-8 text and failed to see a good arguments why it
is a bad idea. But I am tired of this fight, so I stop.
Regards,
Petr
--
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
