RFC 2825

A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols 🕸️✨

• RFC: 2825
• Series: Network Working Group
• Author: Internet Architecture Board (IAB), with L. Daigle as Editor 🎀
• Category: Informational
• Date: May 2000
• Obsoletes / Updates: nothing is listed in the header 🦋

Status of this Memo 📜

Okay bestie, first the boring-but-important bit. This memo gives information to the Internet community. It is not an Internet standard of any kind, and distribution of it is unlimited. 💖

Copyright Notice ©️

Copyright (C) The Internet Society (2000). All Rights Reserved. 🫶

Abstract 🌸

So the whole goal of "internationalizing" Internet protocols is to let everyone on the Internet use their own language and its standard character set to express themselves, write names, and get around the network. 🌍 That's a huge deal, because it touches domain names, which you see in e-mail addresses and in lots of today's URLs used to find stuff on the World Wide Web, and so on. 💻

But here's the tea: domain names are used by Internet protocols that cross national borders. These services have to work together worldwide, or we risk splitting parts of the network apart along locale lines. ✂️😭 That kind of isolation wouldn't just mess up communication between people. It could also keep the areas involved from taking part in e-commerce, distance learning, and other things happening at an international scale, which would slow down economic development. 📉

There are several proposals for internationalizing domain names. Still, it's not yet known whether any of them will ensure this interoperability and global reach while also dealing with how the visible name is represented. Some of them obviously don't. 💀 This document doesn't try to review any specific proposal, because that's the job of the Internationalized Domain Name (IDN) Working Group of the IETF. That group is tasked with evaluating them with the continued global interoperation that all Internet users rightly expect in mind. 👑

This document is a statement by the Internet Architecture Board. It isn't a protocol specification. It's an attempt to clarify the range of architectural issues that internationalizing domain names runs into. 🧚

1. A Definition of Success ⭐

The Internationalized Domain Names (IDN) Working Group is one piece of the IETF's ongoing, comprehensive effort to internationalize language representation in the protocols that keep the Internet running globally. 🌈

Now, the IAB is big on the principles of rough consensus, running code, and architectural integrity, plus making sure the Internet stays globally stable. So every solution proposed to the (IDN) Working Group has to be judged not only on its own technical features, but also on its impact on existing Internet standards and operations, and on the total effect for end-users. 🔥 Solutions must not make users more isolated from their global neighbors, even if they seem to fix a local problem. 🙅‍♀️ Also, existing protocols sometimes limit which characters are allowed. In other cases, implementations of protocols used in the core of the Internet (beyond individual organizations) haven't in practice implemented all the requisite options of the standards. 🤷‍♀️

2. Technical Challenges within the Domain Name System (DNS) 🧩

Honestly, in many technical ways, the IDN work is no different from any other effort to allow multiple character set representations in textual elements that used to be limited to English-language characters. 🔤

One part of the challenge is deciding how to represent the names users want in the DNS, in a way that is clear and technically feasible, and that guarantees a name always means the same thing. 🎯 Several proposals have been suggested to tackle these issues. 💅

The IDN WG's evolving draft requirements document outlines these issues in more detail, and further discussion is deferred to the WG and its documents. 📝

3. Integrating with Current Realities 🌍

Here's the thing, though: the issues the IDN working group is dealing with are complex, and they're tangled up with other operational parts of the Internet. A key challenge when evaluating any proposed solution is analyzing its impact on existing critical operational standards that use fully-qualified domain names [RFC1034], or just host names [RFC1123]. 🕸️ Standards changes can be made, but the best path forward is the one that takes current realities and (re)deployment latencies into account. ⏳

In the Internet's global context, it's not enough to update a few isolated systems, or even most of the systems in one country or region. 🙈 Deployment has to be nearly universal, or we get "islands" of interoperation that give users less access to, and connection with, the rest of the world. 🏝️💔

These aren't esoteric or fleeting worries, either. The IDN WG has already identified some specific issues, and they include (but aren't limited to) the examples below. 👀

3.1 Domain Names and E-mail 💌

As the IDN WG's draft requirements document points out, this issue goes beyond standardizing DNS usage. Electronic mail has long been one of the most-used and most important Internet applications. It's also the bridge that lets users of a variety of local and proprietary mail systems talk to each other. 📬 The standard protocols that define its use (for example, SMTP [RFC821, RFC822] and MIME [RFC2045]) don't permit the full range of characters the DNS specification allows. Certain characters aren't allowed in the domain portions of e-mail addresses under these specifications. 🚫

Some mailers, built to follow these specifications, are known to fail when handling mail that has non-ASCII domain names in its address. They might discard it, misroute it, or damage it. 😱 So it's not possible to just switch to internationalized domain names and expect global e-mail to keep working until most of the servers in the world are upgraded. 🛑

3.2 Domain Names and Routing 🛣️

At a lower level, the Routing Policy Specification Language (RPLS) [RFC2622] uses "named objects," and it inherits object naming restrictions from older standards: [RFC822] for the same e-mail address restrictions, and [RFC1034] for hostnames. 🧾 That means until routing registries and their protocols are updated, it isn't possible to enter or retrieve network descriptions that use internationalized domain names. 🙅‍♀️

3.3 Domain Names and Network Management 🛠️

Also, the Simple Network Management Protocol (SNMP) uses the textual representation defined in [RFC2579]. That specification does allow for UTF-8-based domain names. However, an informal survey of deployed implementations of the software libraries used to build SNMP-compliant software found that few (if any) of them implement it. 😬

This may make it impossible to enter or display correct data in network management tools, if those names are internationalized domain names. 📊

3.4 Domain Names and Security 🔐

Critical parts of Internet public key technologies (PKIX [RFC2459], and IKE [RFC2409]) rely heavily on identifying servers (by hostnames, or fully qualified domain names) and users (by e-mail addresses). 🧑‍💻 If these protocols don't respect the character restrictions, security tools built on them will be affected. Two examples are the Transport Layer Security protocol (TLS [RFC2246]) and IPsec [RFC2401]. 🛡️

The failure might not be obvious, either. For example, in TLS, it's common for a server to show a certificate containing a domain name that claims to be the server's domain name. The client can then match that against the server name it thought it used to reach the service. 🤔

Unless comparison of domain names is properly defined, the client might fail to match the domain name of a legitimate server, or incorrectly match the domain name of a server performing a man-in-the-middle attack. 😈 Either failure could enable attacks on systems that are now impossible, or at least far more difficult. 🚨

Real talk: a domain-name mismatch in TLS can be the difference between talking to the right server and talking to an attacker. Keep the comparison rules tight, bestie. 🫶

---

To be continued in Part 2! 🦋✨

7. References 📚

Okay bestie, here's the reading list. Every single source the document leans on, with all the details. 🧚

• [RFC821]: Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. 💌
• [RFC822]: Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. 📨
• [RFC1034]: Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. 🌐
• [RFC1123]: Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, November 1989. 🖥️
• [RFC2401]: Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 🔐
• [RFC2409]: Harkins, D and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. 🗝️
• [RFC2045]: Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 📎
• [RFC2246]: Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 🔒
• [RFC2459]: Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. 📜
• [RFC2579]: McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J. and M. Rose, "Textual Conventions for SMIv2", RFC 2579, April 1999. 🧾
• [RFC2622]: Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999. 🛣️
• [RFC2826]: IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. 🌳

---

8. Author's Address 🏛️

This one's from the Internet Architecture Board, the IAB. 💖

Internet Architecture Board

EMail: iab@iab.org

Membership at time this document was completed:

• Harald Alvestrand 🌸
• Ran Atkinson 🌸
• Rob Austein 🌸
• Brian Carpenter 🌸
• Steve Bellovin 🌸
• Jon Crowcroft 🌸
• Leslie Daigle 🌸
• Steve Deering 🌸
• Tony Hain 🌸
• Geoff Huston 🌸
• John Klensin 🌸
• Henning Schulzrinne 🌸

---

9. Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2000). All Rights Reserved.

Okay, the legal stuff, but make it cute. 🎀 You're allowed to copy and share this document and translations of it, and you can make derivative works that comment on or explain it or help with implementing it. You can publish and distribute those, in whole or in part, with no restrictions at all, as long as the copyright notice and this paragraph are on every copy and derivative. 🦋

The document itself, though, may not be modified in any way. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are developing Internet standards, where the copyright procedures in the Internet Standards process have to be followed, and translating it into languages other than English. 🌈

These permissions are perpetual. The Internet Society or its successors or assigns won't revoke them. 💜

This document and the information in it are provided on an "AS IS" basis. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 💅

---

Acknowledgement 🫶

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