idnits 2.17.1 draft-obispo-epp-idn-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 376 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 14, 2013) is 3786 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 80 -- Looks like a reference, but probably isn't: '2' on line 95 == Missing Reference: 'RFC3688' is mentioned on line 302, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force F. Obispo 2 Internet-Draft L. Munoz 3 Intended status: Experimental ISC 4 Expires: June 17, 2014 December 14, 2013 6 Internationalized Domain Name Mapping Extension for the Extensible 7 Provisioning Protocol (EPP) 8 draft-obispo-epp-idn-04 10 Abstract 12 This document describes an Extensible Provisioning Protocol (EPP) 13 extension mapping for the provisioning of Internationalized Domain 14 Names (IDN) stored in a shared central repository. This mapping 15 extends the EPP domain name mapping to provide additional features 16 required to implement registrations of domain names in characters 17 sets other than ASCII. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 17, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction 54 2. Conventions Used in This Document 55 3. EPP Command Mapping 56 3.1. EPP Query Commands 57 3.1.1. EPP Command 58 3.2. EPP Transform Commands 59 3.2.1. EPP Command 60 3.3. Formal Syntax 61 4. IANA Considerations 62 5. Security Considerations 63 6. References 64 6.1. Normative References 65 6.2. Informational References 66 Authors' Addresses 68 1. Introduction 70 The EPP protocol provides a complete description of EPP command and 71 response structures. A thorough understanding of the base protocol 72 specification is necessary to understand the mapping described in 73 this document. 75 This document is written in consideration with the Guidelines for 76 Extending the Extensible Provisioning Protocol as defined in 77 [RFC3735]. 79 To comply with the Guidelines for the Implementation of 80 Internationalized Domain Names [1], it is required to associate each 81 label to be registered with a single script, as defined by the code 82 division of the Unicode code chart. This requirement imposes a 83 challenge for registries using the EPP protocol, since there is no 84 such field currently in the domain name mapping to allow for this 85 information to be exchanged. 87 In addition, registries intending to comply with the recommendation 88 of section 4.1 [RFC5891] of the IDNA2008 protocol, which implies the 89 verification of both the name in ASCII Compatible Encoding and 90 Unicode form, will be able to do so using this extension. 92 This extension adds two additional data element to the EPP Domain 93 Name mapping, to allow for association of a domain name to an IDN 94 table identifier, and a the domain name in Unicode Normalization Form 95 C (NFC [2]). 97 2. Conventions Used in This Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 XML is case sensitive. Unless stated otherwise, XML specifications 104 and examples provided in this document MUST be interpreted in the 105 character case representation presented in order to develop a 106 conforming specification. 108 "idn-1.0" is used as an abbreviation for 109 "urn:ietf:params:xml:ns:idn-1.0". The XML namespace prefix "idn" is 110 used, but implementations MUST NOT depend on it and instead employ a 111 proper namespace-aware XML parser and serializer to interpret and 112 output the XML documents. 114 3. EPP Command Mapping 116 A detailed description of the EPP syntax and semantics can be found 117 in [RFC5730]. 119 3.1. EPP Query Commands 121 This extension does not add any elements to the EPP , , 122 or commands or responses. 124 3.1.1. EPP Command 126 This extension does not add any elements to the EPP command, 127 but does include elements in the response, when the extension has 128 been selected during a command. 130 Example command: 132 C: 133 C: 134 C: 135 C: 136 C: 138 C: xn--espaol-zwa.example.com 139 C: 140 C: 2fooBAR 141 C: 142 C: 143 C: 144 C: ABC-12345 145 C: 146 C: 148 When the info command has been processed successfully, and the domain 149 name is an IDN, the server must include in the section of 150 the EPP response an element with the following elements: 152 o A element that contains the IDN table identifier. 154 o A element that contains the domain name in Unicode NFC 155 form. 157 Example response for an authorized client: 159 S: 160 S: 161 S: 162 S: 163 S: Command completed successfully 164 S: 165 S: 166 S: 168 S: xn--espaol-zwa.example.com 169 S: EXAMPLE1-REP 170 S: 171 S: jd1234 172 S: sh8013 173 S: sh8013 174 S: 175 S: ns1.example.com 176 S: ns1.example.net 177 S: 178 S: ClientX 179 S: ClientY 180 S: 1999-04-03T22:00:00.0Z 181 S: ClientX 182 S: 1999-12-03T09:00:00.0Z 183 S: 2005-04-03T22:00:00.0Z 184 S: 2000-04-08T09:00:00.0Z 185 S: 186 S: 2fooBAR 187 S: 188 S: 189 S: 190 S: 191 S: 192 S: es 193 S: español.example.com 194 S: 195 S: 196 S: 197 S: ABC-12345 198 S: 54322-XYZ 199 S: 200 S: 201 S: 203 3.2. EPP Transform Commands 205 This extension does not add any elements to the EPP , 206 , or commands or responses. 208 3.2.1. EPP Command 210 This extension defines additional elements for the EPP 211 command. 213 If the domain name is an IDN, the EPP command MUST contain an 214 element, which MUST contain a child element 215 with the following child elements: 217 o A element that contains the IDN table identifier as 218 provided by the server. 220 o An optional element that contains the domain name to 221 be registered in Unicode NFC. 223 Example command: 225 C: 226 C: 227 C: 228 C: 229 C: 231 C: xn--espaol-zwa.example.com 232 C: 2 233 C: 234 C: ns1.example.net 235 C: ns2.example.net 236 C: 237 C: jd1234 238 C: sh8013 239 C: sh8013 240 C: 241 C: 2fooBAR 242 C: 243 C: 244 C: 245 C: 246 C: 247 C: es 248 C: español.example.com 249 C: 250 C: 251 C: 123456 252 C: 253 C: 255 The server MUST validate the name using the procedure described in 256 section 4.2 of [RFC5891]. 258 If the validation of the IDN name failed because it contained a code 259 point not available in the specified IDN table, the server MUST 260 return an EPP error 2306. 262 In the specific case that the provided did not map to 263 the provided , the server MUST respond with an EPP error 264 2005. 266 3.3. Formal Syntax 268 An EPP object mapping is specified in XML Schema notation. The 269 formal syntax presented here is a complete schema representation of 270 the object mapping suitable for automated validation of EPP XML 271 instances. 273 274 279 280 281 Extensible Provisioning Protocol v1.0 domain name extension 282 schema for IDN Table selection. 283 284 285 287 288 289 290 291 292 294 295 296 297 299 4. IANA Considerations 301 This document uses URNs to describe XML namespaces and XML schemas 302 conforming to a registry mechanism described in [RFC3688]. Two URI 303 assignments have been registered by the IANA. 305 Registration request for the contact namespace: 307 URI: urn:ietf:params:xml:ns:idn-1.0 309 Registrant Contact: See the "Author's Address" section of this 310 document. 312 XML: None. Namespace URIs do not represent an XML specification. 314 Registration request for the contact XML schema: 316 URI: urn:ietf:params:xml:schema:idn-1.0 318 Registrant Contact: See the "Author's Address" section of this 319 document. 321 XML: See the "Formal Syntax" section of this document. 323 5. Security Considerations 325 The mapping extensions described in this document do not provide any 326 security services beyond those described by EPP [RFC5730] the EPP 327 domain name mapping [RFC5731], and protocol layers used by EPP. The 328 security considerations described in these other specifications apply 329 to this specification as well. 331 6. References 333 6.1. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 339 STD 69, RFC 5730, August 2009. 341 [RFC5891] Klensin, J., "Internationalized Domain Names in 342 Applications (IDNA): Protocol", RFC 5891, August 2010. 344 6.2. Informational References 346 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 347 Provisioning Protocol (EPP)", RFC 3735, March 2004. 349 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 350 Domain Name Mapping", STD 69, RFC 5731, August 2009. 352 Authors' Addresses 354 Francisco Obispo 355 Uniregistry Corp. 356 3-110 Governors Square 357 Grand Cayman, Grand Cayman KY1-1108 358 KY 360 Phone: +194990334499 361 Email: fobispo@uniregistry.com 362 URI: http://www.uniregistry.com/ 364 Luis Enrique Munoz 365 Uniregistry Corp. 366 3-110 Governors Square 367 Grand Cayman, Grand Cayman KY1-1108 368 KY 370 Phone: +19499034226 371 Email: fobispo@uniregistry.com 372 URI: http://www.uniregistry.com/