Net::ID...tandards(3)

🌸 Net::IDN::Standards πŸ’…

okay so real talk bestie, this is a page from the User Contributed Perl Documentation, and the whole thing lives under the name Net::IDN::Standards(3) ✨ β€” it's literally the lore drop for Internationalized Domain Names for Applications, aka IDNA πŸŽ€


πŸ‘‘ NAME

Net::IDN::Standards β€” Internationalized Domain Names for Applications (IDNA) πŸ’–


🌈 INTRODUCTION

so back in the day, domain names and host names were stuck in a tiny ASCII-only world 😭 they were restricted to a limited repertoire of ASCII characters, i.e. letters, digits and the hyphen β€” literally just /[A-Z0-9-]/i β€” which meant any word or name from a language that needs extra characters (like diacritics, or just, y'know, special characters) or that uses a different script was simply not allowed. rude, honestly. πŸ™ˆ

Internationalized Domain Names (IDNs) fixed this by extending the character repertoire for domain names from ASCII to Unicode, while maintaining backwards compatibility with software that only expects and handles ASCII characters. iconic behavior. πŸ’…

and how do they pull that off? Unicode domain names get converted to ASCII using an ASCII-compatible encoding (ACE) called Punycode ✨ on the wire, converted domain names start with xn--, followed by the ASCII encoding of the Unicode string. so the Unicode version is typically only shown in applications presenting the domain to the user β€” which is literally where the "for Applications" part of IDNA comes from, iykyk 🌸 and Internationalized Resource Identifiers (IRIs) β€” the Unicode version of URLs β€” may also include domain names in their Unicode form.

but wait, there's more, because the IDNA specs do not just cover the actual Punycode conversion 🫢 they also include extensive rules for preparation (mapping and/or validation) of input strings. they typically define two functions, ToASCII and ToUnicode, which prepare and convert a domain name to the ACE version or the Unicode version. two little functions running the whole show, main character energy fr fr πŸ’œ


⭐ DIFFERENT STANDARDS

"The nice thing about standards is that you have so many to choose from." β€” Andrew S. Tanenbaum

not him calling us out πŸ’€ but okay. while the actual Punycode conversion is stable, there are different specifications regarding mapping and/or validation (preparation). buckle up:

πŸ¦‹ IDNA2003

IDNA2003, which is defined in RFC 3490 (<http://tools.ietf.org/html/rfc3490>) and related documents, was the original specification for the internationalization of domain names. the blueprint. the blueprint that had some issues. 😭

some issues were subsequently identified with IDNA2003:

  • the specification was tied to Unicode 3.2 and therefore did not allow characters added in newer versions of Unicode (without updating the specifications). trapped in time fr.
  • furthermore, a few characters were mapped to other characters or deleted although they would carry meaning in some languages β€” i.e. 'ß' and 'Ο‚' were mapped to 'ss' and 'Οƒ'; and ZWJ and ZWNJ were always mapped to nothing, although some scripts like Arabic require them for correct display. not them erasing a whole vibe 😀

🧚 IDNA2008

IDNA2008, which is defined in RFC 5890 (<http://tools.ietf.org/html/rfc5890>) and related documents, resolves the issues found in IDNA2003. glow-up complete ✨

this was done by allowing some characters that would either be mapped to other characters, mapped to zero and/or cause the preparation to fail. the new domain names would not be accessible by IDNA2003 implementations, of course. (they're just not on the same wavelength anymore πŸ’€)

however β€” and this is the part where we hold hands 🫢 β€” IDNA2008 also disallowed a large number of characters that had been allowed in IDNA2003 (mostly symbols). an implementation of IDNA2008 would therefore no longer be able to access domain names such as √.com, which had been registered under IDNA2003. rip to a real one 😭

πŸŽ€ UTS #46

Unicode Technical Standard #46 (UTS #46, <http://unicode.org/reports/tr46/>) solves this problem by allowing domain names that are valid in either IDNA2003 or IDNA2008. best of both worlds, we love a diplomat πŸ‘‘

this makes UTS #46 the perfect fit for domain lookup (be liberal in what you accept) but unsuitable for validating domain names prior to registration (be conservative in what you send). so bestie: slay for lookups, absolutely not for validating before you register, periodt. ⚠️


πŸ’Œ AUTHOR

Claus FΓ€rber <CFAERBER@cpan.org>

currently maintained by Robert Rothenberg <perl@rhizomnic.com> and Paul Johnson <paul@pjcj.net>. give them their flowers πŸŒΈπŸ’


this has been perl v5.44.0, dated 2026-10-30, signing off from the Net::IDN::Standards(3) page β€” mwah, ily, go register a domain responsibly πŸ’œ

πŸ“¦ where this page comes from