idnits 2.17.00 (12 Aug 2021) /tmp/idnits34020/draft-zhou-eppext-contact-verification-01.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 : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 24 characters in excess of 72. ** The abstract seems to contain references ([RFC5733]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (December 23, 2015) is 2334 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-01 Summary: 2 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 L. Zhou 3 Internet-Draft CNNIC 4 Intended status: Informational D. Ma 5 Expires: June 25, 2016 W. Wang 6 ZDNS Ltd. 7 N. Kong 8 X. Lee 9 CNNIC 10 J. Galvin 11 Affilias 12 December 23, 2015 14 Verification Extension for the Extensible Provisioning Protocol (EPP) 15 Contact Mapping 16 draft-zhou-eppext-contact-verification-01 18 Abstract 20 This mapping describes an verification extension to EPP contact 21 mapping [RFC5733]. Specified in Extensible Markup Language (XML), 22 this extended mapping is applied to provide additional features 23 required for the provisioning of contact verification. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 25, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 73 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 74 3.1. Distinction Type Values . . . . . . . . . . . . . . . . . 4 75 3.2. Verification Status Values . . . . . . . . . . . . . . . 4 76 3.3. Dates and Times . . . . . . . . . . . . . . . . . . . . . 4 77 3.4. Client Identifier . . . . . . . . . . . . . . . . . . . . 5 78 4. Verification State Diagram . . . . . . . . . . . . . . . . . 5 79 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 80 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 6 81 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 82 5.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 83 5.1.3. EPP Command . . . . . . . . . . . . . . . 11 84 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 11 85 5.2.1. EPP Command . . . . . . . . . . . . . . . . 12 86 5.2.2. EPP Command . . . . . . . . . . . . . . . . 12 87 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 12 88 5.2.4. EPP Command . . . . . . . . . . . . . . . 12 89 5.2.5. EPP Command . . . . . . . . . . . . . . . . 12 90 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7. Internationalization Considerations . . . . . . . . . . . . . 14 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 15 94 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 15 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 96 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 97 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 100 1. Introduction 102 The verification of domain name and registrant identity are required 103 in some registries according to local laws and regulations. The 104 registry should ensure the domain registered does not contain any 105 illegal words and the registrants should pass the real-name 106 verification. There are efforts on verification mechanism by 107 introducing a third party that providing verification service 108 [I-D.draft-gould-eppext-verificationcode]. This method is intended 109 to offer a verification framework but not detail the verification 110 statuses which are employ in practice to indicate the verification 111 process. To be in alignment with the verification status indication 112 mechanism, EPP should be extended accordingly. 114 This document describes an extension mapping for version 1.0 of the 115 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 116 extension to EPP object mappings like the EPP contact mapping 117 [RFC5733], can be used to retrieve verification information in query 118 commands. 120 This document is specified using the XML 1.0 as described in 121 [W3C.REC-xml-20040204] and XML Schema notation as described in 122 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 124 2. Conventions Used in This Document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 In examples, "C:" represents lines sent by a protocol client and "S:" 131 represents lines returned by a protocol server. Indentation and 132 white space in examples are provided only to illustrate element 133 relationships and are not a REQUIRED feature of this specification. 135 XML is case sensitive. Unless stated otherwise, XML specifications 136 and examples provided in this document MUST be interpreted in the 137 character case presented to develop a conforming implementation. 139 vericontact-1.0 in this document is used as an abbreviation for 140 urn:ietf:params:xml:ns:vericontact-1.0. 142 3. Object Attributes 144 This extension adds additional elements to the EPP contact mapping 145 [RFC5733]. Only the new elements are described here. 147 3.1. Distinction Type Values 149 A contact may be verified already and may have something like 150 integrity records. So a distiction type values are defined to 151 associate with a contact object. Distinction type value 152 descriptions: 154 o verified. A contact has been verified already. 156 o blocked. A contact has blemished integrity records. 158 o unverified. A contact has not pass the verification process. 160 3.2. Verification Status Values 162 The contact object MUST always have one associated verification 163 status value. The verification status value can be set only by the 164 server. The verification status of an object MAY change as a result 165 of an action performed by a server operator. Verification status 166 Value descriptions: 168 o unverified. No verification materials are received. 170 o pendingVerify. Verification action has not been completed by the 171 server after receiving verification materials. Server operators 172 can delay action completion for a variety of reasons, such as to 173 allow for human review or third-party action. 175 o pass. Successful verification. 177 o failed. Failed verification. Further verification materials may 178 be needed. 180 3.3. Dates and Times 182 Date and time attribute values MUST be represented in Universal 183 Coordinated Time (UTC) using the Gregorian calendar. The extended 184 date-time form using upper case "T" and "Z" characters defined in 185 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 186 values, as XML Schema does not support truncated date-time forms or 187 lower case "T" and "Z" characters. 189 3.4. Client Identifier 191 The client identifier represents the unique identifier assigned to 192 the client by the server. 194 4. Verification State Diagram 196 Following is a general verification state transition process: 198 1. The initial verification status of a domain is "unverified". 200 2. The registrant submits the proof materials to the registry. 202 3. After receiving the proof materials, the verification status of 203 the domain is changed to "pendingVerify". 205 4. The proof materials pass the human review or third-party 206 verification. 208 5. The verification status is changed to "pass". 210 6. The proof materials are not approved. 212 7. The verification status is changed to "failed". 214 8. If the registrant resubmits the proof materials, the status will 215 be set to "pendingVerify" again. 217 Figure 1: Verification State Diagram 219 | 220 v (2) (4) 221 +----------------+ Material +-----------------+ Approved +----------------+ 222 |unverified (1)| submitted |pendingVerify (3)| |pass (5)| 223 | |---------->| |--------->| | 224 +----------------+ +-----------------+ +----------------+ 225 ^ | 226 | | (6) 227 | | Unapproved +----------------+ 228 | | |failed (7)| 229 | +-------------->| | 230 | +----------------+ 231 | (8) Resubmit | 232 +--------------------------------+ 234 5. EPP Command Mapping 236 A detailed description of the EPP syntax and semantics can be found 237 in the EPP core protocol specification [RFC5730]. The command 238 mappings described here are specifically for use in provisioning and 239 managing verification information via EPP. 241 5.1. EPP Query Commands 243 EPP provides three commands to retrieve contact information: 244 to determine if a contact object can be provisioned within a 245 repository, to retrieve detailed information associated with a 246 contact object, and to retrieve contact-object transfer 247 status information. 249 5.1.1. EPP Command 251 This extension does not add any elements to the EPP command 252 described in the EPP contact mapping [RFC5733]. However, additional 253 elements are defined for the response. 255 Example command: 257 C: 258 C: 259 C: 260 C: 261 C: 263 C: sh8013 264 C: sah8013 265 C: 8013sah 266 C: 267 C: 268 C: ABC-12345 269 C: 270 C: 272 When an command has been processed successfully, the EPP 273 element MUST contain child elements as described in the EPP 274 contact mapping [RFC5733]. In addition, the EPP element 275 SHOULD contain a child element that identifies 276 the extension namespace if the contact object has data associated 277 with this extension and based on its service policy. The 278 element contains the following child elements: 280 o An OPTIONAL element is designed to 281 indicate the verification status of a contact information with 282 respect to the verification rules of a specific registry. The 283 element is only used for a 284 element with the attribute "avail" that equals false. The element 285 contains the following attributes: 287 * A "id" attribute associates with a specific contact identifier 288 checked. 290 * A "type" attribute specifies whether a contact is verified or 291 not as described in section 3.1. 293 Example response: 295 S: 296 S: 297 S: 298 S: 299 S: Command completed successfully 300 S: 301 S: 302 S: 304 S: 305 S: sh8013 306 S: 307 S: 308 S: sah8013 309 S: 310 S: 311 S: 8013sah 312 S: 313 S: 314 S: 315 S: 316 S: 317 S: 318 S: 319 S: 320 S: 321 S: 322 S: 323 S: ABC-12345 324 S: 54322-XYZ 325 S: 326 S: 327 S: 329 5.1.2. EPP Command 331 This extension does not add any element to the EPP command 332 described in the EPP contact mapping [RFC5733]. However, additional 333 elements are defined for the response. 335 Example command: 337 C: 338 C: 339 C: 340 C: 341 C: 343 C: sh8013 344 C: 345 C: 2fooBAR 346 C: 347 C: 348 C: 349 C: ABC-12345 350 C: 351 C: 353 When an command has been processed successfully, the EPP 354 element MUST contain child elements as described in the EPP 355 contact mapping [RFC5733]. In addition, the EPP element 356 SHOULD contain a child element that identifies 357 the extension namespace if the contact object has data associated 358 with this extension and based on its service policy. The 359 element contains the following child elements: 361 o A element that contains the current 362 verification status defined in section 3.2. 364 o An OPTIONAL element that contains records 365 with history verification process information. The 366 element MUST contain following elements: 368 * element contains a single history record 369 for the verification process. The element 370 MUST contain following elements: 372 + A element contains the date and time when 373 the operation has been executed. 375 + A element contains the name of an operation 376 that has been executed. 378 + A element contains the identifier of an 379 sponsoring client. 381 Example response for an authorized client: 383 S: 384 S: 385 S: 386 S: 387 S: Command completed successfully 388 S: 389 S: 390 S: 392 S: sh8013 393 S: SH8013-REP 394 S: 395 S: 396 S: 397 S: John Doe 398 S: Example Inc. 399 S: 400 S: 123 Example Dr. 401 S: Suite 100 402 S: Dulles 403 S: VA 404 S: 20166-6503 405 S: US 406 S: 407 S: 408 S: +1.7035555555 409 S: +1.7035555556 410 S: jdoe@example.com 411 S: ClientY 412 S: ClientX 413 S: 2015-02-03T212:00:00.0Z 414 S: ClientX 415 S: 2015-02-20T09:00:00.0Z 416 S: 2015-10-08T09:00:00.0Z 417 S: 418 S: 2fooBAR 419 S: 420 S: 421 S: 422 S: 423 S: 424 S: 425 S: 426 S: 427 S: 428 S: pass 429 S: 430 S: 431 S: 2015-2-6T12:00:00.0Z 432 S: PASS 433 S: ClientX 434 S: 435 S: 436 S: 2001-2-3T15:00:00.0Z 437 S: PENDINGVERIFY 438 S: ClientX 439 S: 440 S: 441 S: 2015-2-3T12:00:00.0Z 442 S: UNVERIFIED 443 S: ClientX 444 S: 445 S: 446 S: 447 S: 448 S: 449 S: ngcl-IvJjzMZc 450 S: test142AWQONJZ 451 S: 452 S: 453 S: 455 response for the unauthorized client has not been changed, see 456 [RFC5733] for detail. 458 An EPP error response MUST be returned if an command cannot be 459 processed for any reason. 461 5.1.3. EPP Command 463 This extension does not add any elements to the EPP 464 command or response described in the EPP contact mapping 465 [RFC5733]. 467 5.2. EPP Transform Commands 469 EPP provides five commands to transform domain objects: to 470 create an instance of a domain object, to delete an instance 471 of a domain object, to extend the validity period of a 472 contact object, to manage domain object sponsorship 473 changes, and to change information associated with a contact 474 object. 476 5.2.1. EPP Command 478 This extension does not add any elements to the EPP command 479 or response described in the EPP contact mapping [RFC5733] 481 5.2.2. EPP Command 483 This extension does not add any elements to the EPP command 484 or response described in the EPP contact mapping [RFC5733]. 486 5.2.3. EPP Command 488 This extension does not add any elements to the EPP command 489 or response described in the EPP contact mapping [RFC5733]. 491 5.2.4. EPP Command 493 This extension does not add any elements to the EPP 494 command or response described in the EPP contact mapping 495 [RFC5733]. 497 5.2.5. EPP Command 499 This extension does not add any elements to the EPP command 500 or response described in the EPP contact mapping [RFC5733]. 502 6. Formal Syntax 504 An EPP object mapping is specified in XML Schema notation. The 505 formal syntax presented here is a complete schema representation of 506 the object mapping suitable for automated validation of EPP XML 507 instances. The BEGIN and END tags are not part of the schema; they 508 are used to note the beginning and ending of the schema for URI 509 registration purposes. 511 BEGIN 512 514 521 522 524 527 528 529 Extensible Provisioning Protocol v1.0 530 Contact Verification Extension Schema v1.0 531 532 534 535 536 538 539 540 541 542 543 545 546 547 548 549 550 551 552 554 555 556 557 558 559 560 562 564 565 566 567 568 569 571 572 574 575 576 577 578 579 580 581 583 584 585 586 587 589 590 591 592 593 594 595 597 598 599 END 601 7. Internationalization Considerations 603 EPP is represented in XML, which provides native support for encoding 604 information using the Unicode character set and its more compact 605 representations including UTF-8. Conformant XML processors recognize 606 both UTF-8 and UTF-16. Though XML includes provisions to identify 607 and use other character encodings through use of an "encoding" 608 attribute in an declaration, use of UTF-8 is RECOMMENDED. 610 As an extension of the EPP contact mapping, the elements, element 611 content described in this document MUST inherit the 612 internationalization conventions used to represent higher-layer 613 domain and core protocol structures present in an XML instance that 614 includes this extension. 616 8. IANA Considerations 618 8.1. XML Namespace 620 This document uses URNs to describe XML namespaces and XML schemas 621 conforming to a registry mechanism described in [RFC3688]. IANA is 622 requested to assignment the following URI. 624 Registration request for the contact verification namespace: 626 o URI: urn:ietf:params:xml:ns:vericontact-1.0 628 o Registrant Contact: See the "Author's Address" section of this 629 document. 631 o XML: See the "Formal Syntax" section of this document. 633 8.2. EPP Extension Registry 635 The EPP extension described in this document should be registered by 636 the IANA in the EPP Extension Registry described in [RFC7451]. The 637 details of the registration are as follows: 639 Name of Extension: Contact Verification Extension 641 Document Status: Informational 643 Reference: (insert reference to RFC version of this document) 645 Registrant Name and Email Address: See the "Author's Address" section 646 of this document. 648 TLDs: any 650 IPR Disclosure: none 652 Status: active 654 Notes: none 656 9. Security Considerations 658 The object mapping extension described in this document does not 659 provide any other security services or introduce any additional 660 considerations beyond those described by [RFC5730], [RFC5733] or 661 those caused by the protocol layers used by EPP. 663 10. Acknowledgement 665 The authors would like to thank Galvin Brown from CentralNic for the 666 idea behind use of verification state diagram, and Lin Dong from .top 667 registry for his careful reviews. 669 11. Normative References 671 [I-D.draft-gould-eppext-verificationcode] 672 Gould, J., "Verification Code Extension for the Extensible 673 Provisioning Protocol (EPP)", November 2015, 674 . 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, 679 DOI 10.17487/RFC2119, March 1997, 680 . 682 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 683 DOI 10.17487/RFC3688, January 2004, 684 . 686 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 687 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 688 . 690 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 691 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 692 August 2009, . 694 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 695 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 696 February 2015, . 698 [W3C.REC-xml-20040204] 699 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 700 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 701 Edition)", World Wide Web Consortium FirstEdition REC-xml- 702 20040204", February 2004, 703 . 705 [W3C.REC-xmlschema-1-20041028] 706 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 707 ""XML Schema Part 1: Structures Second Edition", World 708 Wide Web Consortium Recommendation REC-xmlschema- 709 1-20041028", October 2004, 710 . 712 [W3C.REC-xmlschema-2-20041028] 713 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 714 Second Edition", World Wide Web Consortium Recommendation 715 REC-xmlschema-2-20041028", October 2004, 716 . 718 Authors' Addresses 720 Linlin Zhou 721 CNNIC 722 4 South 4th Street, Zhongguancun, Haidian District 723 Beijing, Beijing 100190 724 China 726 Phone: +86 10 5881 2677 727 Email: zhoulinlin@cnnic.cn 729 Di Ma 730 ZDNS Ltd. 731 4 South 4th Street, Zhongguancun, Haidian District 732 Beijing, Beijing 100190 733 China 735 Email: madi@zdns.cn 737 Wei Wang 738 ZDNS Ltd. 739 4 South 4th Street, Zhongguancun, Haidian District 740 Beijing, Beijing 100190 741 China 743 Email: wangwei@zdns.cn 745 Ning Kong 746 CNNIC 747 4 South 4th Street, Zhongguancun, Haidian District 748 Beijing, Beijing 100190 749 China 751 Phone: +86 10 5881 3147 752 Email: nkong@cnnic.cn 753 Xiaodong Lee 754 CNNIC 755 4 South 4th Street, Zhongguancun, Haidian District 756 Beijing, Beijing 100190 757 China 759 Phone: +86 10 5881 3020 760 Email: xl@cnnic.cn 762 James Galvin 763 Affilias 764 Afilias USA, Inc. Building 3, Suite 105 300 Welsh Road 765 Horsham, PA 19044 766 US 768 Email: jgalvin@afilias.info