RFC 3696

Application Techniques for Checking and Transformation of Names

📅 published February 2004, from ietf

RFC 3696: Application Techniques for Checking and Transformation of Names 🎀

Okay so the header is pure IETF classic: it's from the Network Working Group, written by J. Klensin 💅, dated February 2004, and filed as Category: Informational 🧚. Informational means it's sharing info, not defining an Internet standard. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Status of This Memo ✨

Quick vibe check: this memo gives info to the Internet community 💖. It does not specify an Internet standard of any kind 🙈. Distribution is unlimited, so share it with everyone 🌈

Copyright (C) The Internet Society (2004). All Rights Reserved. 💜

Abstract 🌸

Okay so, a lot of Internet apps are built to guess the top-level domain (or other domain name labels) from partial info 🔍 Then new TLDs showed up, especially the ones that aren't country codes, and that exposed flaws in some of those guessing methods 😭 Now users can have a harder time, or straight up can't, reach parts of the full Internet 💀 This memo covers some of the techniques people have used and gives some tips for keeping the negative impact small as the domain name environment evolves 🫶 It pulls summaries of the applicable rules into one place and points to the actual standards, so you can check the source 🍓

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Restrictions on domain (DNS) names . . . . . . . . . . . . . .  3
3.  Restrictions on email addresses  . . . . . . . . . . . . . . .  5
4.  URLs and URIs  . . . . . . . . . . . . . . . . . . . . . . . .  7
    4.1.  URI syntax definitions and issues  . . . . . . . . . . .  7
    4.2.  The HTTP URL . . . . . . . . . . . . . . . . . . . . . .  8
    4.3.  The MAILTO URL . . . . . . . . . . . . . . . . . . . . .  9
    4.4.  Guessing domain names in web contexts  . . . . . . . . . 11
5.  Implications of internationalization . . . . . . . . . . . . . 11
6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
    9.1.  Normative References . . . . . . . . . . . . . . . . . . 14
    9.2.  Informative References . . . . . . . . . . . . . . . . . 15
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16

1. Introduction 🌷

Designers of user interfaces for Internet apps have often found it useful to check user-provided values for validity before handing them to the Internet tools 👀 This kind of test usually involves syntax checks or other rules applied to domain names, email addresses, or "web addresses" (URLs or, occasionally, extended URI forms (see Section 4)) 💅 It can give users way better diagnostics than they'd get from the protocol itself 🫶 Local validity tests are also thought to make back-office processing more efficient and to reduce the load on the protocols themselves 📈 Honestly, they line up with the well-established principle that it's better to detect errors as early as possible 🔥

The tests have to be made correctly, or at least safely 😤 If the criteria don't match the protocols, users get inconvenienced, addresses and sites become effectively inaccessible to some groups, and business and communication opportunities get lost 💔 Experience in recent years shows that syntax tests are often done incorrectly, and that top-level domain tests are run against obsolete lists and conventions 🙈 The author assumes most of these wrong tests happen because people can't easily find the exact definitions of the criteria they're supposed to apply 🧐 So this document pulls summaries of the applicable rules together in one place and points to the actual standards 🎀 It doesn't add anything to those standards. It just gathers the info into a form that may be more accessible ✨

Lots of Internet protocol experts believe that tests and rules like these should be avoided in applications, and that the tests in the protocols and back-office systems should be relied on instead 🦋 Honestly, implementations of the protocols can't assume that the data passed to them will be valid 😭 Unless the standards specify particular behavior, this document takes no position on whether or not the testing is desirable 🤷‍♀️ It only identifies the correct tests to be made if tests are going to be applied 💖

The sections that follow talk about domain names, email addresses, and URLs 🌈

2. Restrictions on domain (DNS) names 🌐

The authoritative definitions of the format and syntax of domain names are in RFCs 1035 [RFC1035], 1123 [RFC1123], and 2181 [RFC2181] 📚

Literally any characters, or combination of bits (as octets), are permitted in DNS names 🤯 But there's a preferred form that most applications require 👑 That preferred form has been the only one permitted in top-level domain (TLD) names. In general, it's also the only form permitted in most second-level names registered in TLDs, although some names that normally aren't seen by users follow other rules 🫠 It comes from the original ARPANET rules for naming hosts (the "hostname" rule), and it's probably better described as the "LDH rule," after the characters it permits 🍓 The LDH rule, as updated, says the labels (words or strings separated by periods) that make up a domain name must consist of only the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen 🔤 No other symbols or punctuation characters are permitted, and neither is blank space 🚫 If the hyphen is used, it's not permitted to appear at either the beginning or end of a label 🙅‍♀️ There's also an extra rule that basically says top-level domain names can't be all-numeric 🔢

When you need to express labels with non-character octets, or to embed periods within labels, there's a mechanism for keying them in that uses an escape sequence 🧩 Consult RFC 1035 [RFC1035] if you need that mechanism (most common apps, including email and the Web, generally won't permit those escaped strings) 🙈 A special encoding is now available for non-ASCII characters. See the brief discussion in Section 5 🌏

Most Internet apps that reference other hosts or systems assume they'll be given "fully-qualified" domain names, meaning names that include all of the labels leading to the root, including the TLD name 🌳 Those fully-qualified names then get passed either to the domain name resolution protocol itself or to the remote systems 📡 So purported DNS names used in applications, and to locate resources, generally must contain at least one period (".") character 💕 Ones that don't are either invalid or require the app to supply more info 🧐 Of course, this principle doesn't apply when the app's purpose is to process or query TLD names themselves 💅 The DNS spec also lets a trailing period denote the root, so a.b.c and a.b.c. are equivalent 👯 But the latter is more explicit, and applications are required to accept it 🫶 This matters most when a TLD name is referred to directly. For example, ".COM" has become the popular way to talk about that TLD, but "COM." is strictly and technically correct when talking about the DNS, because it shows that "COM" is a top-level domain name 🎀

Here's the thing: lots of apps have tried going beyond the "one or more periods" test to check that a valid TLD name is actually present 👀 They did this by applying heuristics to the form of the name, or by checking a local list of valid names 📋 The old heuristics don't work anymore 🥲 If you keep a local list, you have to put way more effort into keeping it up-to-date than you did a few years ago 📆

The heuristics were built on the observation that, since the DNS was first deployed, all top-level domain names were two, three, or four characters long 🔡 All two-character names were tied to "country code" domains, with the specific labels (with a few early exceptions) drawn from the ISO list of codes for countries and similar entities [IS3166] 🌍 The three-letter names were "generic" TLDs, whose function wasn't country-specific, and there was exactly one four-letter TLD, the infrastructure domain "ARPA." [RFC1591] 🏛️ But these length-dependent rules were conventions, not something the protocols depended on 💡

Before the mid-1990s, lists of valid top-level domain names changed infrequently 🐢 New country codes were added gradually, and then more rapidly, as the Internet expanded. But the list of generic domains didn't change at all between the creation of the "INT." domain in 1988 and ICANN's allocation of new generic TLDs in 2000 🥹 Some application developers responded by assuming any two-letter domain name could be valid as a TLD, but the generic TLD list was fixed and could be kept locally and tested 🧠 A few of these assumptions broke once ICANN started allocating new top-level domains. One two-letter domain that doesn't appear in the ISO 3166-1 table [ISO.3166.1988] was tentatively approved, and new domains were created with three, four, and even six letter codes 🤯

As of the first quarter of 2003, the list of valid, non-country, top-level domains was .AERO, .BIZ, .COM, .COOP, .EDU, .GOV, .INFO, .INT, .MIL, .MUSEUM, .NAME, .NET, .ORG, .PRO, and .ARPA 📝 ICANN is expected to expand that list at regular intervals, so the list shown here should not be used in testing 🚫 Instead, systems that filter by testing TLD names should regularly update their local tables of TLDs (both "generic" and country-code-related) by polling the list published by IANA [DomainList] 🔄 It's likely that the better strategy now is to do the "at least one period" test, verify LDH conformance (including verifying that the apparent TLD name isn't all-numeric), and then use the DNS to determine domain name validity, rather than trying to maintain a local list of valid TLD names 🏆

A DNS label may be no more than 63 octets long 📏 This is the length of the form actually stored. If a non-ASCII label is converted to encoded "punycode" form (see Section 5), the length of that form may restrict how many actual characters (in the original character set) can fit 🧮 A complete, fully-qualified domain name must not exceed 255 octets 🛑

Some extra mechanisms for guessing correct domain names when incomplete info is provided have been developed for use with the web, and they're discussed in Section 4.4 🕸️✨

3. Restrictions on email addresses ✨

Reference documents: RFC 2821 [RFC2821] and RFC 2822 [RFC2822]

okay bestie, email addresses are giving main character energy 💌 A modern email address is a "local part" joined to a "domain part" (a fully-qualified domain name) by an at-sign ("@") 🦋 The domain part follows the same rules as the previous section, so all those worries about filtering and lists of names apply here too 💅 The domain can also be swapped for an IP address in square brackets, but that's strongly discouraged except for testing and troubleshooting 🙈

The local part can show up using the quoting conventions we're about to cover 🎀 Quoted forms are rarely used in practice, but they're needed for some legit purposes 🫶 So they should not be rejected by filtering routines. Instead, they should be passed to the email system so the destination host can evaluate them 🌸

Here's the exact rule: any ASCII character, control characters included, may appear quoted or inside a quoted string ✨ When quoting is needed, you use the backslash character to quote the character right after it. For example:

Abc\@def@example.com

is a valid form of an email address 💖 Blank spaces can also show up, like this:

Fred\ Bloggs@example.com

The backslash can also quote itself, like this:

Joe.\\Blow@example.com

Besides backslash quoting, conventional double-quote characters can wrap strings too 🧚 For example:

"Abc@def"@example.com

"Fred Bloggs"@example.com

These are alternate forms of the first two examples above 🌈 Quoted forms are rarely recommended and uncommon in practice, but as we talked about, applications processing email addresses must support them 😭 Quoted forms often show up with addresses tied to transitions from other systems and contexts, and those transition requirements still happen. A system that accepts a user-provided email address can't "know" whether that address belongs to a legacy system, so those address forms must be accepted and passed into the email environment 💜

Without quotes, the local part can be any mix of letters, digits, or any of these special characters:

! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

A period (".") can also appear, but it can't start or end the local part, and two or more consecutive periods aren't allowed 🙅‍♀️ Put another way, any printing ASCII character except the at-sign ("@"), backslash, double quote, comma, or square brackets can appear without quoting ✨ If any of the excluded characters need to appear, they must be quoted 💅 These forms are valid and pretty common:

user+mailbox@example.com
customer/department=shipping@example.com

$A12345@example.com

!def!xyz%abc@example.com

_somename@example.com

Any of the characters listed above are permitted 🦋 In local parts, the apostrophe ("'") and the acute accent ("`") are ordinary characters, not quoting characters 💌 Some of those special characters have routing or other special handling on certain receiving hosts. But there's no way to know whether the remote host uses those conventions or just treats them as normal text, so sending programs (and programs checking address validity) must simply accept these strings and pass them on 🫶

Besides the syntax rules, there's also a length limit on email addresses. The local part (before the "@") can be at most 64 characters (octets), the domain part (after the "@") can be at most 255 characters (octets), and the total comes to 320 characters 😱 Systems that handle email should be ready to process addresses that long, even though you'll rarely run into them 💀

4. URLs and URIs 🌸

4.1. URI syntax definitions and issues 🔥

The syntax for URLs (Uniform Resource Locators) is specified in [RFC1738] 🍓 The more general "URI" (Uniform Resource Identifier) syntax is specified in [RFC2396] ✨ URI syntax is super general, with lots of variation depending on the "scheme" you're using (like "http", "ftp", or "mailto") 🧚 You could use the general syntax rules from RFC 2396 to check syntax, but they're so broad (basically just splitting the scheme name from the "scheme specific part" with a colon (":") and excluding some characters that must be escaped if used) that they don't really filter or validate much 🥱

The following characters are reserved in many URIs. They must be used for their URI-intended purpose or be encoded 🔒 Some schemes may loosen these restrictions or only apply them to particular component parts. See the following sections for URLs used on "web pages" and for electronic mail 💜

; / ? : @ & = + $ , ?

On top of that, control characters, the space character, the double-quote (") character, and these special characters:

< > # %

are generally forbidden. They must either be avoided or escaped, as discussed below 🙈

The colon after the scheme name and the percent sign used for escaping are specifically reserved for those jobs, although ":" can also show up elsewhere in some schemes 🎀

When you need to encode these characters (or others), you replace the character with a percent-sign ("%") followed by two hexidecimal digits that represent its octet value 💖 See section 2.4.1 of [RFC2396] for the exact definition. Unless a character is a delimiter of the URI scheme itself, it can optionally be encoded this way. Systems testing URI syntax should be ready for these encodings to appear in any component of the URI except the scheme name itself 🫶

There's a "generic URI" syntax that's more restrictive, but using it to test URI strings means you need to know whether the particular scheme in use follows that syntax 😵‍💫 So applications that want to check or validate URIs should usually identify the scheme name first and then apply scheme-specific tests 🦋 The rules for two of them, HTTP [RFC1738] and MAILTO [RFC2368] URLs, are discussed below. But if you're writing an application that needs very precise checks, or that rejects particular syntax instead of just warning the user, go check the relevant scheme-definition documents for exact syntax and relationships 📚

4.2. The HTTP URL 🌈

Absolute HTTP URLs are made up of the scheme name, a host name (a domain name or IP address), and an optional port number. Then, optionally, there's a path, a search part, and a fragment identifier 🍓 These are separated by a colon and the two slashes before the host name, a colon, a slash, a question mark, and a hash mark ("#") respectively. So we get:

http://host:port/path?search#fragment

http://host/path/

http://host/path#fragment
http://host/path?search

http://host

and other variations on that form 💅 There's also a "relative" form, but it almost never shows up in text a user might enter into a form. See [RFC2616] for details 🧚

These characters are reserved within the path and search parts and must be encoded:

/ ; ?

The first one (the slash) can be used unencoded, and it's often used in the path to show hierarchy 🌸

4.3. The MAILTO URL 💌

okay so MAILTO is a URL type whose content is an email address 💖 It can encode any of the email address formats from Section 3 above ✨ It can also handle multiple addresses and even stuff like Subject lines inside the body of the URL 🎀 MAILTO is officially defined in RFC 2368 [RFC2368], so if you're going to accept or test multiple addresses or mail header or body formats, read that doc carefully, bestie 📚

Now, when you're accepting text for a MAILTO URL or validating one, here's the tea 🫖 A MAILTO URL can encode any valid email address, but you can't just copy the address in as-is, because email addresses can contain characters that are invalid in URLs or have reserved meanings there 😭 Those characters have to be encoded, as outlined in Section 4.1 above, when the address gets mapped into URL form. And it goes the other way too: addresses pulled out of MAILTO URLs generally can't be copied straight into email contexts, since most email programs won't reverse the decoding (and doing that might count as a protocol violation 🙈).

These characters only work in MAILTO URLs with the specific meanings listed below. If they show up in an email address for some other purpose, they must be encoded:

:       The colon in "mailto:"

< > # " % { } | \ ^ ~ `

These characters are "unsafe" in any URL, so they must always be encoded 🚫

These characters must also be encoded if they appear in a MAILTO URL:

? & =
   Used to delimit headers and their values when these are
   encoded into URLs.

Here are some examples, because examples are everything 🧁

+-------------------------+-----------------------------+-----------+
|      Email address      |         MAILTO URL          |   Notes   |
+-------------------------+-----------------------------+-----------+
|     Joe@example.com     |  mailto:joe@example.com     |     1     |
|                         |                             |           |
|  user+mailbox@example   |         mailto:             |     2     |
|          .com           |  user%2Bmailbox@example     |           |
|                         |          .com               |           |
|                         |                             |           |
|  customer/department=   |  mailto:customer%2F         |     3     |
|  shipping@example.com   | department=shipping@example |           |
|                         |          .com               |           |
|                         |                             |           |
|   $A12345@example.com   |  mailto:$A12345@example     |     4     |
|                         |          .com               |           |
|                         |                             |           |
|  !def!xyz%abc@example   |  mailto:!def!xyz%25abc      |     5     |
|          .com           |       @example.com          |           |
|                         |                             |           |
|  _somename@example.com  |  mailto:_somename@example   |     4     |
|                         |          .com               |           |
+-------------------------+-----------------------------+-----------+

                                  Table 1

Notes on Table 🗒️

  1. No characters appear in the email address that require escaping, so the body of the MAILTO URL is identical to the email address ✨
  2. There is actually some uncertainty as to whether or not the "+" characters requires escaping in MAILTO URLs (the standards are not precisely clear). But, since any character in the address specification may optionally be encoded, it is probably safer to encode it 🤷‍♀️
  3. The "/" character is generally reserved in URLs, and must be encoded as %2F 🙅‍♀️
  4. Neither the "$" nor the "_" character are given any special interpretation in MAILTO URLs, so need not be encoded 💅
  5. While the "!" character has no special interpretation, the "%" character is used to introduce encoded sequences and hence it must always be encoded 🫶

4.4. Guessing domain names in web contexts 🔍

okay this one is so messy 😭 Several web browsers have adopted a practice where you can type an incomplete domain name instead of a full URL. This has, for example, let users type "microsoft" and have the browser interpret it as "http://www.microsoft.com/". Other browser versions went even further and tried to build DNS names through a series of heuristics, testing each variation in turn to see if it shows up in the DNS and accepting the first one found as the intended domain name 💀 Others automatically invoke search engines if no period appears or if the reference fails.

If any of these approaches are used, it is often critical that the browser recognize the complete list of TLDs. If the list is incomplete, complete domain names may not be recognized as such, and the system may try to turn them into completely different names 😱 For example, "example.aero" is a fully-qualified name, since "AERO." is a TLD name. But if the system doesn't recognize "AERO" as a TLD name, it's likely to try to look up example.aero.com and www.example.aero.com (and then fail or find the wrong host), rather than simply looking up the user-supplied name.

As discussed in Section 2 above, there are dangers with software that tries to "know" the list of top-level domain names locally and take advantage of that knowledge. These name-guessing heuristics are another example of that situation. If the lists are up-to-date and used carefully, the systems they're embedded in may provide an easier, and more attractive, experience for at least some users ✨ But finding the wrong host, or being unable to find a host even when its name is precisely known, are bad experiences by any measure 🥲

More generally, there have been bad experiences with attempts to "complete" domain names by adding additional information to them. These issues are described in some detail in RFC 1535 [RFC1535] 📖

5. Implications of internationalization 🌍

The IETF has adopted a series of proposals ([RFC3490] - [RFC3492]) that let internationalized (i.e., non-ASCII) names be encoded in the DNS. The primary standard, and the group as a whole, are known as "IDNA" 🌏 The actual strings stored in the DNS are in an encoded form: the labels begin with the characters "xn--" followed by the encoded string. Applications should be prepared to accept and process the encoded form (those strings are consistent with the "LDH rule" (see Section 2), so they shouldn't raise any separate issues) and the use of local, and potentially other, characters as appropriate to local systems and circumstances 💖

The IDNA specification describes the exact process used to validate a name or encoded string. The process is complex enough that shortcuts or heuristics, especially for versions of labels written directly in Unicode or other coded character sets, are likely to fail and cause problems 🙃 In particular, these strings can't be validated with syntax or semantic rules of the usual sorts: syntax validity is defined only in terms of the result of executing a particular function.

On top of the protocol restrictions, many domains are implementing rules about which non-ASCII names they'll let people register (see, e.g., [JET], [RegRestr]). This work is still relatively new, and the rules and conventions are likely to be different for each domain, or at least for each language or script group 🌸 Trying to test for those rules in a client program, to see if a user-supplied name might possibly exist in the relevant domain, would almost certainly be ill-advised 🚩

One quick local test, however, may be reasonable: as of the time of this writing, there should be no labels in the DNS that start with two characters, followed by two hyphens, where the two characters are not "xn" (in either upper or lower case). Such label strings, if they appear, are probably erroneous or obsolete, and it may be reasonable to at least warn the user about them ⚠️

There is ongoing work in the IETF and elsewhere to define internationalized formats for use in other protocols, including email addresses. Those forms may or may not conform to existing rules for ASCII-only identifiers, so anyone designing evaluators or filters should watch that work closely 👀

6. Summary 🎀

When an application accepts a string from the user and ultimately passes it on to an API for a protocol, whether to test or filter the text in any way not required by the protocol itself is hotly debated 🔥 If it has to divide the string into its components, or otherwise interpret it, it obviously must make at least enough tests to validate that process. With things like domain names or email addresses that can be passed on untouched, deciding which ones are valid and which aren't is a more complex call. It should include how to make exactly the correct tests, and how to keep information that changes and evolves up-to-date 🧠 A test containing obsolete information can be extremely frustrating for potential correspondents or customers, and may harm the relationships you want to keep 💔

7. Security Considerations 🔐

okay this section is serious, so buckle up 🫣 Since this document merely summarizes the requirements of existing standards, it doesn't introduce any new security issues. However, many of the techniques that motivate the document raise important security concerns of their own. Rejecting valid forms of domain names, email addresses, or URIs often denies service to the user of those entities 😤 Worse, guessing at the user's intent when an incomplete address, or other string, is given can compromise privacy or the accuracy of a reference if the wrong target is found and returned 😱 From a security standpoint, the optimum behavior is probably to never guess, and instead to force the user to specify exactly what they want. When that position involves a tradeoff with an acceptable user experience, good judgment should be used, and the fact that it's a tradeoff should be recognized 🧐

Some characters have special or privileged meanings on some systems (i.e., ` on Unix). Applications should be careful to escape those locally if necessary. By the same token, they are valid, and should not be disallowed locally, or escaped when transmitted through Internet protocols, for such reasons if a remote site chooses to use them 🫶

The presence of local checking does not permit remote checking to be bypassed. Note that this can apply to a single machine. In particular, a local MTA should not assume that a local MUA has properly escaped locally-significant special characters 🚨

8. Acknowledgements 💜

The author would like to express his appreciation for helpful comments from Harald Alvestrand, Eric A. Hall, and the RFC Editor, and for partial support of this work from SITA 🥰 Responsibility for any errors remains, of course, with the author.

The first Internet-Draft on this subject was posted in February 2003. The document was submitted to the RFC Editor on 20 June 2003, returned for revisions on 19 August, and resubmitted on 5 September 2003 🗓️

9. References 📚

9.1. Normative References ✨

Okay, this is the bibliography bit, but it's the part that tells you what you actually need to read 💅 These are the normative references, so they're required reading for implementers:

  • [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
  • [RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.
  • [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
  • [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
  • [RFC2368] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
  • [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
  • [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
  • [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.
  • [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968. ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
  • [DomainList] Internet Assigned Numbers Authority (IANA), Untitled alphabetical list of current top-level domains. http://data.iana.org/TLD/tlds-alpha-by-domain.txt ftp://data.iana.org/TLD/tlds-alpha-by-domain.txt

9.2. Informative References 🌸

These ones are background reading, so they're helpful but not required to implement anything:

  • [ISO.3166.1988] International Organization for Standardization, "Codes for the representation of names of countries, 3rd edition", ISO Standard 3166, August 1988.
  • [JET] Konishi, K., et al., "Internationalized Domain Names Registration and Administration Guideline for Chinese, Japanese and Korean", Work in Progress.
  • [RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
  • [RegRestr] Klensin, J., "Registration of Internationalized Domain Names: Overview and Method", Work in Progress, February 2004.

10. Author's Address 🧚

Here's where you can reach the author:

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 (2004). 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.

Now the legal part, which is serious even if I'm not 😭 This document and the information in it 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 technology in this document are valid, or how far they reach, or whether any license under those rights might or might not be available. It also doesn't claim to have done any independent work to find such rights. If you want the procedures for rights in RFC documents, look in BCP 78 and BCP 79.

Copies of IPR disclosures that were made to the IETF Secretariat, along with any assurances of licenses that will be made available, or the result of any attempt to get a general license or permission for implementers or users of this specification to use those proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please send that information 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