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]
