Summary

  • RFC 3490 left DNS in ASCII and inserted IDNA inside applications. ToASCII could reject a label; ToUnicode deliberately never failed and returned the original input if decoding or its round-trip test failed.
  • The returned display string was therefore not proof of a valid label, registry acceptance, zone insertion, resolution, DNSSEC authentication or control. Each belonged to a different layer and required its own receipt.

The most revealing sentence in RFC 3490 was not about a new alphabet. It was about failure: “ToUnicode never fails.” Read casually, that sounds like a promise of universal understanding. Read as an algorithm, it means something narrower. When a conversion step failed, the operation returned the original input immediately. The application still had something to show. It did not thereby have a valid internationalized domain name.

That behavior made sense because the 2003 design was a bridge, not a renovation of DNS. RFC 3490 did not add Unicode to DNS packets or require new name servers. It put a shim inside the application. On the human side, an application could accept or display Unicode. On the infrastructure side, old resolver interfaces, zone files and DNS servers continued to carry ASCII labels. Internationalization happened at the seam.

The standard named the places where that seam mattered “domain name slots”: a DNS QNAME, a resolver function argument, the domain after an at-sign in a mail header, or the host part of a URI field. Prose that merely mentioned a name was not automatically a slot. This was already a discipline of scope. A string's meaning depended on where it was being used, not merely on how it looked.

The path toward DNS was strict. ToASCII worked one label at a time. For non-ASCII input it invoked Nameprep, could enforce the old letter-digit-hyphen restrictions, rejected a non-ASCII sequence that already began with the reserved prefix, encoded with Punycode, added xn--, and required a final length between one and 63 code points. Any failed step meant failure. If any label failed, RFC 3490 said the domain name must not be used as an IDN.

The return path toward the person had a different job. ToUnicode first recognized the ACE prefix, removed it, decoded the remainder, then sent the result back through ToASCII. Only if the newly generated ASCII label matched the saved input, without regard to ASCII case, did it expose the decoded Unicode form. That round trip prevented an arbitrary prefix-shaped string from acquiring authority merely because Punycode produced some characters.

But display software could not simply disappear when the check failed. So ToUnicode returned the original label. RFC 3490 added the operational clue: if a label still began with the ACE prefix after ToUnicode, it was not a valid ACE label and was not equivalent to the intermediate Unicode string. “Returned” meant that the display path had a safe fallback. It did not mean “accepted.”

This creates a ladder of evidence that modern interfaces often flatten. A string may be renderable. It may pass ToASCII. A registry may accept it under stricter language and script policy. Its A-label may be inserted into a zone. A resolver may receive an answer. DNSSEC may authenticate that answer. A user may recognize the rendered name as the party intended. None of those facts automatically supplies the next one.

RFC 3490 was explicit about one of the sharpest boundaries. DNSSEC authenticated the ASCII domain name stored and signed in DNS, not the Unicode form and not the mapping between the two. Even a cryptographically valid DNS answer could not certify what a human believed a displayed spelling meant. Exact protocol identity and perceived identity occupied different layers.

The standard also refused a broader linguistic promise. Unicode enlarged the repertoire, but DNS remained an exact-match service. Similar-looking code points, alternative spellings, traditional and simplified Chinese forms, and language-specific equivalences were not all merged. A registry could impose additional rules. Conversion was an interoperability mechanism, not a universal theory of names.

The later IDNA2008 work sharpened this separation. RFC 5890 and RFC 5891 replaced RFC 3490's vocabulary with A-labels and U-labels and described registration and lookup as separate protocols. Registration could demand exact agreement between the submitted forms and reject a mismatch. Lookup was more permissive, yet still had validation rules. RFC 5891 stated the principle with useful bluntness: successful comparison did not imply validity.

RFC 5895 moved user-interface mapping into local handling before the shared protocol. That change echoes Heng Lu's minimum-initial-specification rule. The common mechanism should carry only what interoperability needs; language-sensitive input, presentation and policy decisions remain near the people and institutions that can judge them. The DNS core need not become a global linguistic authority in order to carry a globally usable identifier.

The historical achievement of RFC 3490 was therefore not that every name could become readable. It was that the standard preserved old infrastructure while marking the boundary between two representations. Its quiet warning survives the mechanism that was later replaced: a function that always returns can be excellent for continuity and terrible as a validity oracle. Readable text is evidence of display. Acceptance needs another receipt.

Sources