RFC 3491

RFC 3491: Nameprep, a Stringprep Profile for IDNs 💖

okay bestie, this one is Nameprep, and it's the rulebook for getting internationalized domain names (IDNs) ready so they actually behave for people all over the world 🌍✨ It's a Standards Track doc from March 2003, written by Paul Hoffman (IMC & VPNC) and Marc Blanchet (Viagenie), in the Network Working Group. The title block doesn't list anything it obsoletes or updates. 🎀

---

Status of This Memo ✨

This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🫶

Copyright Notice 🌸

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

Abstract ✨

This doc explains how to prep internationalized domain name (IDN) labels so that name input and name comparison work the way typical users expect, wherever they are 🌈 It's a profile of the stringprep protocol and it's part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS) 🧚

1. Introduction 🦋

This doc lays out the processing rules that let users type internationalized domain names (IDNs) into apps and have the best shot at getting the string right 💜 It's a profile of stringprep [STRINGPREP], and these rules are only for IDNs, not arbitrary text, so don't go using them on your diary entries 😭

Here's what the profile defines, as [STRINGPREP] requires:

• The intended applicability of the profile: internationalized domain names processed by IDNA.
• The character repertoire that is the input and output to stringprep: Unicode 3.2, specified in section 2.
• The mappings used: specified in section 3.
• The Unicode normalization used: specified in section 4.
• The characters that are prohibited as output: specified in section 5.
• Bidirectional character handling: specified in section 6.

1.1 Interaction of protocol parts 🎀

Nameprep is used by the IDNA [IDNA] protocol to prep domain names, and that's its only job 💅 It's explicitly not built for processing arbitrary free text, so it SHOULD NOT be used for that purpose 🙈 Nameprep is a profile of Stringprep [STRINGPREP], and implementations of Nameprep MUST fully implement Stringprep ✨

Nameprep works on domain name labels, not whole domain names. IDNA calls nameprep for each label in a domain name 🍓

1.2 Terminology 🔥

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] 👑

2. Character Repertoire 🌈

This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A 💖

3. Mapping 🦋

This profile specifies mapping using the following tables from [STRINGPREP]:

• Table B.1
• Table B.2

4. Normalization ✨

This profile specifies using Unicode normalization form KC, as described in [STRINGPREP] 🫶

5. Prohibited Output 🚫

This profile specifies prohibiting output using the following tables from [STRINGPREP]:

• Table C.1.2
• Table C.2.2
• Table C.3
• Table C.4
• Table C.5
• Table C.6
• Table C.7
• Table C.8
• Table C.9

IMPORTANT NOTE: This profile MUST be used with the IDNA protocol. The IDNA protocol has additional prohibitions that are checked outside of this profile. 🚨

6. Bidirectional characters 🌸

This profile says to check bidirectional strings the way [STRINGPREP] section 6 describes 🔄

7. Unassigned Code Points in Internationalized Domain Names 🧚

If the processing in [IDNA] says to use a list of unassigned code points, the system uses table A.1 from [STRINGPREP] as its list 🥰

8. References 📚

8.1 Normative References

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
• [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.

8.2 Informative references

• [STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, and "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

9. Security Considerations 💀🔐

Heads up, this section is serious 😭 The Unicode and ISO/IEC 10646 repertoires have a LOT of characters that look alike. Users of security protocols often do visual matching, like when they compare the names of trusted third parties. Since you can't map look-alike characters together without a lot of context, like knowing which fonts are in use, stringprep does nothing to map look-alikes together and doesn't prohibit characters just because they resemble others.

The Internet's security partly depends on the DNS, so any change to the DNS can change the security of a huge chunk of the Internet. 🚨

Domain names are how users reach Internet servers. If one internationalized name you typed could land you on different servers depending on how it was interpreted, the Internet's security would be compromised 💔

Current apps might assume the characters allowed in domain names will always match what they are in [STD13]. This doc hugely increases the number of characters you can use in domain names 🌊 Any program that uses "special" characters alongside domain names may be vulnerable to attacks based on the new characters this spec allows. Be careful out there 👀

10. IANA Considerations 📋

This is a profile of stringprep, and it's been registered with IANA in the stringprep profile registry (www.iana.org/assignments/stringprep-profiles) 🎀

Name of this profile:
   Nameprep

RFC in which the profile is defined:
   This document.

Indicator whether or not this is the newest version of the
profile:
   This is the first version of Nameprep.

11. Acknowledgements 🫶

Lots of people from the IETF IDN Working Group and the Unicode Technical Committee added ideas to this doc 🌟

The IDN Nameprep design team made many helpful changes. That team and its advisors include:

• Asmus Freytag
• Cathy Wissink
• Francois Yergeau
• James Seng
• Marc Blanchet
• Mark Davis
• Martin Duerst
• Patrik Faltstrom
• Paul Hoffman

More significant improvements were proposed by:

• Jonathan Rosenne
• Kent Karlsson
• Scott Hollenbeck
• Dave Crocker
• Erik Nordmark
• Matitiahu Allouche

12. Authors' Addresses 💌

Paul Hoffman
Internet Mail Consortium and VPN Consortium
127 Segre Place
Santa Cruz, CA  95060 USA

EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org


Marc Blanchet
Viagenie inc.
2875 boul. Laurier, bur. 300
Ste-Foy, Quebec, Canada, G1V 2M2

EMail: Marc.Blanchet@viagenie.qc.ca

13. Full Copyright Statement ⚖️

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and 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 🌈