[DNSOP] Re: New I-D: Transparent Handling of IDNs in Name Resolution APIs (draft-rodenhaeuser-idna-transparent-resolution -00)

I posted this draft on 20 July, during IETF 126, and it drew no
discussion. Following a suggestion from the WG secretary, I would like
to ask explicitly: is this work of interest to the group, and if not,
what are the concerns?

  draft-rodenhaeuser-idna-transparent-resolution-00
  https://datatracker.ietf.org/doc/draft-rodenhaeuser-idna-transparent-resolution/

To make the problem concrete, here is something anyone with two Linux
machines can reproduce. Both invocations request UTS #46 nontransitional
processing explicitly; the systems differ only in the version of libidn2
they ship:

  # Ubuntu 24.04 LTS, libidn2 2.3.7
  $ idn2 -N STRAẞE.de
  strasse.de

  # Ubuntu 26, libidn2 2.3.8
  $ idn2 -N STRAẞE.de
  xn--strae-oqa.de

  # both systems agree here
  $ idn2 -N straße.de
  xn--strae-oqa.de

libidn2 2.3.8 (March 2025) picked up the Unicode 15.1 tables, in which
the mapping of U+1E9E changed from "ss" to U+00DF. So on current tables
the lowercase and uppercase spellings of the same word converge on one
domain, and on older ones they diverge. These are two independently
registrable domains -- .de applies first-come-first-served to "ß" names,
with no bundling requirement. Both Ubuntu releases above are supported
today, and glibc's AI_IDN path uses this library.

The same divergence exists across other stacks: Appendix A of the draft
records what Windows, .NET, Apple's libc, WebKit, systemd-resolved and
Go actually do. It crosses layers within a single runtime and within a
single vendor.

The draft's proposal is that name resolution services accept Unicode by
default and convert once, at the point where a name is handed to a
specific protocol -- UTS #46 nontransitional, Unicode 15.1 table floor,
wire format unchanged. RFC 6055 recommended exactly this placement in
2011; Windows, systemd-resolved and the browser platforms already
convert by default. The draft aims to codify that as a BCP.

Specific questions I would value answers to:

  1. Is the placement of the conversion (resolver rather than
     application) something this group considers its business, or does
     it belong elsewhere?
  2. Is the table-version skew above a real operational concern, or is
     it too marginal to standardise around?
  3. Does the private-namespace accommodation in Section 6.3 conflict
     with current operational practice?

Frank negative answers are just as useful to me as positive ones.

Thank you,
Luca Rodenhäuser

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]