idnits 2.17.1 draft-xie-eppext-nv-mapping-02.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 (May 5, 2016) is 2907 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-03 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: November 6, 2016 VeriSign, Inc. 6 L. Hongyan 7 Teleinfo 8 May 5, 2016 10 Extensible Provisioning Protocol (EPP) China Name Verification Mapping 11 draft-xie-eppext-nv-mapping-02 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 November 6, 2016. 38 Copyright Notice 40 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 33 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 88 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 33 89 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 34 90 8. Security considerations . . . . . . . . . . . . . . . . . . . 34 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 92 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 35 93 10.1. draft-xie-eppext-nv-mapping-00: Version 00 . . . . . . . 35 94 10.2. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 35 95 10.3. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 35 96 11. Normative References . . . . . . . . . . . . . . . . . . . . 35 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 99 1. Introduction 101 When creating a domain name which will be stored in a shared central 102 repository, some registry administrative organizations require the 103 verification of the domain name and the real name based on legal or 104 policy requirements. 106 The domain name verification, means to verify the domain label is in 107 compliance with laws, rules and regulations. The real name 108 verification, means to verify that the registrant really exists and 109 is authorized to register a domain name. 111 The verification of this document meets the requirements in China, 112 but MAY be applicable outside of China. 114 In order to meet above requirements of the domain name registration, 115 this document describes the Extensible Provisioning Protocol (EPP) 116 Name Verification (NV) Mapping. This document is specified using the 117 Extensible Markup Language (XML) 1.0 as described in 118 [W3C.REC-xml-20040204] and XML Schema notation as described in 119 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 121 The EPP core protocol specification [RFC5730] provides a complete 122 description of EPP command and response structures. A thorough 123 understanding of the base protocol specification is necessary to 124 understand the mapping described in this document. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 "nv-1.0" in this document is used as an abbreviation for 133 urn:ietf:params:xml:ns:nv-1.0. The XML namespace prefix "nv" is 134 used, but implementations MUST NOT depend on it and instead employ a 135 proper namespace-aware XML parser and serializer to interpret and 136 output the XML documents. 138 In examples, "C:" represents lines sent by a protocol client and "S:" 139 represents lines returned by a protocol server. Indentation and 140 white space in examples are provided only to illustrate element 141 relationships and are not a REQUIRED feature of this specification. 143 XML is case sensitive. Unless stated otherwise, XML specifications 144 and examples provided in this document MUST be interpreted in the 145 character case presented to develop a conforming implementation. 147 3. Definitions and Object Attributes 149 3.1. Definitions 151 The following definitions are used in this document: 153 o Domain Name Verification(DNV), represents the verification of the 154 domain's label is in compliance with laws, rules and regulations. 156 o Real Name Verification(RNV), represents the verification of the 157 registrant(real name) is in compliance with laws, rules and 158 regulations. 160 o Name Verification(NV), represents DNV, RNV or both of them. 162 o Verification Service Provider(VSP), collects the proof of 163 materials for Name Verification(NV) and performs the verification. 165 o Verification Code, which is described in 166 [I-D.gould-eppext-verificationcode] ,is a formatted token, 167 referred to as the Verification Code Token, that is digitally 168 signed by a Verification Service Provider (VSP) using XML 169 Signature in "W3C.CR-xmldsig-core2-20120124". 171 o Signed Code, which is described in 172 [I-D.gould-eppext-verificationcode], is the XML Signature format 173 of the Verification Code. 175 o Encoded Signed Code, which is described in 176 [I-D.gould-eppext-verificationcode], is the "base64" encoded XML 177 Signature format of the Verification Code. 179 o Prohibited Name(PN), is a domain label that is prohibited from 180 registration. 182 o Restricted Name(RN), is a domain label that is restricted from 183 registration. Additional information is needed during Domain Name 184 Verification(DNV) to authorize the registration of a Restricted 185 Name. 187 3.2. Object Attributes 189 An EPP NV object has attributes and associated values that can be 190 viewed and modified by the sponsoring client or the server. This 191 section describes each attribute type in detail. The formal syntax 192 for the attribute values described here can be found in the "Formal 193 Syntax" section of this document and in the appropriate normative 194 references. 196 o Status Values. A NV object MUST always have one associated status 197 value. The Status value can be set only by the server. The 198 status value MAY be accompanied by a string of human-readable text 199 that describes the rationale for the status applied to the object. 200 The status of an object MAY change as a result of an action 201 performed by a server operator. Status Value Descriptions: 203 * pendingCompliant. The object verification is not complete and 204 is pending completion. Please refer to Section 4.3 for details 205 on handling offline review of NV objects with the 206 pendingComplaint status. 208 * compliant. The object is in compliance with the policy. 210 * nonCompliant. The object is not in compliance with the policy. 212 o Dates and Times. Date and time attribute values MUST be 213 represented in Universal Coordinated Time (UTC) using the 214 Gregorian calendar. The extended date-time form using upper case 215 "T" and "Z" characters defined in [W3C.REC-xmlschema-2-20041028] 216 MUST be used to represent date-time values, as XML Schema does not 217 support truncated date-time forms or lower case "T" and "Z" 218 characters. 220 o Authorization Information. Authorization information is 221 associated with NV objects to facilitate query operations. 222 Authorization information is assigned when a NV object is created, 223 and it might be updated in the future. This specification 224 describes password-based authorization information, though other 225 mechanisms are possible. 227 3.3. Name Verification Proofs 229 When performing name verification, some Verification Service 230 Providers(VSP) MAY need to collect the proof of materials to verify 231 the real name of a registrant. The proof of materials is defined 232 with the following enumerated values: 234 o "poc" for Proof of Citizen(POC). The POC represents the citizen's 235 identification card(ID) material. 237 o "poe" for Proof of Enterprise(POE). The POE represents the 238 Organization Code Certificate(OCC) or Business License(BL) 239 material. 241 o "poot" for Proof of Other Types(POOT). The POOT represents other 242 certificate materials except the POC and POE. 244 4. EPP Command Mapping 246 A detailed description of the EPP syntax and semantics can be found 247 in the EPP core protocol specification [RFC5730]. The command 248 mappings described here are specifically for use in provisioning and 249 managing NV via EPP. 251 4.1. EPP Query Commands 253 EPP provides three commands to retrieve NV information: 254 determine if an object is known to the server, to retrieve 255 detailed information associated with an object, and to 256 retrieve object transfer status information. 258 4.1.1. EPP Command 260 The EPP command is used to determine if the domain's label 261 can be used to create a DNV object. It provides a hint that allows a 262 client to anticipate the success or failure of creating a DNV object 263 using the command. 265 In addition to the standard EPP command elements, the command 266 MUST contain a element that identifies the nv namespace. 267 The element contains the following child elements: 269 o One or more elements that contain the domain labels to 270 be queried. 272 Example command: 274 C: 275 C: 276 C: 277 C: 278 C: 279 C: example1 280 C: example2 281 C: example3 282 C: 283 C: 284 C: ABC-12345 285 C: 286 C: 288 When a command has been processed successfully, the EPP 289 element MUST contain a child element that 290 identifies the NV namespace. The element contains one 291 or more elements that contain the following child elements: 293 o A element that contains the queried domain label. This 294 element MUST contain an "avail" attribute whose value indicates 295 object availability (can it be created or not) at the moment the 296 command was completed. A value of "1" or "true" means 297 that the object can be created. A value of "0" or "false" means 298 that the object can not be created. This element SHOULD contain a 299 "restricted" attribute whose value indicates this name is a RN or 300 not, with a default value of "0". A value of "1" or "true" means 301 that the object is a RN Name. A value of "0" or "false" means 302 that the object is not restricted. 304 o An OPTIONAL element that MAY be provided when an 305 object cannot be created. If present, this element contains 306 server-specific text to help explain why the object cannot be 307 created. This text MUST be represented in the response language 308 previously negotiated with the client; an OPTIONAL "lang" 309 attribute MAY be present to identify the language if the 310 negotiated value is something other than the default value of "en" 311 (English). 313 Example response: 315 S: 316 S: 317 S: 318 S: 319 S: Command completed successfully 320 S: 321 S: 322 S: 324 S: 325 S: example1 326 S: 327 S: 328 S: example2 329 S: In Prohibited Lists. 330 S: 331 S: 332 S: example3 333 S: 334 S: 335 S: 336 S: 337 S: ABC-12345 338 S: 54322-XYZ 339 S: 340 S: 341 S: 343 An EPP error response MUST be returned if a command cannot be 344 processed for any reason. 346 4.1.2. EPP Command 348 The EPP command is used to retrieve information associated 349 with a NV object. The response to this command MAY vary depending on 350 the identity of the querying client, and server policy towards 351 unauthorized clients. If the querying client is the sponsoring 352 client, all available information MUST be returned. If the querying 353 client is not the sponsoring client but the client provides valid 354 authorization information, all available information MUST be 355 returned. If the querying client is not the sponsoring client and 356 the client does not provide valid authorization information, server 357 policy determines which OPTIONAL elements are returned. 359 In addition to the standard EPP command elements, the command 360 MUST contain a element that identifies the NV namespace. 361 The element contains the following child elements: 363 o A element that contains the Verification Code Token 364 value. An "type" attribute MUST be used to identify the type of 365 the query(Signed Code or Input Data). If the type is 366 "signedCode", the successful response of the server MUST be the 367 Signed Code of the verification code. If the type is "input", the 368 successful response of the server MUST be the verification input 369 data and the verification status. 371 o An OPTIONAL element that contains authorization 372 information associated with the NV object. If this element is not 373 provided or if the authorization information is invalid, server 374 policy determines if the command is rejected or if response 375 information will be returned to the client. 377 Example command to query the signed code: 379 C: 380 C: 381 C: 382 C: 383 C: 385 C: abc-123 386 C: 387 C: 388 C: ABC-12345 389 C: 390 C: 392 Example command to query the input data: 394 C: 395 C: 396 C: 397 C: 398 C: 400 C: abc-123 401 C: 402 C: 403 C: ABC-12345 404 C: 405 C: 407 Example command with authorization information: 409 C: 410 C: 411 C: 412 C: 413 C: 415 C: abc-123 416 C: 417 C: 2fooBAR 418 C: 419 C: 420 C: 421 C: ABC-12345 422 C: 423 C: 424 When an command has been processed successfully, the EPP 425 element MUST contain a child element that 426 identifies the nv namespace. The element has two forms 427 based on the query type provided in the command: the Signed Code Form 428 and the Input Form. The child element of the element is 429 defined for each form. 431 The Signed Code Form is returned when the command "type" attribute is 432 set to "signedCode". The element is used for the 433 Signed Code Form that contains the following child elements: 435 o A element that contains the Verification Code Token 436 value of the signed code with the "type" attribute to indicate the 437 type of NV object. The "type" attribute value of "domain" 438 indicates a DNV object and "real-name" indicates a RNV object. 440 o An OPTIONAL element that contains the current status 441 using the status values defined in Section 3.2. 443 o A element include: 445 * A element that is a "base64" encoded 446 form of the digitally signed as 447 defined in [I-D.gould-eppext-verificationcode]. 449 Example response of a Signed Code: 451 S: 452 S: 453 S: 454 S: 455 S: Command completed successfully 456 S: 457 S: 458 S: 459 S: 460 S: abc-123 461 S: 462 S: 463 S: 2fooBAR 464 S: 465 S: 466 S:ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 467 S:OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht 468 S:bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD 469 S:b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp 470 S:ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3 471 S:dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg 472 S:PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53 473 S:My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0 474 S:aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp 475 S:Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk 476 S:Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y 477 S:aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 478 S:ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l 479 S:dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu 480 S:YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P 481 S:UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy 482 S:ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0 483 S:UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa 484 S:Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3 485 S:amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ 486 S:bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr 487 S:CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa 488 S:d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm 489 S:SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z 490 S:VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+ 491 S:CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB 492 S:ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF 493 S:d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k 494 S:bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF 495 S:eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB 496 S:d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr 497 S:R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG 498 S:UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G 499 S:c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw 500 S:QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa 501 S:cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2 502 S:NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr 503 S:MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ 504 S:ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n 505 S:WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF 506 S:QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH 507 S:Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB 508 S:Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj 509 S:SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w 510 S:LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK 511 S:VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi 512 S:R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK 513 S:SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB 514 S:Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi 515 S:bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC 516 S:MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz 517 S:REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr 518 S:aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W 519 S:N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy 520 S:aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts 521 S:L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt 522 S:TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn 523 S:UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE 524 S:YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp 525 S:b25Db2RlOnNpZ25lZENvZGU+Cg== 526 S: 527 S: 528 S: 529 S: 530 S: 531 S: ABC-12345 532 S: 54322-XYZ 533 S: 534 S: 535 S: 537 The Input Code Form is returned when the command "type" attribute is 538 set to "input". The element is used for the Input Form 539 and contains a choice of two different child elements dependent on 540 the type of NV object that matches the in the command. The 541 child element is used for a DNV object and the 542 child element is used for a RNV object. 544 The element is used for a DNV object and contains the 545 following child elements: 547 o A element that contains the label of the domain. 549 o An OPTIONAL element containing the Verification Code 550 Token value of a RNV object used for verification of a Restricted 551 Name. 553 Example response of a DNV: 555 S: 556 S: 557 S: 558 S: 559 S: Command completed successfully 560 S: 561 S: 562 S: 563 S: 564 S: 565 S: example 566 S: 567 S: 568 S: 2fooBAR 569 S: 570 S: 571 S: 572 S: 573 S: 574 S: ABC-12345 575 S: 54322-XYZ 576 S: 577 S: 578 S: 580 The element is used for a RNV object. The "role" attribute 581 MUST be used to identify the role of the RNV object with the possible 582 values of "person" or "org". 584 The element contains the following child elements: 586 o A element that contains the full name of the contact. 588 o A element that contains the citizen or the organization 589 ID of the contact. 591 o A element that contains the proof material type of 592 the contact based on the enumerated values defined in Name 593 Verification Proofs (Section 3.3). 595 o Zero or more elements that contains the following 596 child elements: 598 * A element contains the type of the file. 600 * A element contains the "base64" encoded 601 content of the file. 603 Example response of a RNV person: 605 S: 606 S: 607 S: 608 S: 609 S: Command completed successfully 610 S: 611 S: 612 S: 613 S: 614 S: 615 S: John Xie 616 S: 1234567890 617 S: poc 618 S: 619 S: jpg 620 S: EABQRAQAAAAAAAAAAAAAAAAAAAAD 621 S: 622 S: 623 S: 624 S: 625 S: 2fooBAR 626 S: 627 S: 628 S: 629 S: 630 S: 631 S: ABC-12345 632 S: 54322-XYZ 633 S: 634 S: 635 S: 637 Example response of a RNV organization: 639 S: 640 S: 641 S: 642 S: 643 S: Command completed successfully 644 S: 645 S: 646 S: 647 S: 648 S: 649 S: John Xie 650 S: 1234567890 651 S: poe 652 S: 653 S: jpg 654 S: EABQRAQAAAAAAAAAAAAAAAAAAAAD 655 S: 656 S: 657 S: 658 S: 659 S: 2fooBAR 660 S: 661 S: 662 S: 663 S: 664 S: 665 S: ABC-12345 666 S: 54322-XYZ 667 S: 668 S: 669 S: 671 A server with a different information-return policy MAY provide less 672 information in a response for an unauthorized client. 674 An EPP error response MUST be returned if an command cannot be 675 processed for any reason. 677 4.1.3. EPP Command 679 Transfer semantics do not apply to Name Verification (NV) objects, so 680 there is no mapping defined for the EPP command. 682 4.2. EPP Transform Commands 684 EPP provides five commands to transform NV objects: to 685 create an instance of an object, to delete an instance of an 686 object, to extend the validity period of an object, 687 to manage object sponsorship changes, and to 688 change information associated with an object. 690 4.2.1. EPP Command 692 The EPP command provides a transform operation that allows a 693 client to create an NV object. In addition to the standard EPP 694 command elements, the command MUST contain a 695 element that identifies the NV namespace. The elements 696 contains a choice of two different child elements dependent on the 697 type of NV object to create. The child element is used to 698 create a DNV object and the child element is used to create 699 a RNV object. AN element contains authorization 700 information to be associated with the NV object. 702 o The element is used for a DNV object and contains the 703 following child elements: 705 * A element that contains the label of the domain. 707 * An OPTIONAL element containing the Verification 708 Code Token value of a RNV object used for verification of a 709 Restricted Name. 711 o The element is used for a RNV object. The "role" 712 attribute MUST be used to identify the role of the RNV object with 713 the possible values of "person" or "org". The element 714 contains the following child elements: 716 * A element that contains the full name of the contact. 718 * A element that contains the citizen or the 719 organization ID of the contact. 721 * A element that contains the proof material type 722 of the contact based on the enumerated values defined in Name 723 Verification Proofs (Section 3.3). 725 * Zero or more elements that contains the following 726 child elements: 728 + A element contains the type of the file. 730 + A element contains the "base64" encoded 731 content of the file. 733 Example command for a DNV object: 735 C: 736 C: 737 C: 738 C: 739 C: 740 C: 741 C: example 742 C: 743 C: 744 C: 2fooBAR 745 C: 746 C: 747 C: 748 C: ABC-12345 749 C: 750 C: 752 Example command for a RNV person object: 754 C: 755 C: 756 C: 757 C: 758 C: 759 C: 760 C: John Xie 761 C: 1234567890 762 C: poe 763 C: 764 C: jpg 765 C: EABQRAQAAAAAAAAAAAAAAAAAAAAD 766 C: 767 C: 768 C: 769 C: 770 C: 2fooBAR 771 C: 772 C: 773 C: 774 C: ABC-12345 775 C: 776 C: 778 Example command for an RNV organization: 780 C: 781 C: 782 C: 783 C: 784 C: 785 C: 786 C: John Xie 787 C: 1234567890 788 C: poe 789 C: 790 C: jpg 791 C: EABQRAQAAAAAAAAAAAAAAAAAAAAD 792 C: 793 C: 794 C: 795 C: 796 C: 2fooBAR 797 C: 798 C: 799 C: 800 C: ABC-12345 801 C: 802 C: 804 When a command has been processed successfully, the EPP 805 element MUST contain a child element that 806 identifies the nv namespace. element contains the either 807 a element on success or a element on 808 failure. 810 o The element contains the following child elements: 812 * A element that contains the id of the verification 813 code with the required "type" attribute that defines the type 814 of the verification code. 816 * A element that contains the current status using 817 the status values defined in Section 3.2. 819 * A element that contains the date and time of nv 820 object creation. 822 * A element include: 824 + A element that is a "base64" encoded 825 form of the digitally signed 826 as defined in [I-D.gould-eppext-verificationcode]. 828 o The element contains the following child elements: 830 * A element that contains the current status using 831 the status values defined in Section 3.2. 833 * A element containing a human-readable description of 834 the reason of the failure. The language of the response is 835 identified via an OPTIONAL "lang" attribute. If not specified, 836 the default attribute value MUST be "en" (English). 838 Example response of success: 840 S: 841 S: 842 S: 843 S: 844 S: Command completed successfully 845 S: 846 S: 847 S: 848 S: 849 S: abc-123 850 S: 851 S: 2015-08-17T22:00:00.0Z 852 S: 853 S:ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 854 S:OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht 855 S:bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD 856 S:b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp 857 S:ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3 858 S:dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg 859 S:PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53 860 S:My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0 861 S:aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp 862 S:Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk 863 S:Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y 864 S:aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 865 S:ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l 866 S:dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu 867 S:YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P 868 S:UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy 869 S:ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0 870 S:UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa 871 S:Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3 872 S:amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ 873 S:bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr 874 S:CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa 875 S:d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm 876 S:SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z 877 S:VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+ 878 S:CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB 879 S:ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF 880 S:d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k 881 S:bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF 882 S:eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB 883 S:d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr 884 S:R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG 885 S:UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G 886 S:c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw 887 S:QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa 888 S:cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2 889 S:NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr 890 S:MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ 891 S:ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n 892 S:WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF 893 S:QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH 894 S:Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB 895 S:Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj 896 S:SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w 897 S:LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK 898 S:VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi 899 S:R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK 900 S:SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB 901 S:Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi 902 S:bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC 903 S:MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz 904 S:REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr 905 S:aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W 906 S:N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy 907 S:aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts 908 S:L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt 909 S:TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn 910 S:UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE 911 S:YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp 912 S:b25Db2RlOnNpZ25lZENvZGU+Cg== 913 S: 914 S: 915 S: 916 S: 917 S: 918 S: ABC-12345 919 S: 54321-XYZ 920 S: 921 S: 922 S: 924 Example response of failed: 926 S: 927 S: 928 S: 929 S: 930 S: Command completed successfully 931 S: 932 S: 933 S: 934 S: 935 S: 936 S: 937 S: The name of the object is not correct. 938 S: 939 S: 940 S: 941 S: 942 S: 943 S: ABC-12345 944 S: 54321-XYZ 945 S: 946 S: 947 S: 949 An EPP error response MUST be returned if a command cannot 950 be processed for any reason. 952 4.2.2. EPP Command 954 Delete semantics do not apply to Name Verification (NV) objects, so 955 there is no mapping defined for the EPP command. 957 4.2.3. EPP Command 959 Renew semantics do not apply to Name Verification (NV) objects, so 960 there is no mapping defined for the EPP command. 962 4.2.4. EPP Command 964 Transfer semantics do not apply to Name Verification (NV) objects, so 965 there is no mapping defined for the EPP command. 967 4.2.5. EPP Command 969 The EPP command provides a transform operation that allows a 970 client to modify the attributes of a NV object. In addition to the 971 standard EPP command elements, the command MUST contain a 972 element that identifies the NV namespace. The 973 element contains the following child elements: 975 o A element that contains the code of the a NV object to 976 be updated. 978 o A element that contains object attribute values to be 979 changed. 981 A element contains the following child elements: 983 o A element that contains authorization information 984 associated with the NV object. This mapping includes a password- 985 based authentication mechanism, but the schema allows new 986 mechanisms to be defined in new schemas. 988 Example command: 990 C: 991 C: 992 C: 993 C: 994 C: 995 C: abc-123 996 C: 997 C: 998 C: 2BARfoo 999 C: 1000 C: 1001 C: 1002 C: 1003 C: ABC-12345 1004 C: 1005 C: 1007 When an command has been processed successfully, 1008 a server MUST respond with an EPP response with no 1009 element. 1011 Example response: 1013 S: 1014 S: 1015 S: 1016 S: 1017 S: Command completed successfully 1018 S: 1019 S: 1020 S: ABC-12345 1021 S: 54321-XYZ 1022 S: 1023 S: 1024 S: 1026 An EPP error response MUST be returned if an 1027 command cannot be processed for any reason. 1029 4.3. Offline Review of Requested Actions 1031 Commands are processed by a server in the order they are received 1032 from a client. Though an immediate response confirming receipt and 1033 processing of the command is produced by the server, a server 1034 operator MAY perform an offline review of requested transform 1035 commands before completing the requested action. In such situations, 1036 the response from the server MUST clearly note that the transform 1037 command has been received and processed but that the requested action 1038 is pending. The status of the corresponding object MUST clearly 1039 reflect processing of the pending action. The server MUST notify the 1040 client when offline processing of the action has been completed. 1042 Examples describing a command that requires offline review 1043 are included here. Note the result code and message returned in 1044 response to the command. 1046 S: 1047 S: 1048 S: 1049 S: 1050 S: Command completed successfully; action pending 1051 S: 1052 S: 1053 S: 1055 S: 1056 S: abc-123 1057 S: 1058 S: 2015-09-03T22:00:00.0Z 1059 S: 1060 S: 1061 S: 1062 S: 1063 S: ABC-12345 1064 S: 54321-XYZ 1065 S: 1066 S: 1067 S: 1069 The status of the NV object after returning this response MUST 1070 include "pendingCompliant". The server operator reviews the request 1071 offline, and informs the client of the outcome of the review either 1072 by queuing a service message for retrieval via the command or 1073 by using an out-of-band mechanism to inform the client of the outcome 1074 of the review. 1076 The service message MUST contain text that describes the notification 1077 in the child element of the response element. In 1078 addition, the EPP element MUST contain a child 1079 element that identifies the NV namespace. The element 1080 contains the following child elements: 1082 A element that contains the id of the verification code 1083 with the required "type" attribute that defines the type of the 1084 verification code. 1086 A element that contains the current status 1087 descriptors associated with the NV. 1089 A element containing a human-readable description of the 1090 result. The language of the response is identified via an 1091 OPTIONAL "lang" attribute. If not specified, the default 1092 attribute value MUST be "en" (English). 1094 A element that contains the date and time describing 1095 when review of the requested action was completed. 1097 Example "review completed" service message: 1099 S: 1100 S: 1101 S: 1102 S: 1103 S: Command completed successfully; ack to dequeue 1104 S: 1105 S: 1106 S: 2015-09-04T22:01:00.0Z 1107 S: Pending action completed successfully. 1108 S: 1109 S: 1110 S: 1112 S: abc-123 1113 S: 1114 S: The object has passed verification, 1115 S: signed code was generated. 1116 S: 2015-09-04T22:00:00.0Z 1117 S: 1118 S: 1119 S: 1120 S: BCD-23456 1121 S: 65432-WXY 1122 S: 1123 S: 1124 S: 1126 5. Formal Syntax 1128 An EPP object NV mapping is specified in XML Schema notation. The 1129 formal syntax presented here is a complete schema representation of 1130 the object mapping suitable for automated validation of EPP XML 1131 instances. The BEGIN and END tags are not part of the schema; they 1132 are used to note the beginning and ending of the schema for URI 1133 registration purposes. 1135 BEGIN 1136 1138 1147 1148 1149 Extensible Provisioning Protocol v1.0 1150 Name Verification provisioning schema. 1151 1152 1154 1157 1158 1159 1162 1165 1166 1167 1168 1170 1173 1174 1175 1177 1178 1180 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1197 1198 1200 1201 1202 1203 1204 1205 1207 1208 1210 1212 1213 1214 1215 1216 1217 1218 1220 1221 1222 1223 1224 1225 1227 1228 1229 1230 1231 1232 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1247 1250 1251 1252 1253 1255 1256 1258 1260 1261 1262 1263 1264 1265 1267 1270 1271 1272 1273 1274 1275 1277 1280 1281 1282 1283 1284 1285 1288 1289 1290 1291 1292 1293 1295 1298 1299 1300 1301 1303 1306 1307 1308 1310 1311 1313 1314 1315 1316 1318 1319 1321 1322 1323 1324 1326 1328 1329 1330 1332 1335 1336 1337 1338 1339 1340 1341 1343 1344 1345 1346 1347 1348 1350 1351 1353 1354 1355 1356 1357 1358 1360 1361 1362 1363 1364 1365 1366 1368 1371 1372 1373 1374 1375 1376 1377 1378 1380 1383 1384 1385 1386 1387 1388 1389 1390 1392 1393 1394 1395 1397 1398 1400 1401 1403 1404 1405 1406 1408 1409 1410 1412 1417 1418 1419 1420 1422 1424 1425 1426 1428 1429 1430 1431 1433 1434 1435 1437 1438 1439 1440 1441 1442 1443 1445 1448 1449 END 1451 6. Internationalization Considerations 1453 EPP is represented in XML, which provides native support for encoding 1454 information using the Unicode character set and its more compact 1455 representations including UTF-8. Conformant XML processors recognize 1456 both UTF-8 and UTF-16. Though XML includes provisions to identify 1457 and use other character encodings through use of an "encoding" 1458 attribute in an declaration, use of UTF-8 is RECOMMENDED. 1460 As an extension of the EPP, the elements, element content described 1461 in this document MUST inherit the internationalization conventions 1462 used to represent higher-layer domain and core protocol structures 1463 present in an XML instance that includes this extension. 1465 7. IANA Considerations 1467 7.1. XML Namespace 1469 This document uses URNs to describe XML namespaces and XML schemas 1470 conforming to a registry mechanism described in [RFC3688]. IANA is 1471 requested to assignment the following two URI. 1473 Registration request for the NV namespace: 1475 o URI: urn:ietf:params:xml:ns:nv-1.0 1476 o Registrant Contact: See the "Author's Address" section of this 1477 document. 1479 o XML: None. Namespace URI does not represent an XML specification. 1481 Registration request for the NV XML schema: 1483 o URI: urn:ietf:params:xml:schema:nv-1.0 1485 o Registrant Contact: See the "Author's Address" section of this 1486 document. 1488 o XML: See the "Formal Syntax" section of this document. 1490 7.2. EPP Extension Registry 1492 The EPP extension described in this document should be registered by 1493 the IANA in the EPP Extension Registry described in [RFC7451]. The 1494 details of the registration are as follows: 1496 Name of Extension: Extensible Provisioning Protocol (EPP) China Name 1497 Verification Mapping 1499 Document status: Informational 1501 Reference: (insert reference to RFC version of this document) 1503 Registrant Name and Email Address: IESG, 1505 TLDs: Any 1507 IPR Disclosure: None 1509 Status: Active 1511 Notes: None 1513 8. Security considerations 1515 Verification Code Tokens are digitally signed using XML Signature 1516 technology. The security considerations described in Section 12 of 1517 the W3C XML Signature Syntax and Processing Candidate Recommendation 1518 [W3C.CR-xmldsig-core2-20120124] apply to this specification as well. 1519 The object mapping described in this document does not provide any 1520 other security services or introduce any additional considerations 1521 beyond those described by [RFC5730] or those caused by the protocol 1522 layers used by EPP. 1524 9. Acknowledgements 1526 The authors especially thank the author of [RFC5730]. 1528 Useful comments and contributions were made by TBD. 1530 10. Change History 1532 RFC Editor: Please remove this section. 1534 10.1. draft-xie-eppext-nv-mapping-00: Version 00 1536 o First draft. 1538 10.2. Change from 00 to 01 1540 1. Made the element of the panDataType and pendingType 1541 require the "type" attribute in the XML schema. 1543 2. Fixed the XML schema to include the OPTIONAL 1544 element. 1546 3. Added the support for the OPTIONAL "lang" attribute for the 1547 element of the and elements. 1549 10.3. Change from 01 to 02 1551 o Ping update. 1553 11. Normative References 1555 [I-D.gould-eppext-verificationcode] 1556 Gould, J., "Verification Code Extension for the Extensible 1557 Provisioning Protocol (EPP)", draft-gould-eppext- 1558 verificationcode-03 (work in progress), March 2016. 1560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1561 Requirement Levels", BCP 14, RFC 2119, 1562 DOI 10.17487/RFC2119, March 1997, 1563 . 1565 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1566 DOI 10.17487/RFC3688, January 2004, 1567 . 1569 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1570 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1571 . 1573 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1574 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1575 February 2015, . 1577 [W3C.CR-xmldsig-core2-20120124] 1578 Bartel, M., Boyer, J., Fox, B., LaMacchia, B., and E. 1579 Simon, ""XML Signature Syntax and Processing Version 2.0", 1580 W3C Candidate Recommendation 24 January 2012", January 1581 2012, 1582 . 1584 [W3C.REC-xml-20040204] 1585 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1586 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 1587 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1588 20040204", February 2004, 1589 . 1591 [W3C.REC-xmlschema-1-20041028] 1592 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1593 ""XML Schema Part 1: Structures Second Edition", World 1594 Wide Web Consortium Recommendation REC-xmlschema- 1595 1-20041028", October 2004, 1596 . 1598 [W3C.REC-xmlschema-2-20041028] 1599 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 1600 Second Edition", World Wide Web Consortium Recommendation 1601 REC-xmlschema-2-20041028", October 2004, 1602 . 1604 Authors' Addresses 1606 Xie Jiagui 1607 Teleinfo 1608 1#-21,gaolizhang Street,Haidian District 1609 Beijing, Beijing 100095 1610 China 1612 Phone: +86 10 5884 6931 1613 Email: xiejiagui@teleinfo.cn 1614 James Gould 1615 VeriSign, Inc. 1616 12061 Bluemont Way 1617 Reston, VA 20190 1618 US 1620 Email: jgould@verisign.com 1621 URI: http://www.verisign.com 1623 Liu Hongyan 1624 Teleinfo 1625 1#-21,gaolizhang Street,Haidian District 1626 Beijing, Beijing 100095 1627 China 1629 Phone: +86 10 5884 6931 1630 Email: liuhongyan@teleinfo.cn