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