RFC 4185

National and Local Characters for DNS Top Level Domain (TLD) Names

📅 published October 2005, from ietf

RFC 4185: National and Local Characters for DNS Top Level Domain (TLD) Names 🎀

okay bestie, RFC 4185 was written by J. Klensin and published in October 2005 🌸 It's an Informational doc, which means it's giving "here's some info for the community" and not an Internet standard. It doesn't obsolete or update any other RFCs, because its title block doesn't list any. 🫶

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2005).

IESG Note 🙈

ok so this RFC is not a candidate for any level of Internet Standard 💀 The IETF disclaims any knowledge of how fit this RFC is for any purpose, and it notes that the decision to publish wasn't based on IETF review, apart from IESG review for conflict with IETF work. The RFC Editor chose to publish this document at its own discretion. For more, check out RFC 3932 [RFC3932].

Abstract 🦋

Okay, so picture this: while people were working on internationalizing the Domain Name System (DNS), there were LOTS of chats about "multilingual" or "internationalized" top level domain names (TLDs) 🌈 Especially for countries whose main language isn't written in a Roman-based script. This document walks through some of the reasons people want these domains, a few suggestions that have been made to make them work, and the limits the DNS puts on everything. 🧚 Then it suggests an alternative, local translation, which might solve a bigger version of the problem without needing protocol changes, long deployment delays, or other headaches ✨ The idea is to use a localization technique inside applications so that any TLD can be reached using the vocabulary and characters of any language. It isn't limited to "multilingual" TLDs that are tied to one country's language(s) and script(s) 👑

Table of Contents 🍓

1. Introduction ....................................................3
   1.1. Terminology ................................................3
   1.2. Background on the "Multilingual Name" Problem ..............3
        1.2.1. Approaches to the Requirement .......................3
        1.2.2. Writing the Name of One's Country in its Own
               Characters ..........................................4
        1.2.3. Countries with Multiple Languages and
               Countries with Multiple .............................5
        1.2.4. Availability of Non-ASCII Characters in Programs ....5
   1.3. Domain Name System Constraints .............................6
        1.3.1. Administrative Hierarchy ............................6
        1.3.2. Aliases .............................................6
   1.4. Internationalization and Localization ......................7
2. Client-Side Solutions ...........................................7
   2.1. IDNA and the Client ........................................8
   2.2. Local Translation Tables for TLD Names .....................8
3. Advantages and Disadvantages of Local Translation ...............9
   3.1. Every TLD Appears in the Local Language and Character Set ..9
   3.2. Unification of Country Code Domains .......................10
   3.3. User Understanding of Local and Global References .........11
   3.4. Limits on Expansion of the Number of TLDs .................11
   3.5. Standardization of the Translations .......................12
   3.6. Implications for Future New Domain Names ..................13
   3.7. Mapping for TLDs, Not Domain Names or Keywords ............13
4. Information Interchange, IDNs, Comparisons, and Translations ...13
5. Internationalization Considerations ............................15
6. Security Considerations ........................................15
7. Acknowledgements ...............................................16
8. Informative References .........................................17

1. Introduction ✨

1.1. Terminology 💅

This document assumes the conventional terminology used to discuss the domain name system (DNS) and its hierarchical arrangements. Terms such as "top level domain" (or just "TLD"), "subdomain", "subtree", and "zone file" are used without further explanation. 🧠 On top of that, the term "ccTLD" is used to denote a "country code top level domain", and "gTLD" is used to denote a "generic top level domain", as described in [RFC1591] and in common usage.

1.2. Background on the "Multilingual Name" Problem 🌸

People who share a language usually prefer to talk in it, using whatever characters are normally used to write that language, instead of in some "foreign" one 🫶 Standards for using agreed-upon characters and languages in electronic mail message bodies and selected headers have existed since MIME came out in 1992 [MIME], and the Web has supported multilingual text since its very beginning, also using MIME. Non-Roman-character content was actually around even earlier, using private conventions 🙈 The catch is that domain names are shown to users in email addresses and URLs. Other application protocols do similar things, typically exposing domain names too. Put exposed domain names together with internationalization requirements, and people quickly started demanding domain names in applications that used characters other than the super restrictive, ASCII-subset "hostname" conventions (also called "letter-digit-hyphen" or "LDH") recommended in the DNS specifications [RFC1035] 😭 The effort to do this soon became known as "multilingual domain names". That was honestly a misnomer 💀 The DNS only deals with characters and identifier strings, not what people usually think of as "names", except by accident or through local registration conventions. There's also been little interest in a true "multilingual name", meaning a name that contains components from more than one language. Instead, the focus has been on using strings in the DNS that conform to specific individual languages 🎀

1.2.1. Approaches to the Requirement 🦋

Once people saw the requirement not as "modifying the DNS" but as "giving users access to the DNS from a variety of languages and character sets", three sets of proposals came up in the IETF and elsewhere 👑 They were:

  1. Do processing in client software that recodes a user-visible string into an ASCII-compatible form. That form can safely go through DNS protocols and be stored in the DNS. This is the approach used, for example, in the IETF's "IDNA" protocol [RFC3490] ✨
  2. Modify the DNS to be more welcoming to non-ASCII names and strings. There have been a bunch of proposals for this, using several different techniques. Some have been implemented on a proprietary basis by various vendors, but none of them have gained acceptance in the IETF community 😭 That's mainly because they would take a long time to deploy, would leave many problems unsolved, and have been shown to cause problems with deployed approaches that hadn't been upgraded yet.
  3. Move the problem out of the DNS entirely, relying instead on a "directory" or "presentation" layer to handle internationalization 🧚 The reasoning behind this approach is discussed in [RFC3467].

This document proposes a fourth approach 💖 It only applies to the top level domains (TLDs) (see Section 1.3.1 for a discussion of the special issues that make TLDs both problematic and a special opportunity). This approach has the user interface of applications map non-ASCII names for TLDs to existing TLDs. It could be used as an alternate or as a supplement to the strategies summarized above 🌈

1.2.2. Writing the Name of One's Country in its Own Characters 🇨🇳

An early focus of the "multilingual domain name" efforts was captured in statements like "users in my country, in which ASCII is rarely used, should be able to write an entire domain name in their own character set" 🥹 Here's the tea: since all top-level domain names, right now, follow the LDH rules, the modified naming rules discussed in [RFC1123], and the coding conventions specified in [RFC1591], every fully-qualified DNS name was effectively required to contain at least one ASCII label (the TLD name). Some advocates for internationalized names have considered the presence of any ASCII labels inappropriate. The vision is that you should be able to write the name of the ccTLD for China in Chinese, the name of the ccTLD for Saudi Arabia in Arabic, the name for Spain in Spanish, and so on 🍓

That much could be done, given updated applications, by using a new TLD name with IDNA encoding. Of course, adding a TLD like that would raise new questions 🤔 What do you do about gTLDs? How do you handle countries with several official languages (maybe even using different scripts)? How should name strings be chosen? And should there be an attempt to coordinate the contents of the local-language TLD zone with the traditional ISO 3166-coded one? A few of these issues get addressed below. But if you look at (or even just think about) user behavior and preferences, it's almost just as important to be able to write the name of the ccTLD for China in Arabic, and that of Saudi Arabia in Chinese. True internationalization means that, at least as far as ambiguity and conflicts can be avoided, people should be able to use the languages and character sets they prefer 💅 For the same reasons you'd want all-Chinese domain names available in China, it matters to be able to have an apparent Chinese-language TLD for a domain whose second level and beyond are Chinese characters, even when the TLD itself serves mostly non-Chinese-speaking registrants and users 🫶

1.2.3. Countries with Multiple Languages and Countries with Multiple Names 🌍

From a user interface standpoint, writing ccTLD names in local characters is a real problem 😩 As discussed below in Section 1.3.2, the DNS itself doesn't easily let a domain be referred to by more than one name (or spelling or translation of a name). Countries with more than one official language would need the country name represented in each of those languages. And just as it's important for a user in China to be able to write the name of the Chinese ccTLD in Chinese characters, she should be able to access a Chinese-language site in France using Chinese characters too. That would require her to write the name of the French ccTLD in Chinese characters, rather than in a form based on a Roman character set ✨

1.2.4. Availability of Non-ASCII Characters in Programs 🖥️

Over the years, computer users have gotten used to the fact that not every computer has a full set of characters available to every program 🙃 An extreme example is an Arabic speaker using a public kiosk computer in a United States airport. There's only a small chance the web browser there will be able to input and render Arabic correctly 💀 This matters for the multilingual TLD problem, because you can't just switch a ccTLD in the DNS over to one of a given country's non-ASCII names without possibly stopping people all over the world from entering that name 😭

Next up is 1.3. Domain Name System Constraints, so stay tuned, bestie 🦋💖

1.3.1. Administrative Hierarchy 🌳

okay bestie, so the DNS is built on this idea called an "administrative hierarchy" 👑. The entity in charge of a given node is responsible for the policies that apply to everything underneath it (Cf. [RFC1034], [RFC1035], and [RFC1591]) 💅. This works super well for a company's own domain and subdomains 💼. The hierarchy can match the org chart, there are established ways to set policy, and everyone is presumably on the same page about goals 🫶.

It gets messy 😬 when a domain is shared by unrelated entities with no common policy assumptions, because it's really hard to agree on rules that apply to all of them and their subdomains. In general, the unrelated-entities situation is always what you get for the labels registered in a TLD (second-level names) 🙈. The exception is TLDs where the second level is structural, like the .CO, .AC, and .GOV conventions in many ccTLDs, or the historical geographical organization of .US [RFC1480] ✨. In those cases, it applies to the labels within that structural level 🎀.

TLDs may, but need not, have consistent registration policies for those second (or third) level names 🌈. Countries (or ccTLD administrators) have often made rules about what entities can register in their ccTLDs and what shape the names can take. RFC 1591 laid out registration norms for most of the gTLDs that existed back then, but those norms have mostly been ignored in recent years 💀. Some recent "sponsored" and purpose-specific domains follow pretty specific rules about what's appropriate to register 🦋. Homogeneous registration rules for the root, on the other hand, are impossible 😭. Almost by definition, the subdomains registered in the root (TLDs) are super diverse, so one policy about the types and formats of names that applies to all root subdomains just isn't feasible 🧚.

1.3.2. Aliases 🦋

okay so in a world that isn't the DNS, the logical move for giving a country code (or other) domain a local-language name would be to set up an alias, or some kind of "see instead" reference 💖. But the DNS doesn't have facilities for either one 💀. What it does have is a CNAME record, and its label can only point to one particular label, not a whole subtree 🍓. For example, if A.B.C is a fully-qualified name, a CNAME reference in B.C from X to A makes X.B.C look like it has the same values as A.B.C ✨. However, a CNAME reference from Y to C in the root would not make A.B.Y referenceable (or even defined) at all 😵.

There's also a second record type, DNAME [RFC2672], that can provide an alias for a portion of the tree 🌸. But many people believe it's technically problematic 🙈. At a minimum, it can cause synchronization issues when references across zones happen, and the IETF has discouraged using it, except as a way to enable a transition from one domain to another 🫠. Even if someone were to contemplate designing yet another alias-type record, the DNS technical constraints of query-response integrity and DNSSec zone signing (cf. [RFC4033], [RFC4034], and [RFC4035]) make it extremely unlikely that one could be defined that meets the desired requirements for "see instead" or true synonym references 🔥.

1.4. Internationalization and Localization 🌍

it's been pointed out a bunch that while lots of people talk about "internationalization," what they actually mean, and want, is "localization" 💜. In this context, "internationalization" means making something accessible globally, with a broad-range "universal" character set and conventions that work for all languages and cultures 🌐. "Localization," on the other hand, is about things working well in one particular locality, or for a broad range of localities, even though the style of operation might differ for each locality 🎀. Anything that actually involves the DNS must be global, and therefore internationalized, because the DNS can't meaningfully support different responses or query and matching models based on things like where the user making the query is located 🙅‍♀️. The DNS can't support localization internally, but a lot of the features we've talked about in this section are way easier to think about in local terms (whether that's a geographical area, users of a language, or some other criteria) than in global ones 🫶.

2. Client-Side Solutions 💅

traditionally, the IETF stayed out of standardizing actions that happen strictly on individual hosts, and kept itself to behavior you can observe "on the wire," i.e., in protocols between network hosts 🖥️. There have been exceptions 👀, when different clients needed to use data or interpret values in compatible ways to keep interoperability. The standards for email and web body formats, and IDNA itself, are examples of these exceptions 💌. No matter what needs to be standardized, it's almost never required, and often unwise, for a user interface to show "on the wire" formats to the user by default 🙅‍♀️ (debugging options that show the wire formats are common and often super useful 🔍). However, in most cases where the presentation format and the wire format differ, the client program must take precautions to make sure the wire format can be rebuilt from user input, or to keep the wire format, while hidden, tied to the presentation mechanism so it can be rebuilt 🔐. It's rarely a goal in itself, but it's often necessary for the user to be at least vaguely aware that the wire ("real") format is different from the presentation one, and for the wire format to be available for debugging 🧠.

honestly, the DNS itself is a perfect example of the difference between the wire format and the user presentation format 🤯. Most Internet users don't realize that the wire format for DNS queries and responses doesn't include the . character 😱. Instead, each label is represented by its length in bytes, followed by the label itself 🧩.

2.1. IDNA and the Client 💻

like I mentioned earlier, IDNA itself is entirely a client-side protocol 🫶. It works by doing some mappings and then encoding labels to be placed into the DNS in a special format called "punycode" [RFC3492] 🎀. When labels in that format show up, the client transforms them back into internationalized (normally Unicode [ISO10646]) characters ✨. The important takeaway here is that any application program that supports IDNA is already doing a ton of transformation work on the client side 🔥. It's not just showing the user the "on the wire" formats. It's also the case that if an application makes different mappings than the ones IDNA calls for, you'll probably only find out when users complain about unexpected behavior 😬. As long as the punycode strings it sends are valid, the server can't tell what mappings were applied to produce those strings 👻.

2.2. Local Translation Tables for TLD Names 🗺️

we suggest that, in addition to maintaining the code and tables needed to support IDNA, authors of application programs may want to keep a table with a list of TLDs and locally-desirable names for each one 💖. For ccTLDs, these could be the names (or locally-standard abbreviations) that the relevant countries are known by locally, whether in ASCII characters or others 🌏. With some care from the application designer (for example, making sure local forms don't conflict with the actual TLD names), a particular TLD name the user types in could be either the local or the standard form, with no special tagging or problems 🙌. When DNS names come into these client programs, the TLD labels would be mapped to local form before IDNA is applied to the rest of the name ✨. When names come in from users, local TLD names would be mapped to the global ones before IDNA is applied or before they're used in other DNS processing 💅.

3. Advantages and Disadvantages of Local Translation 🌈

3.1. Every TLD Appears in the Local Language and Character Set ✨

okay so a top-level domain named after a country in that country's own name, or after a language in that language, is SO appealing 💖 But the same reasons that make it cute also argue for basically every other TLD being reachable from that language too 🦋 A user in Korea who can reach the national ccTLD in the Korean language and character set totally expects generic top-level domains and domains for other countries to be just as accessible, especially if the second-level names are Korean too 🌸 A user from Spain or Portugal, or in Latin America, would probably have the same expectations, but they'd want Spanish or Portuguese names, not Korean ones 💅

That level of local optimization is not realistic 😭 (some would argue it's not even possible) with the DNS, because it would ultimately require every top-level domain to be copied for each of the world's languages. And the copying wouldn't stop at the TLD itself. In principle, all of its subtrees would need to be fully replicated too 🙈 Maybe in practice only the subtrees where a language variation or translation really matters would need it. But ngl, that restriction would shrink the problem without changing what the problem actually is. The administrative hierarchy of the DNS (see Section 1.3.1) turns replication into an administrative nightmare 💀 Every administrator of a second-level domain in the world would be forced to maintain dozens, probably hundreds, of similar zone files for the replicas. Even if only the zones relevant to a particular country or language were replicated, binding them to the right top-level domain and keeping every replica synchronized would be extremely difficult at best. And administrators of third- and fourth-level domains, and beyond, would be facing similar problems 🥺

By contrast, treating TLD names as a localization problem using local translation is pretty simple 🧚 It does put some burden of understanding on the user, though (see Section 4). Each function represented by a TLD (a country, generic registrations, or purpose-specific registrations) could be represented in the local language and character set as needed. And for countries with many languages, or for users living, working in, or visiting countries where their language is not dominant, "local" could be defined in terms of the needs or wishes of each particular user 🫶

An extra bonus: if two countries called themselves by the same name in their local languages (say, Western Slobbovia and Eastern Slobbovia both called themselves "Slobland"), local conventions could still be followed, as long as users understood that only internal forms could be exported outside the country. In this case, that's the ISO 3166-based ccTLD name (see Section 3.3) 👑

Note that this proposal is about mapping native-language strings to existing TLDs. It would almost certainly be ill-advised to stretch the idea too far and try to map strings that local users would be unlikely to guess into TLDs. For example, there are probably no languages in which the country known in English as "Finland" is called "FI". So you would not want to create a mapping from two characters that look or sound like a Roman "F" and a Roman "I" to the ccTLD .fi 🙅‍♀️

3.2. Unification of Country Code Domains 🍓

It follows from some of the comments above that, while there seems to be some immediate appeal in having (at least) two domains for each country, one using the ISO 3166-1 code [ISO3166] and another using a name based on the national name in the national language, that setup would create considerable problems for registrants in both domains 😵 For registrants maintaining enterprise or organizational subdomains, ease of administration of a single family of zone files will usually make a registration in a single top-level domain preferable to replicated sets of them, at least as long as their functional requirements (such a local-language access) are met by the unified structure. For registrants with no interest in any Internet function or protocols other than use of the HTTP/HTTPS-based web, this problem can be dealt with at the applications level using redirects. In the general case, though, that is not a feasible solution 🔗

For countries with multiple national languages that are considered equal and legally equivalent, the advantages of a translation-based approach, rather than multiple registrations and replicated trees, would be even more significant 🌈 Actually installing and maintaining a separate TLD for each language would be an administrative nightmare, especially if the associated zones were meant to stay synchronized. The oft-suggested proposal to adopt an "exactly one extra domain for each country" rule would essentially require some of the multiple-official-language countries to violate their own constitutions 🙃 On the flip side, having multiple domains for a given country, based on the number of official languages and without any expectation of synchronization, would give some countries an extra allocation of TLDs that others would definitely consider unfair ⚖️

Of course, replicated domains might be popular with some registries and registrars, since replication would almost inevitably increase the total number of domains to be registered. Helping that group while hurting Internet users by adding administrative overhead and confusion is not a goal of this document 🙅

3.3. User Understanding of Local and Global References 🧠

The IDNA tables (actually Nameprep [RFC3491] and Stringprep [RFC3454]) must be identical globally for IDNA to work reliably. The tables for mapping between local names and TLD names, though, could be determined locally and differ from one locale to another, as long as users understood that international interchange of names required the standard forms. That understanding adds some extra learning burden for users, although software could help with part of it (see Section 4) 📚

In any event, at least in the foreseeable future, DNS names passed between users in different countries, or using different languages, will likely be forced into punycode form to guarantee compatibility. Those users would not, in general, be able to read each other's scripts or have appropriate input facilities (keyboards, etc.) for them. So the marginal knowledge or effort needed to put TLD names into standard form and transmit them that way would actually be fairly small 💫

3.4. Limits on Expansion of the Number of TLDs 📈

Using local translation does have one side effect that some parts of the Internet community might consider undesirable 😬 The size and complexity of translation tables, and the work of maintaining them, will depend to a considerable extent on the number of top-level domains of interest, how often new domains are added, and how many get added at a time. A country or other locale that wanted a complete set of translations (so that every TLD had a representation in the local language) would presumably find setting up a table for the current collection of a few hundred domains to be a task that takes some days 🗓️ If the number of TLDs stayed relatively stable, with a small number added at infrequent intervals, updates could probably be handled on an ad hoc basis. But if large numbers of domains were added frequently, or if the total number of TLDs became very large, maintaining the table might require dedicated staff if each new TLD had to be accommodated. Worse, updating the tables stored on client machines might require update and synchronization protocols, and all of the complexities that tend to come with them (see [RFC3696] for a discussion of some related issues in applications) 😵‍💫

In practice, there will be little need to translate every TLD into a local language. Some existing TLDs have no obvious translation in many languages (most notably .arpa), or the translation would be far from obvious to typical users (for example, .int and .aero). Of course, these could be translated by function: .arpa to the local term for "infrastructure", .int with "international" or "international organization", .aero with "aeronautical" or "airlines", and so on. But it is not clear whether doing so would have significant value 🤷‍♀️ For almost every language, there are dozens of ccTLDs for which there are no translations of the country names into the local language that anyone other than geographers would know. And if new TLDs are added, there might not be a strong need (or even the capability) to have language-specific equivalents for each 🌍

3.5. Standardization of the Translations 🎀

An immediate question whenever proposals like this one come up is whether the names for the various TLDs that don't match the strings actually in the DNS should be standardized and, if so, by what mechanism 🤔 Standardization would promote communication within a country or among people who share a language. However, it is likely to be very difficult to reach international agreements that wide conformance could be expected to follow. Exceptions might arise within particular countries or language groups. But even then, there might be advantages to users being able to specify additional synonymous names that are easy for them to remember 💜 As with IDNA-based IDNs, users who want to pass information about domain names to people whose exact capabilities and software are unknown, and to do so with minimal risk of confusion, will probably stick to the names that actually appear in the DNS, i.e., the "punycode" representations 🫧

In any event, neither standardization nor uniform use of either the system outlined here or a specific collection of names is required to make the system work for those who would find it useful 🌷 Similarly, mechanisms for country-wide coordination, and examination of whether such mechanisms are appropriate or inappropriate, are beyond the scope of this document 🦋

3.6. Implications for Future New Domain Names ✨

okay so, if apps start using this proposal, making brand new IDNA-based TLDs is going to get a lot harder 😭 bestie, think about it. If this takes off, people who speak those languages will basically expect the local-language name to mean the same thing as an existing TLD 🫣 So creating a new, stand-alone IDNA-based TLD will need way more thinking and care to avoid clashes. And when it finally happens, every app that maps the name to the existing TLD will have to update its mapping tables. A whole glow-up, but it's a lot 💀

BUT the problem might not be as scary in real life as it sounds at first 🫶 For ccTLDs from the ISO 3166-1 list, there's presumably no problem at all. The 3166-1 alpha-2 codes are strictly ASCII, and general trends make clashes with internationalized names extremely unlikely. Like ICANN's "GAC Recommendations" say not to use country names or codes for anything not connected to those specific countries 🌍 Also, the DNS doesn't have a usable aliasing function right now (see Section 1.3.2). So new IDNA-based TLDs will probably only get allocated after countries and other individual entities have had lots of time to spot any problems with the proposed new names 🔍 patience is a whole mood 🦋

3.7. Mapping for TLDs, Not Domain Names or Keywords 🎀

By now it should be super clear that the mapping in this document is only for TLDs, not full domain names or keywords 💅 Like, nothing here should be read as applying to anything other than TLDs, partly because of the limitations in Section 3.1. Also, this document is only about the domain name system (DNS), not any keyword system. How particular keyword systems would interact with these proposals is left as a (possibly very difficult) exercise for whoever reads or implements those systems 🧩 Good luck, you genius 💜 But for the subset of keyword systems that want to completely hide DNS names or URIs from the user, their output would presumably be the LDH names that actually showed up in the DNS. So that's punycode form for IDNA names, with no application processing of the kind discussed here 🍓

4. Information Interchange, IDNs, Comparisons, and Translations 🌸

okay this spec is built on two pretty explicit assumptions 🧚 The first one is that the biggest and most important value of any internationalization or localization technique is letting users who share a language or culture talk to each other. Talking across different cultures, languages, or scripts is inherently harder, and even harder if people can't easily spot the languages and scripts they have in common 😩 Those difficulties come from age-old issues in language translation and differences between languages and scripts. They are NOT problems with the DNS or IDNs, no matter how those are represented 🙅‍♀️ That's the second assumption: when communication across language or cultural groups is needed, the people who have to do it (usually a much smaller group than those talking within the same language and culture) will need to rely on commonly understood languages and scripts, and put in a bit more care and effort than they would within their own groups 🫶

As the sections above outlined, the suggestions in this document could seriously become problems if they're misused or misunderstood 🚨 For example, if two applications on the same host used different translation tables, the user could end up super confused. But in some cases that would only be slightly worse than some of the alternatives 🤷‍♀️ Say that on a given system, IDNs are shown in native script but ASCII TLD names are used. Then cutting and pasting from one app to another might not work the way you expect, unless all the applications and the underlying operating system are Unicode-based and use the same encoding model for Unicode 🫠 Some app writers have already figured out, even without much IDN use, that they need separate "copy string" and "copy link location" operations, plus the matching "paste" operations 💅 Any use of IDNs or Internationalized Resource Identifiers (IRIs, see [RFC3987]) may need similar operations, or extensions to them, to force strings into internal ("punycode" or URI) form on copy and translate them back on paste. If that's done, the right translations could happen as part of the same process ✨ The author's hunch is that these operations will probably be needed on lots of systems whether or not this proposal gets adopted. If that's true, the extra translation steps will likely be invisible to the user 👑

Now, precisely because the translated names proposed here are part of a presentation form, and not the internal form names, they are inappropriate in a bunch of situations where a globally unique, internal-form name is actually required 🙈 It would be a poor, honestly dangerous, idea to use these names in security contexts like names in certificates, access lists, or any other context where accurate comparisons are necessary 🚫

There's also a more general issue when DNS or IRI references get passed between users whose systems are localized for different languages or conventions 🌏 In general, a user in one part of the world won't know how another user's systems are set up or exactly what software they use, and nobody should be expected or forced to learn that stuff 😌 But if the person sending an internationalized reference doesn't know whether the receiving system supports the same characters and fonts, and whether the receiving user is ready to deal with them, the careful sender will send the internal form of the reference too, or even instead of the native-character form 🛡️ And of course, if the reference goes out on paper, on a sign, in a coded character set other than Unicode, or even as an image rather than a Unicode string, then adding the internal form becomes even more important 📄 Adding a translation requirement for TLD labels makes having internal forms available in interchange way more important, but it doesn't actually change the requirement to do so 🔑

Here's a helpful thing to note: in a different networking model than the one the Internet uses, both this proposal and IDNA itself are basically "presentation layer" approaches. They aren't constructions you can expect to work well in interchange 🦋

5. Internationalization Considerations 🌈

This entire specification is about internationalization issues, especially the boundaries between internationalization and localization, and between network protocols and client/user interface actions 💜

6. Security Considerations 🔐

okay this part is SERIOUS, bestie 😤 IDNA gives a client-based way to show Unicode names in applications while only passing ASCII-based names on the wire ✨ That makes it a major step toward bringing a client-based presentation layer into the Internet. But client-based presentation layer transformations bring risks from non-conforming tables that can change meaning without any external protection 🚨 For example, if a mapping table normally maps A onto C, and an attacker alters that table so that A maps onto D instead, a LOT of mischief can happen 😈 On the other hand, these aren't the usual kind of network attacks. They can be thought of as falling into the "users can always cause harm to themselves" category 🙃 The local translation model outlined here doesn't significantly increase the risks over the ones tied to IDNA, but it might open up some new ways to exploit them 🕳️

Both this approach and IDNA rely on updated programs showing users information in a very different form from the one it's sent in on the wire 🖥️ Unless the internal (wire) form is always used in interchange, or at least made available whenever DNS names are exchanged, there's room for ambiguity and confusion about references 😵‍💫 Just like with IDNA itself, if only the "wire" form is shown, the user will feel like nothing valuable has been done, meaning no internationalization or localization has happened. So showing the "wire" form to get rid of the potential ambiguities probably won't be considered an acceptable solution, even with its security advantages 🙅‍♀️

If the translation tables used with the technique suggested here are obtained from a server, or translations are fetched from a remote machine using some protocol, the mechanisms used should make sure the values received are authentic. In other words, neither the values nor the query for them should have been intercepted and tampered with in any way 🔒 No sneaky middlemen, periodt 🚫

7. Acknowledgements 🫶

This document was inspired by a bunch of conversations in ICANN, IETF, MINC, and private settings about the future evolution and internationalization of top level domains 💖 The author didn't know this at the time, but the concept had apparently been developed independently in other groups, which is pretty unsurprising, since anyone even slightly skilled in the relevant technologies should be able to see it coming 🤓 As far as this author knows, though, it was never written up for general comment. The discussions within and about the ICANN IDN Committee were especially helpful, even though several of that committee's participants might be surprised by where those discussions ended up 🌸 Email correspondence with several people after the first version of this document was posted, especially Richard Hill, Paul Hoffman, Lee XiaoDong, and Soobok Lee, led to a lot of clarification in later versions 💅 The author is especially grateful to Paul Hoffman for extensive comments and additional text for the third version, and to Patrik Faltstrom, Joel Halpern, Sam Hartman, and Russ Housley for suggestions that made it into the final one 🙌

The first version of this document was posted on October 21, 2002. 🦋

8. Informative References ✨

Okay, time for the reading list, bestie 📚🧚 These are the outside docs this spec leans on, all listed with their full details.

  • [ISO10646] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993.
  • [ISO3166] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO Standard 3166-1:1977, 1997.
  • [MIME] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, June 1992. This was updated and replaced by Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC2045, November 1996. Also, Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1342, June 1992. That one was updated and replaced by Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. 🎀
  • [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. 🌸
  • [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 🌸
  • [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
  • [RFC1480] Cooper, A. and J. Postel, "The US Domain", RFC 1480, June 1993.
  • [RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
  • [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
  • [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. 💅
  • [RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003.
  • [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. ✨
  • [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
  • [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. 🦋
  • [RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004.
  • [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
  • [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
  • [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. 🔥
  • [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
  • [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

Author's Address 🎀

John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA

Phone: +1 617 491 5735 EMail: john-ietf@jck.com

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈

Intellectual Property 🔥

The IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the implementation or use of the technology in this document are valid or in scope, or on whether any license under those rights might be available. It also doesn't claim to have made any independent effort to find such rights. Info about how rights work for RFC documents lives in BCP 78 and BCP 79. 📚

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to tell it about any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 🫶

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from