idnits 2.17.1 draft-liman-tld-names-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 142: '.... Host software MUST support this mor...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1123, updated by this document, for RFC5378 checks: 1989-10-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 29, 2011) is 4524 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission L-J. Liman 3 Internet-Draft Netnod 4 Updates: 1123 (if approved) J. Abley 5 Intended status: Standards Track ICANN 6 Expires: June 1, 2012 November 29, 2011 8 Top Level Domain Name Specification 9 draft-liman-tld-names-06 11 Abstract 13 The syntax for allowed Top-Level Domain (TLD) labels in the Domain 14 Name System (DNS) is not clearly applicable to the encoding of 15 Internationalised Domain Names (IDNs) as TLDs. 17 This document provides a concise specification of TLD label syntax 18 based on existing syntax documentation, extended minimally to 19 accommodate IDNs. 21 This document updates RFC1123. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 1, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. TLD Label Syntax Specification . . . . . . . . . . . . . . . . 7 61 5. Policy Considerations . . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 68 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 13 69 A.1. draft-liman-tld-names-06 . . . . . . . . . . . . . . . . . 13 70 A.2. draft-liman-tld-names-05 . . . . . . . . . . . . . . . . . 13 71 A.3. draft-liman-tld-names-04 . . . . . . . . . . . . . . . . . 13 72 A.4. draft-liman-tld-names-03 . . . . . . . . . . . . . . . . . 13 73 A.5. draft-liman-tld-names-02 . . . . . . . . . . . . . . . . . 13 74 A.6. draft-liman-tld-names-01 . . . . . . . . . . . . . . . . . 13 75 A.7. draft-liman-tld-names-00 . . . . . . . . . . . . . . . . . 13 76 A.8. Version Identification Tag . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 The syntax of TLD labels ("TLD DNS-Labels", as defined in Section 2) 82 is specified in [RFC1123], where such labels are asserted to be 83 "alphabetic" within a section of that document entitled "DISCUSSION". 84 This can be interpreted as requiring that the hyphen character ("-") 85 and numeric digits be excluded from TLD DNS-Labels. Such a 86 restriction would not accommodate the US-ASCII encoding of 87 Internationalised Domain Names (IDNs), as specified in [RFC5890]. A 88 more detailed discussion of the existing specifications can be found 89 in Section 3. 91 This document extends the syntax of allowable TLD DNS-Labels to 92 support IDNs, but places some restrictions on the choice of IDN 93 labels. These restrictions are intended to be consistent with the 94 existing specification for US-ASCII TLD DNS-Labels. See Section 4 95 for the updated specification. 97 This document focuses narrowly on the issue of allowable DNS-Labels 98 in TLDs and does not (and is not intended to) make any other changes 99 or clarifications to existing domain name syntax rules. 101 It is carefully noted that the specification in this document is not 102 the only factor in choosing suitable TLD DNS-Labels, and that many 103 considerations external to the IETF are included in that wider 104 policy. See Section 5 for more discussion of policy considerations. 106 2. Definitions 108 The term DNS-Label is used in this document to have precisely the 109 same meaning as the term "label", as introduced in [RFC1034], section 110 3.1. A DNS-Label denotes one node in a DNS tree. A DNS-Label is 111 zero to 63 octets in length. The term "DNS-Label" refers exclusively 112 to the "wire format" of the label, and not to any presentation format 113 of the label. 115 A Top-Level Domain (TLD) DNS-Label is the right-most ("highest- 116 level") DNS-Label in a fully-qualified domain name. 118 The terms A-Label and U-Label are used in this document as defined in 119 [RFC5890]. 121 3. Background 123 [RFC0952] defines a host name as follows: 125 'A "name" ... is a text string up to 24 characters drawn from the 126 alphabet (A-Z), digits (0-9), minus sign (-), and period (.). 127 Note that periods are only allowed when they serve to delimit 128 components of "domain style names". (See RFC-921, "Domain Name 129 System Implementation Schedule", for background). No blank or 130 space characters are permitted as part of a name. No distinction 131 is made between upper and lower case. The first character must be 132 an alpha character. The last character must not be a minus sign 133 or period.' [Unnumbered section titled "ASSUMPTIONS", first 134 paragraph] 136 [RFC1123] reaffirms this definition, but makes one change to the 137 syntax: 139 'The syntax of a legal Internet host name was specified in RFC-952 140 [DNS:4]. One aspect of host name syntax is hereby changed: the 141 restriction on the first character is relaxed to allow either a 142 letter or a digit. Host software MUST support this more liberal 143 syntax.' [Section 2.1] 145 In addition, the DISCUSSION section of Section 2.1 says: 147 'However, a valid host name can never have the dotted-decimal form 148 #.#.#.#, since at least the highest-level component label will be 149 alphabetic.' [Section 2.1] 151 Some implementers may have understood the above phrase 'will be 152 alphabetic' to be a protocol restriction. 154 Neither [RFC0952] nor [RFC1123] explicitly states the reasons for 155 these restrictions. It might be supposed that human factors were a 156 consideration; [RFC1123] appears to suggest that one of the reasons 157 was to prevent confusion between dotted-decimal IPv4 addresses and 158 host domain names. In any case, it is reasonable to believe that the 159 restrictions have been assumed in some deployed software, and that 160 changes to the rules should be undertaken with caution. 162 The Internationalised Domain Names in Applications 2008 specification 163 (IDNA2008) [RFC5891] [RFC5892] provides a protocol for encoding 164 Unicode strings in DNS-Labels. The Unicode string used by 165 applications is known as a U-Label; its corresponding encoding in the 166 DNS is known as an A-Label. The terms A-Label and U-Label are used 167 in this document as defined in [RFC5890]. Valid A-Labels always 168 contain non-alphabetic characters. 170 In order to accommodate the wish to express TLD names in scripts 171 other than Latin (or rather, the US-ASCII subset of Latin), it is 172 necessary to allow non-alphabetic characters in the corresponding TLD 173 DNS-Labels. To minimize changes, the U-label form of a TLD name is 174 restricted in ways functionally compatible with the restrictions 175 (from [RFC0952] and [RFC1123]) on US-ASCII TLD names, by applying 176 rules analogous to those already imposed on US-ASCII TLD DNS-Labels 177 to TLD U-labels. 179 However, deployed software that checks DNS top-level labels for 180 conformance with an alphabetic restriction will not recognize such 181 corresponding A-Labels (i.e., U-labels represented in their US-ASCII 182 form). 184 4. TLD Label Syntax Specification 186 This document relaxes the existing specification to allow TLD DNS- 187 Labels to be well-formed A-Labels, but places restrictions on their 188 corresponding U-Labels. That is, not every well-formed A-Label is a 189 valid TLD DNS-Label. 191 The ABNF expression that matches a valid TLD DNS-Label is as follows: 193 tld-dns-label = traditional-tld-label / idn-label 195 traditional-tld-label = 1*63(ALPHA) 197 idn-label = Restricted-A-Label 199 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 201 A Restricted-A-Label is a DNS-Label which satisfies all the following 202 conditions: 204 1. the DNS-Label is a valid A-Label according to [RFC5890]; 206 2. the derived property value of all code points, as defined by 207 [RFC5890], is PVALID; 209 3. the general category of all code points, is one of { Ll, Lo, Lm, 210 Mn, Mc }. 212 This new specification reflects current practice in registration of 213 TLD names by the IANA, extended to accommodate IDNs. 215 5. Policy Considerations 217 This document provides a technical specification that limits the set 218 of TLD DNS-Labels that are available for assignment; it does not aim 219 to encapsulate the full policy framework within which TLD names are 220 chosen. 222 At the time of writing, the policy under which TLD names are chosen 223 is developed and maintained by ICANN in consultation with a wide base 224 of stakeholders. As the Internet continues to grow to serve new user 225 communities, applications and services, it is to be expected that the 226 corresponding policy will be changed accordingly. 228 6. IANA Considerations 230 While this document makes no requests of the IANA, management of the 231 root zone is an IANA function. This document expands the set of 232 strings permitted for delegation from the root zone, and hence 233 establishes new limits for the corresponding IANA policy. 235 7. Security Considerations 237 This document is believed to have limited security implications. 239 General discussion about the security effects of internationalized 240 labels can be found in [RFC5890], section 4. Those considerations 241 apply equally to TLD labels. 243 The creation of new TLDs has the potential to conflict with software 244 which (for example) predates and correspondingly does not accommodate 245 new TLD names. Such software problems might in turn lead to security 246 vulnerabilities, e.g. in the case where a DNS name specified by a 247 user is truncated or otherwise misinterpreted, causing an application 248 to interact with a different remote host from that which the user 249 intended. It should be noted that this is not a new phenomenon, and 250 has been observed following the creation of new (US-ASCII) TLD names 251 prior to the publication of this document. 253 The issue that some Unicode characters can be confused with each 254 other is discussed at length in the Security Considerations section 255 of [RFC5890]. 257 8. Acknowledgements 259 Tina Dam, Patrik Faltstrom, John Klensin, Thomas Narten and Andrew 260 Sullivan contributed text to this document, and their contributions 261 are hereby acknowledged. 263 9. References 265 9.1. Normative References 267 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 268 and Support", STD 3, RFC 1123, October 1989. 270 [RFC5890] Klensin, J., "Internationalized Domain Names for 271 Applications (IDNA): Definitions and Document Framework", 272 RFC 5890, August 2010. 274 [RFC5891] Klensin, J., "Internationalized Domain Names in 275 Applications (IDNA): Protocol", RFC 5891, August 2010. 277 [RFC5892] Faltstrom, P., "The Unicode Code Points and 278 Internationalized Domain Names for Applications (IDNA)", 279 RFC 5892, August 2010. 281 9.2. Informative References 283 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 284 host table specification", RFC 952, October 1985. 286 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 287 STD 13, RFC 1034, November 1987. 289 Appendix A. Change History 291 This section (and sub-sections) should be removed before publication. 293 A.1. draft-liman-tld-names-06 295 Add Mc as an allowable code-point, required for names in Devanagari 296 script. 298 A.2. draft-liman-tld-names-05 300 New affiliation and address for Liman, due to company merger. 302 A.3. draft-liman-tld-names-04 304 Removed subjective and unverified statements regarding deployed 305 software. Replaced with more generic text. Polishing a few 306 expressions to make them less obtrusive. Removed confusing paragraph 307 after ABNF table. Updated some references that are now published as 308 RFCs. 310 A.4. draft-liman-tld-names-03 312 More wordsmithing, and explanatory text. Work on the IANA and the 313 security considerations sections. 315 A.5. draft-liman-tld-names-02 317 Wordsmithing and rearrangement of text following discussions with Joe 318 Abley, Tina Dam, Thomas Narten and Andrew Sullivan. Incorporated 319 revised ABNF and associated specification from Patrik Faltstrom. 320 Tightened definitions and introduced the term "DNS-Label" to avoid 321 ambiguity with various other uses of the word "label". 323 A.6. draft-liman-tld-names-01 325 Substantial comments and improvements supplied by Thomas Narten and 326 John Klensin. Decided to go for a minimal change approach. Also 327 noted that U-labels have to be letters due to jumping digit problem. 328 Rewritten major parts. 330 A.7. draft-liman-tld-names-00 332 First cut. Prompted by Olafur Gudmundsson and Tina Dam. 334 A.8. Version Identification Tag 336 $Id: draft-liman-tld-names.xml,v 1.40 2011/04/12 08:20:42 liman Exp $ 338 Authors' Addresses 340 Lars-Johan Liman 341 Netnod Internet Exchange 342 Box 30194 343 SE-104 25 Stockholm 344 Sweden 346 Email: liman@netnod.se 347 URI: http://www.netnod.se/ 349 Joe Abley 350 ICANN 351 4676 Admiralty Way 352 Suite 330 353 Marina del Rey 90292 354 USA 356 Email: joe.abley@icann.org 357 URI: http://www.icann.org/