idnits 2.17.1 draft-xie-eppext-nv-mapping-00.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 : ---------------------------------------------------------------------------- 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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 9, 2015) is 3121 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-gould-eppext-verificationcode-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force X. Jiagui 3 Internet-Draft Teleinfo 4 Intended status: Informational J. Gould 5 Expires: April 11, 2016 VeriSign, Inc. 6 L. Hongyan 7 Teleinfo 8 October 9, 2015 10 Extensible Provisioning Protocol (EPP) China Name Verification Mapping 11 draft-xie-eppext-nv-mapping-00 13 Abstract 15 This document describes an Extensible Provisioning Protocol (EPP) for 16 the provisioning and management of Name Verification (NV) stored in a 17 shared central repository in China. Specified in XML, the mapping 18 defines EPP command syntax and semantics as applied to name 19 verification. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 11, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Definitions and Object Attributes . . . . . . . . . . . . . . 4 70 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Object Attributes . . . . . . . . . . . . . . . . . . . . 4 72 3.3. Name Verification Proofs . . . . . . . . . . . . . . . . 5 73 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 6 75 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 76 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 77 4.1.3. EPP Command . . . . . . . . . . . . . . . 16 78 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 16 79 4.2.1. EPP Command . . . . . . . . . . . . . . . . 16 80 4.2.2. EPP Command . . . . . . . . . . . . . . . . 22 81 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 22 82 4.2.4. EPP Command . . . . . . . . . . . . . . . 22 83 4.2.5. EPP Command . . . . . . . . . . . . . . . . 22 84 4.3. Offline Review of Requested Actions . . . . . . . . . . . 24 85 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 86 6. Internationalization Considerations . . . . . . . . . . . . . 32 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 88 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 33 89 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 33 90 8. Security considerations . . . . . . . . . . . . . . . . . . . 34 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 92 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 34 93 10.1. draft-xie-epp-nv-mapping-00: Version 00 . . . . . . . . 34 94 11. Normative References . . . . . . . . . . . . . . . . . . . . 34 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 97 1. Introduction 99 When creating a domain name which will be stored in a shared central 100 repository, some registry administrative organizations require the 101 verification of the domain name and the real name based on legal or 102 policy requirements. 104 The domain name verification, means to verify the domain label is in 105 compliance with laws, rules and regulations. The real name 106 verification, means to verify that the registrant really exists and 107 is authorized to register a domain name. 109 The verification of this document meets the requirements in China, 110 but MAY be applicable outside of China. 112 In order to meet above requirements of the domain name registration, 113 this document describes the Extensible Provisioning Protocol (EPP) 114 Name Verification (NV) Mapping. This document is specified using the 115 Extensible Markup Language (XML) 1.0 as described in 116 [W3C.REC-xml-20040204] and XML Schema notation as described in 117 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 119 The EPP core protocol specification [RFC5730] provides a complete 120 description of EPP command and response structures. A thorough 121 understanding of the base protocol specification is necessary to 122 understand the mapping described in this document. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 "nv-1.0" in this document is used as an abbreviation for 131 urn:ietf:params:xml:ns:nv-1.0. The XML namespace prefix "nv" is 132 used, but implementations MUST NOT depend on it and instead employ a 133 proper namespace-aware XML parser and serializer to interpret and 134 output the XML documents. 136 In examples, "C:" represents lines sent by a protocol client and "S:" 137 represents lines returned by a protocol server. Indentation and 138 white space in examples are provided only to illustrate element 139 relationships and are not a REQUIRED feature of this specification. 141 XML is case sensitive. Unless stated otherwise, XML specifications 142 and examples provided in this document MUST be interpreted in the 143 character case presented to develop a conforming implementation. 145 3. Definitions and Object Attributes 147 3.1. Definitions 149 The following definitions are used in this document: 151 o Domain Name Verification(DNV), represents the verification of the 152 domain's label is in compliance with laws, rules and regulations. 154 o Real Name Verification(RNV), represents the verification of the 155 registrant(real name) is in compliance with laws, rules and 156 regulations. 158 o Name Verification(NV), represents DNV, RNV or both of them. 160 o Verification Service Provider(VSP), collects the proof of 161 materials for Name Verification(NV) and performs the verification. 163 o Verification Code, which is described in 164 [I-D.gould-eppext-verificationcode] ,is a formatted token, 165 referred to as the Verification Code Token, that is digitally 166 signed by a Verification Service Provider (VSP) using XML 167 Signature in "W3C.CR-xmldsig-core2-20120124". 169 o Signed Code, which is described in 170 [I-D.gould-eppext-verificationcode], is the XML Signature format 171 of the Verification Code. 173 o Encoded Signed Code, which is described in 174 [I-D.gould-eppext-verificationcode], is the "base64" encoded XML 175 Signature format of the Verification Code. 177 o Prohibited Name(PN), is a domain label that is prohibited from 178 registration. 180 o Restricted Name(RN), is a domain label that is restricted from 181 registration. Additional information is needed during Domain Name 182 Verification(DNV) to authorize the registration of a Restricted 183 Name. 185 3.2. Object Attributes 187 An EPP NV object has attributes and associated values that can be 188 viewed and modified by the sponsoring client or the server. This 189 section describes each attribute type in detail. The formal syntax 190 for the attribute values described here can be found in the "Formal 191 Syntax" section of this document and in the appropriate normative 192 references. 194 o Status Values. A NV object MUST always have one associated status 195 value. The Status value can be set only by the server. The 196 status value MAY be accompanied by a string of human-readable text 197 that describes the rationale for the status applied to the object. 198 The status of an object MAY change as a result of an action 199 performed by a server operator. Status Value Descriptions: 201 * pendingCompliant. The object verification is not complete and 202 is pending completion. Please refer to Section 4.3 for details 203 on handling offline review of NV objects with the 204 pendingComplaint status. 206 * compliant. The object is in compliance with the policy. 208 * nonCompliant. The object is not in compliance with the policy. 210 o Dates and Times. Date and time attribute values MUST be 211 represented in Universal Coordinated Time (UTC) using the 212 Gregorian calendar. The extended date-time form using upper case 213 "T" and "Z" characters defined in [W3C.REC-xmlschema-2-20041028] 214 MUST be used to represent date-time values, as XML Schema does not 215 support truncated date-time forms or lower case "T" and "Z" 216 characters. 218 o Authorization Information. Authorization information is 219 associated with NV objects to facilitate query operations. 220 Authorization information is assigned when a NV object is created, 221 and it might be updated in the future. This specification 222 describes password-based authorization information, though other 223 mechanisms are possible. 225 3.3. Name Verification Proofs 227 When performing name verification, some Verification Service 228 Providers(VSP) MAY need to collect the proof of materials to verify 229 the real name of a registrant. The proof of materials is defined 230 with the following enumerated values: 232 o "poc" for Proof of Citizen(POC). The POC represents the citizen's 233 identification card(ID) material. 235 o "poe" for Proof of Enterprise(POE). The POE represents the 236 Organization Code Certificate(OCC) or Business License(BL) 237 material. 239 o "poot" for Proof of Other Types(POOT). The POOT represents other 240 certificate materials except the POC and POE. 242 4. EPP Command Mapping 244 A detailed description of the EPP syntax and semantics can be found 245 in the EPP core protocol specification [RFC5730]. The command 246 mappings described here are specifically for use in provisioning and 247 managing NV via EPP. 249 4.1. EPP Query Commands 251 EPP provides three commands to retrieve NV information: 252 determine if an object is known to the server, to retrieve 253 detailed information associated with an object, and to 254 retrieve object transfer status information. 256 4.1.1. EPP Command 258 The EPP command is used to determine if the domain's label 259 can be used to create a DNV object. It provides a hint that allows a 260 client to anticipate the success or failure of creating a DNV object 261 using the command. 263 In addition to the standard EPP command elements, the command 264 MUST contain a element that identifies the nv namespace. 265 The element contains the following child elements: 267 o One or more elements that contain the domain labels to 268 be queried. 270 Example command: 272 C: 273 C: 274 C: 275 C: 276 C: 277 C: example1 278 C: example2 279 C: example3 280 C: 281 C: 282 C: ABC-12345 283 C: 284 C: 286 When a command has been processed successfully, the EPP 287 element MUST contain a child element that 288 identifies the NV namespace. The element contains one 289 or more elements that contain the following child elements: 291 o A element that contains the queried domain label. This 292 element MUST contain an "avail" attribute whose value indicates 293 object availability (can it be created or not) at the moment the 294 command was completed. A value of "1" or "true" means 295 that the object can be created. A value of "0" or "false" means 296 that the object can not be created. This element SHOULD contain a 297 "restricted" attribute whose value indicates this name is a RN or 298 not, with a default value of "0". A value of "1" or "true" means 299 that the object is a RN Name. A value of "0" or "false" means 300 that the object is not restricted. 302 o An OPTIONAL element that MAY be provided when an 303 object cannot be created. If present, this element contains 304 server-specific text to help explain why the object cannot be 305 created. This text MUST be represented in the response language 306 previously negotiated with the client; an OPTIONAL "lang" 307 attribute MAY be present to identify the language if the 308 negotiated value is something other than the default value of "en" 309 (English). 311 Example response: 313 S: 314 S: 315 S: 316 S: 317 S: Command completed successfully 318 S: 319 S: 320 S: 322 S: 323 S: example1 324 S: 325 S: 326 S: example2 327 S: In Prohibited Lists. 328 S: 329 S: 330 S: example3 331 S: 332 S: 333 S: 334 S: 335 S: ABC-12345 336 S: 54322-XYZ 337 S: 338 S: 339 S: 341 An EPP error response MUST be returned if a command cannot be 342 processed for any reason. 344 4.1.2. EPP Command 346 The EPP command is used to retrieve information associated 347 with a NV object. The response to this command MAY vary depending on 348 the identity of the querying client, and server policy towards 349 unauthorized clients. If the querying client is the sponsoring 350 client, all available information MUST be returned. If the querying 351 client is not the sponsoring client but the client provides valid 352 authorization information, all available information MUST be 353 returned. If the querying client is not the sponsoring client and 354 the client does not provide valid authorization information, server 355 policy determines which OPTIONAL elements are returned. 357 In addition to the standard EPP command elements, the command 358 MUST contain a element that identifies the NV namespace. 359 The element contains the following child elements: 361 o A element that contains the Verification Code Token 362 value. An "type" attribute MUST be used to identify the type of 363 the query(Signed Code or Input Data). If the type is 364 "signedCode", the successful response of the server MUST be the 365 Signed Code of the verification code. If the type is "input", the 366 successful response of the server MUST be the verification input 367 data and the verification status. 369 o An OPTIONAL element that contains authorization 370 information associated with the NV object. If this element is not 371 provided or if the authorization information is invalid, server 372 policy determines if the command is rejected or if response 373 information will be returned to the client. 375 Example command to query the signed code: 377 C: 378 C: 379 C: 380 C: 381 C: 383 C: abc-123 384 C: 385 C: 386 C: ABC-12345 387 C: 388 C: 390 Example command to query the input data: 392 C: 393 C: 394 C: 395 C: 396 C: 398 C: abc-123 399 C: 400 C: 401 C: ABC-12345 402 C: 403 C: 405 Example command with authorization information: 407 C: 408 C: 409 C: 410 C: 411 C: 413 C: abc-123 414 C: 415 C: 2fooBAR 416 C: 417 C: 418 C: 419 C: ABC-12345 420 C: 421 C: 422 When an command has been processed successfully, the EPP 423 element MUST contain a child element that 424 identifies the nv namespace. The element has two forms 425 based on the query type provided in the command: the Signed Code Form 426 and the Input Form. The child element of the element is 427 defined for each form. 429 The Signed Code Form is returned when the command "type" attribute is 430 set to "signedCode". The element is used for the 431 Signed Code Form that contains the following child elements: 433 o A element that contains the Verification Code Token 434 value of the signed code with the "type" attribute to indicate the 435 type of NV object. The "type" attribute value of "domain" 436 indicates a DNV object and "real-name" indicates a RNV object. 438 o An OPTIONAL element that contains the current status 439 using the status values defined in Section 3.2. 441 o A element include: 443 * A element that is a "base64" encoded 444 form of the digitally signed as 445 defined in [I-D.gould-eppext-verificationcode]. 447 Example response of a Signed Code: 449 S: 450 S: 451 S: 452 S: 453 S: Command completed successfully 454 S: 455 S: 456 S: 457 S: 458 S: abc-123 459 S: 460 S: 461 S: 2fooBAR 462 S: 463 S: 464 S:ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 465 S:OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht 466 S:bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD 467 S:b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp 468 S:ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3 469 S:dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg 470 S:PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53 471 S:My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0 472 S:aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp 473 S:Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk 474 S:Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y 475 S:aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 476 S:ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l 477 S:dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu 478 S:YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P 479 S:UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy 480 S:ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0 481 S:UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa 482 S:Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3 483 S:amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ 484 S:bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr 485 S:CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa 486 S:d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm 487 S:SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z 488 S:VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+ 489 S:CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB 490 S:ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF 491 S:d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k 492 S:bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF 493 S:eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB 494 S:d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr 495 S:R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG 496 S:UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G 497 S:c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw 498 S:QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa 499 S:cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2 500 S:NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr 501 S:MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ 502 S:ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n 503 S:WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF 504 S:QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH 505 S:Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB 506 S:Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj 507 S:SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w 508 S:LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK 509 S:VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi 510 S:R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK 511 S:SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB 512 S:Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi 513 S:bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC 514 S:MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz 515 S:REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr 516 S:aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W 517 S:N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy 518 S:aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts 519 S:L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt 520 S:TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn 521 S:UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE 522 S:YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp 523 S:b25Db2RlOnNpZ25lZENvZGU+Cg== 524 S: 525 S: 526 S: 527 S: 528 S: 529 S: ABC-12345 530 S: 54322-XYZ 531 S: 532 S: 533 S: 535 The Input Code Form is returned when the command "type" attribute is 536 set to "input". The element is used for the Input Form 537 and contains a choice of two different child elements dependent on 538 the type of NV object that matches the in the command. The 539 child element is used for a DNV object and the 540 child element is used for a RNV object. 542 The element is used for a DNV object and contains the 543 following child elements: 545 o A element that contains the label of the domain. 547 o An OPTIONAL element containing the Verification Code 548 Token value of a RNV object used for verification of a Restricted 549 Name. 551 Example response of a DNV: 553 S: 554 S: 555 S: 556 S: 557 S: Command completed successfully 558 S: 559 S: 560 S: 561 S: 562 S: 563 S: example 564 S: 565 S: 566 S: 2fooBAR 567 S: 568 S: 569 S: 570 S: 571 S: 572 S: ABC-12345 573 S: 54322-XYZ 574 S: 575 S: 576 S: 578 The element is used for a RNV object. The "role" attribute 579 MUST be used to identify the role of the RNV object with the possible 580 values of "person" or "org". 582 The element contains the following child elements: 584 o A element that contains the full name of the contact. 586 o A element that contains the citizen or the organization 587 ID of the contact. 589 o A element that contains the proof material type of 590 the contact based on the enumerated values defined in Name 591 Verification Proofs (Section 3.3). 593 o Zero or more elements that contains the following 594 child elements: 596 * A element contains the type of the file. 598 * A element contains the "base64" encoded 599 content of the file. 601 Example response of a RNV person: 603 S: 604 S: 605 S: 606 S: 607 S: Command completed successfully 608 S: 609 S: 610 S: 611 S: 612 S: 613 S: John Xie 614 S: 1234567890 615 S: poc 616 S: 617 S: jpg 618 S: EABQRAQAAAAAAAAAAAAAAAAAAAAD 619 S: 620 S: 621 S: 622 S: 623 S: 2fooBAR 624 S: 625 S: 626 S: 627 S: 628 S: 629 S: ABC-12345 630 S: 54322-XYZ 631 S: 632 S: 633 S: 635 Example response of a RNV organization: 637 S: 638 S: 639 S: 640 S: 641 S: Command completed successfully 642 S: 643 S: 644 S: 645 S: 646 S: 647 S: John Xie 648 S: 1234567890 649 S: poe 650 S: 651 S: jpg 652 S: EABQRAQAAAAAAAAAAAAAAAAAAAAD 653 S: 654 S: 655 S: 656 S: 657 S: 2fooBAR 658 S: 659 S: 660 S: 661 S: 662 S: 663 S: ABC-12345 664 S: 54322-XYZ 665 S: 666 S: 667 S: 669 A server with a different information-return policy MAY provide less 670 information in a response for an unauthorized client. 672 An EPP error response MUST be returned if an command cannot be 673 processed for any reason. 675 4.1.3. EPP Command 677 Transfer semantics do not apply to Name Verification (NV) objects, so 678 there is no mapping defined for the EPP command. 680 4.2. EPP Transform Commands 682 EPP provides five commands to transform NV objects: to 683 create an instance of an object, to delete an instance of an 684 object, to extend the validity period of an object, 685 to manage object sponsorship changes, and to 686 change information associated with an object. 688 4.2.1. EPP Command 690 The EPP command provides a transform operation that allows a 691 client to create an NV object. In addition to the standard EPP 692 command elements, the command MUST contain a 693 element that identifies the NV namespace. The elements 694 contains a choice of two different child elements dependent on the 695 type of NV object to create. The child element is used to 696 create a DNV object and the child element is used to create 697 a RNV object. AN element contains authorization 698 information to be associated with the NV object. 700 o The element is used for a DNV object and contains the 701 following child elements: 703 * A element that contains the label of the domain. 705 * An OPTIONAL element containing the Verification 706 Code Token value of a RNV object used for verification of a 707 Restricted Name. 709 o The element is used for a RNV object. The "role" 710 attribute MUST be used to identify the role of the RNV object with 711 the possible values of "person" or "org". The element 712 contains the following child elements: 714 * A element that contains the full name of the contact. 716 * A element that contains the citizen or the 717 organization ID of the contact. 719 * A element that contains the proof material type 720 of the contact based on the enumerated values defined in Name 721 Verification Proofs (Section 3.3). 723 * Zero or more elements that contains the following 724 child elements: 726 + A element contains the type of the file. 728 + A element contains the "base64" encoded 729 content of the file. 731 Example command for a DNV object: 733 C: 734 C: 735 C: 736 C: 737 C: 738 C: 739 C: example 740 C: 741 C: 742 C: 2fooBAR 743 C: 744 C: 745 C: 746 C: ABC-12345 747 C: 748 C: 750 Example command for a RNV person object: 752 C: 753 C: 754 C: 755 C: 756 C: 757 C: 758 C: John Xie 759 C: 1234567890 760 C: poe 761 C: 762 C: jpg 763 C: EABQRAQAAAAAAAAAAAAAAAAAAAAD 764 C: 765 C: 766 C: 767 C: 768 C: 2fooBAR 769 C: 770 C: 771 C: 772 C: ABC-12345 773 C: 774 C: 776 Example command for an RNV organization: 778 C: 779 C: 780 C: 781 C: 782 C: 783 C: 784 C: John Xie 785 C: 1234567890 786 C: poe 787 C: 788 C: jpg 789 C: EABQRAQAAAAAAAAAAAAAAAAAAAAD 790 C: 791 C: 792 C: 793 C: 794 C: 2fooBAR 795 C: 796 C: 797 C: 798 C: ABC-12345 799 C: 800 C: 802 When a command has been processed successfully, the EPP 803 element MUST contain a child element that 804 identifies the nv namespace. element contains the either 805 a element on success or a element on 806 failure. 808 o The element contains the following child elements: 810 * A element that contains the id of the verification 811 code with the required "type" attribute that defines the type 812 of the verification code. 814 * A element that contains the current status using 815 the status values defined in Section 3.2. 817 * A element that contains the date and time of nv 818 object creation. 820 * A element include: 822 + A element that is a "base64" encoded 823 form of the digitally signed 824 as defined in [I-D.gould-eppext-verificationcode]. 826 o The element contains the following child elements: 828 * A element that contains the current status using 829 the status values defined in Section 3.2. 831 * A element containing a human-readable description of 832 the reason of the failure. The language of the response is 833 identified via an OPTIONAL "lang" attribute. If not specified, 834 the default attribute value MUST be "en" (English). 836 Example response of success: 838 S: 839 S: 840 S: 841 S: 842 S: Command completed successfully 843 S: 844 S: 845 S: 846 S: 847 S: abc-123 848 S: 849 S: 2015-08-17T22:00:00.0Z 850 S: 851 S:ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 852 S:OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht 853 S:bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD 854 S:b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp 855 S:ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3 856 S:dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg 857 S:PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53 858 S:My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0 859 S:aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp 860 S:Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk 861 S:Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y 862 S:aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 863 S:ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l 864 S:dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu 865 S:YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P 866 S:UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy 867 S:ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0 868 S:UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa 869 S:Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3 870 S:amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ 871 S:bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr 872 S:CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa 873 S:d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm 874 S:SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z 875 S:VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+ 876 S:CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB 877 S:ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF 878 S:d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k 879 S:bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF 880 S:eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB 881 S:d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr 882 S:R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG 883 S:UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G 884 S:c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw 885 S:QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa 886 S:cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2 887 S:NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr 888 S:MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ 889 S:ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n 890 S:WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF 891 S:QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH 892 S:Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB 893 S:Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj 894 S:SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w 895 S:LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK 896 S:VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi 897 S:R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK 898 S:SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB 899 S:Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi 900 S:bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC 901 S:MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz 902 S:REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr 903 S:aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W 904 S:N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy 905 S:aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts 906 S:L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt 907 S:TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn 908 S:UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE 909 S:YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp 910 S:b25Db2RlOnNpZ25lZENvZGU+Cg== 911 S: 912 S: 913 S: 914 S: 915 S: 916 S: ABC-12345 917 S: 54321-XYZ 918 S: 919 S: 920 S: 922 Example response of failed: 924 S: 925 S: 926 S: 927 S: 928 S: Command completed successfully 929 S: 930 S: 931 S: 932 S: 933 S: 934 S: The name of the object is not correct. 935 S: 936 S: 937 S: 938 S: 939 S: ABC-12345 940 S: 54321-XYZ 941 S: 942 S: 943 S: 945 An EPP error response MUST be returned if a command cannot 946 be processed for any reason. 948 4.2.2. EPP Command 950 Delete semantics do not apply to Name Verification (NV) objects, so 951 there is no mapping defined for the EPP command. 953 4.2.3. EPP Command 955 Renew semantics do not apply to Name Verification (NV) objects, so 956 there is no mapping defined for the EPP command. 958 4.2.4. EPP Command 960 Transfer semantics do not apply to Name Verification (NV) objects, so 961 there is no mapping defined for the EPP command. 963 4.2.5. EPP Command 965 The EPP command provides a transform operation that allows a 966 client to modify the attributes of a NV object. In addition to the 967 standard EPP command elements, the command MUST contain a 968 element that identifies the NV namespace. The 969 element contains the following child elements: 971 o A element that contains the code of the a NV object to 972 be updated. 974 o A element that contains object attribute values to be 975 changed. 977 A element contains the following child elements: 979 o A element that contains authorization information 980 associated with the NV object. This mapping includes a password- 981 based authentication mechanism, but the schema allows new 982 mechanisms to be defined in new schemas. 984 Example command: 986 C: 987 C: 988 C: 989 C: 990 C: 991 C: abc-123 992 C: 993 C: 994 C: 2BARfoo 995 C: 996 C: 997 C: 998 C: 999 C: ABC-12345 1000 C: 1001 C: 1003 When an command has been processed successfully, 1004 a server MUST respond with an EPP response with no 1005 element. 1007 Example response: 1009 S: 1010 S: 1011 S: 1012 S: 1013 S: Command completed successfully 1014 S: 1015 S: 1016 S: ABC-12345 1017 S: 54321-XYZ 1018 S: 1019 S: 1020 S: 1022 An EPP error response MUST be returned if an 1023 command cannot be processed for any reason. 1025 4.3. Offline Review of Requested Actions 1027 Commands are processed by a server in the order they are received 1028 from a client. Though an immediate response confirming receipt and 1029 processing of the command is produced by the server, a server 1030 operator MAY perform an offline review of requested transform 1031 commands before completing the requested action. In such situations, 1032 the response from the server MUST clearly note that the transform 1033 command has been received and processed but that the requested action 1034 is pending. The status of the corresponding object MUST clearly 1035 reflect processing of the pending action. The server MUST notify the 1036 client when offline processing of the action has been completed. 1038 Examples describing a command that requires offline review 1039 are included here. Note the result code and message returned in 1040 response to the command. 1042 S: 1043 S: 1044 S: 1045 S: 1046 S: Command completed successfully; action pending 1047 S: 1048 S: 1049 S: 1051 S: 1052 S: abc-123 1053 S: 1054 S: 2015-09-03T22:00:00.0Z 1055 S: 1056 S: 1057 S: 1058 S: 1059 S: ABC-12345 1060 S: 54321-XYZ 1061 S: 1062 S: 1063 S: 1065 The status of the NV object after returning this response MUST 1066 include "pendingCompliant". The server operator reviews the request 1067 offline, and informs the client of the outcome of the review either 1068 by queuing a service message for retrieval via the command or 1069 by using an out-of-band mechanism to inform the client of the outcome 1070 of the review. 1072 The service message MUST contain text that describes the notification 1073 in the child element of the response element. In 1074 addition, the EPP element MUST contain a child 1075 element that identifies the NV namespace. The element 1076 contains the following child elements: 1078 A element that contains the code of the a NV object. 1080 A element that contains the current status 1081 descriptors associated with the NV. 1083 A element containing a human-readable description of the 1084 result. The language of the response is identified via an 1085 OPTIONAL "lang" attribute. If not specified, the default 1086 attribute value MUST be "en" (English). 1088 A element that contains the date and time describing 1089 when review of the requested action was completed. 1091 Example "review completed" service message: 1093 S: 1094 S: 1095 S: 1096 S: 1097 S: Command completed successfully; ack to dequeue 1098 S: 1099 S: 1100 S: 2015-09-04T22:01:00.0Z 1101 S: Pending action completed successfully. 1102 S: 1103 S: 1104 S: 1106 S: abc-123 1107 S: 1108 S: The object has passed verification, 1109 S: signed code was generated. 1110 S: 2015-09-04T22:00:00.0Z 1111 S: 1112 S: 1113 S: 1114 S: BCD-23456 1115 S: 65432-WXY 1116 S: 1117 S: 1118 S: 1120 5. Formal Syntax 1122 An EPP object NV mapping is specified in XML Schema notation. The 1123 formal syntax presented here is a complete schema representation of 1124 the object mapping suitable for automated validation of EPP XML 1125 instances. The BEGIN and END tags are not part of the schema; they 1126 are used to note the beginning and ending of the schema for URI 1127 registration purposes. 1129 BEGIN 1130 1132 1141 1142 1143 Extensible Provisioning Protocol v1.0 1144 Name Verification provisioning schema. 1145 1146 1148 1151 1152 1153 1156 1159 1160 1161 1162 1164 1167 1168 1169 1171 1172 1174 1177 1178 1179 1180 1181 1182 1183 1184 1185 1187 1188 1189 1190 1191 1193 1194 1195 1196 1197 1198 1200 1201 1203 1205 1206 1207 1208 1209 1210 1211 1213 1214 1215 1216 1217 1218 1220 1221 1222 1223 1224 1225 1227 1228 1229 1230 1231 1232 1234 1235 1236 1237 1238 1239 1241 1244 1245 1246 1247 1249 1250 1252 1254 1255 1256 1257 1258 1259 1261 1264 1265 1266 1267 1268 1269 1271 1274 1275 1276 1277 1278 1280 1283 1284 1285 1286 1287 1288 1290 1293 1294 1295 1296 1298 1301 1302 1303 1305 1306 1308 1309 1310 1311 1313 1314 1316 1317 1318 1319 1321 1323 1324 1325 1327 1330 1331 1332 1333 1334 1335 1336 1338 1339 1340 1341 1342 1343 1345 1346 1348 1349 1350 1351 1352 1353 1355 1356 1357 1359 1360 1361 1362 1364 1367 1368 1369 1370 1371 1372 1373 1374 1376 1379 1380 1381 1382 1383 1384 1385 1386 1388 1389 1390 1391 1393 1394 1396 1397 1399 1400 1401 1402 1404 1405 1406 1407 1412 1413 1414 1415 1417 1419 1420 1421 1423 1424 1425 1426 1427 1428 1429 1431 1434 1435 END 1437 6. Internationalization Considerations 1439 EPP is represented in XML, which provides native support for encoding 1440 information using the Unicode character set and its more compact 1441 representations including UTF-8. Conformant XML processors recognize 1442 both UTF-8 and UTF-16. Though XML includes provisions to identify 1443 and use other character encodings through use of an "encoding" 1444 attribute in an declaration, use of UTF-8 is RECOMMENDED. 1446 As an extension of the EPP, the elements, element content described 1447 in this document MUST inherit the internationalization conventions 1448 used to represent higher-layer domain and core protocol structures 1449 present in an XML instance that includes this extension. 1451 7. IANA Considerations 1453 7.1. XML Namespace 1455 This document uses URNs to describe XML namespaces and XML schemas 1456 conforming to a registry mechanism described in [RFC3688]. IANA is 1457 requested to assignment the following two URI. 1459 Registration request for the NV namespace: 1461 o URI: urn:ietf:params:xml:ns:nv-1.0 1463 o Registrant Contact: See the "Author's Address" section of this 1464 document. 1466 o XML: None. Namespace URI does not represent an XML specification. 1468 Registration request for the NV XML schema: 1470 o URI: urn:ietf:params:xml:schema:nv-1.0 1472 o Registrant Contact: See the "Author's Address" section of this 1473 document. 1475 o XML: See the "Formal Syntax" section of this document. 1477 7.2. EPP Extension Registry 1479 The EPP extension described in this document should be registered by 1480 the IANA in the EPP Extension Registry described in [RFC7451]. The 1481 details of the registration are as follows: 1483 Name of Extension: Extensible Provisioning Protocol (EPP) China Name 1484 Verification Mapping 1486 Document status: Informational 1488 Reference: (insert reference to RFC version of this document) 1490 Registrant Name and Email Address: IESG, 1492 TLDs: Any 1494 IPR Disclosure: None 1496 Status: Active 1498 Notes: None 1500 8. Security considerations 1502 Verification Code Tokens are digitally signed using XML Signature 1503 technology. The security considerations described in Section 12 of 1504 the W3C XML Signature Syntax and Processing Candidate Recommendation 1505 [W3C.CR-xmldsig-core2-20120124] apply to this specification as well. 1506 The object mapping described in this document does not provide any 1507 other security services or introduce any additional considerations 1508 beyond those described by [RFC5730] or those caused by the protocol 1509 layers used by EPP. 1511 9. Acknowledgements 1513 The authors especially thank the author of [RFC5730]. 1515 Useful comments and contributions were made by TBD. 1517 10. Change History 1519 RFC Editor: Please remove this section. 1521 10.1. draft-xie-eppext-nv-mapping-00: Version 00 1523 o First draft. 1525 11. Normative References 1527 [I-D.gould-eppext-verificationcode] 1528 Gould, J., "Verification Code Extension for the Extensible 1529 Provisioning Protocol (EPP)", draft-gould-eppext- 1530 verificationcode-00 (work in progress), September 2015. 1532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1533 Requirement Levels", BCP 14, RFC 2119, March 1997. 1535 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1536 January 2004. 1538 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1539 STD 69, RFC 5730, August 2009. 1541 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1542 Provisioning Protocol", RFC 7451, February 2015. 1544 [W3C.CR-xmldsig-core2-20120124] 1545 Bartel, M., Boyer, J., Fox, B., LaMacchia, B., and E. 1546 Simon, ""XML Signature Syntax and Processing Version 2.0", 1547 W3C Candidate Recommendation 24 January 2012", January 1548 2012, 1549 . 1551 [W3C.REC-xml-20040204] 1552 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1553 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 1554 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1555 20040204", February 2004, 1556 . 1558 [W3C.REC-xmlschema-1-20041028] 1559 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1560 ""XML Schema Part 1: Structures Second Edition", World 1561 Wide Web Consortium Recommendation REC-xmlschema- 1562 1-20041028", October 2004, 1563 . 1565 [W3C.REC-xmlschema-2-20041028] 1566 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 1567 Second Edition", World Wide Web Consortium Recommendation 1568 REC-xmlschema-2-20041028", October 2004, 1569 . 1571 Authors' Addresses 1573 Xie Jiagui 1574 Teleinfo 1575 1#-21,gaolizhang Street,Haidian District 1576 Beijing, Beijing 100095 1577 China 1579 Phone: +86 10 5884 6931 1580 Email: xiejiagui@teleinfo.cn 1582 James Gould 1583 VeriSign, Inc. 1584 12061 Bluemont Way 1585 Reston, VA 20190 1586 US 1588 Email: jgould@verisign.com 1589 URI: http://www.verisign.com 1590 Liu Hongyan 1591 Teleinfo 1592 1#-21,gaolizhang Street,Haidian District 1593 Beijing, Beijing 100095 1594 China 1596 Phone: +86 10 5884 6931 1597 Email: liuhongyan@teleinfo.cn