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

On Aug 12, 2026, Paul Hoffman wrote:
> My secondary concern is that you are tying this to a static version of
> the Unicode Standard.

Thank you -- this is the first substantive feedback I have had, and it is
useful. Taking your points in reverse order.

On the Unicode version: the draft does not pin one. Section 4.3.1 sets a
floor ("15.1 or later") and a SHOULD to track the current version,
following the process of RFC 8753. If your concern is the normative
reference to UTS #46 Revision 35, that is a fair hit and I am happy to
make it version-flexible.

On IETF agreement: you are right, and I should fix the wording. What I
intended to claim is convergence among implementations -- which is
empirical and checkable -- not consensus in the IETF IDN community, which
plainly does not exist. If the text reads as claiming the latter, that is
a defect. I would genuinely value your view on what the live positions
are, since I clearly underestimated the disagreement.

On the new requirement: could you say whether your objection is to
default-on specifically, or to any normative requirement at this layer
twenty years in? Nothing in the draft invalidates existing behaviour --
ASCII input, including pre-converted A-labels, takes an untouched fast
path -- but that is a compatibility argument, not an answer to the
process question you are raising. The narrower claim (if a resolver
converts, it should do so uniformly) may be separable from the broader
one, and knowing which part you object to would tell me whether there is
a viable document here at all.

Thank you,
Luca Rodenhäuser

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