idnits 2.17.1 draft-chen-top-level-interface-protocol-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 : ---------------------------------------------------------------------------- ** There are 3 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 4: '...Expires: MAY 17, 2020 Nove...' RFC 2119 keyword, line 109: '...in this document MUST be interpreted i...' RFC 2119 keyword, line 122: '...ps and are not a REQUIRED feature of t...' RFC 2119 keyword, line 147: '...ribed in this document MUST conform to...' RFC 2119 keyword, line 157: '...ient identifiers MUST conform to the "...' (53 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 118, but not defined == Missing Reference: 'RFC3688' is mentioned on line 1247, but not defined == Missing Reference: 'RFC0791' is mentioned on line 1296, but not defined Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Y. Chen 2 Internet Draft J. Xie 3 Intended status: Experimental Z. Li 4 Expires: MAY 17, 2020 November 17, 2019 H. Liu 5 China Academy of Information and Communications Technology Y. Han 7 National Identifier Top-level Node Interface Protocol 8 draft-chen-top-level-interface-protocol-00 10 Abstract 12 This document describes an Extensible Provisioning Protocol (EPP) 13 for the provisioning and management of enterprises and identifiers 14 between the server which is called Business Management System(BMS) 15 and is entitled to manage the identifier top-level node and the 16 client which is also referred to as Second Node Management System 17 (SNMS).Specified in XML, the mapping defines EPP command syntax and 18 semantics as applied to enterprise and identifier management. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on May 18, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction...................................................4 61 1.1. Conventions Used in This Document.........................4 62 2. Object Attributes..............................................4 63 2.1. Object Attributes.........................................4 64 2.2. Client Identifiers........................................5 65 2.3. Dates and Times...........................................5 66 2.4. IP Addresses..............................................5 67 3. EPP Command Mapping............................................5 68 3.1. EPP Query Commands........................................5 69 3.1.1. EPP Command..................................6 70 3.1.2. EPP Command...................................9 71 3.1.3. EPP Command...................................9 72 3.1.4. EPP Query Command........................12 73 3.2. EPP Transform Commands...................................12 74 3.2.1. EPP Command................................13 75 3.2.2. EPP Command................................19 76 3.2.3. EPP Command.................................19 77 3.2.4. EPP Command..............................19 78 3.2.5. EPP Command................................19 79 4. Internationalization Considerations...........................26 80 5. Security Considerations.......................................26 81 6. IANA Considerations...........................................27 82 7. Acknowledgments...............................................27 83 8. References....................................................27 84 8.1. Normative References.....................................27 85 8.2. Informative References...................................28 87 1. Introduction 89 Identifier Enterprises in this context are individuals or companies 90 that act as digital object identifier registrars. Digital object 91 identifier is a set of globally unique character strings with a 92 specified format that may consist of digits, letters or notations 93 which is an essential element of a digital object. 95 This document describes the interface protocol of National 96 identifier top-level node for the provision and management of 97 identifiers and enterprises for version 1.0 of the Extensible 98 Provisioning Protocol (EPP). This mapping is specified using the 99 Extensible Markup Language (XML)1.0 as described in [W3C.REC-xml- 100 20040204] and XML Schema notation as described in [W3C.REC- 101 xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 103 [RFC5730]provides a complete description of EPP command and response 104 structures. A thorough understanding of the base protocol 105 specification is necessary to understand the mapping described in 106 this document. 108 XML is case sensitive. Unless stated otherwise, XML specifications 109 and examples provided in this document MUST be interpreted in the 110 character case presented to develop a conforming implementation. 112 1.1. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 115 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 116 this document are to be interpreted as described in RFC 2119 117 [RFC2119]. 119 In examples, "C:" represents lines sent by a protocol client and 120 "S:" represents lines returned by a protocol server. Indentation 121 and white space in examples are provided only to illustrate element 122 relationships and are not a REQUIRED feature of this protocol. 124 2. Object Attributes 126 EPP enterprise object and identifier object both have attributes and 127 associated values that can be viewed and modified by the sponsoring 128 client or the server. This section describes each attribute type in 129 detail. The formal syntax for the attribute values described here 130 can be found in the "Formal Syntax" section of this document and in 131 the appropriate normative references. 133 2.1. Object Attributes 135 Enterprise objects represent the registrar and the information 136 resources related to an enterprise, such as identifier to be 137 applied, certificate code, legal person, contacts, etc. 139 Business Management System (BMS) in this document represents a 140 server system that is entitled to administrate the Global Handle 141 Registry naming authorities, while Second Node Management System 142 (SNMS) acts as an administrator to manage sub-naming authorities 143 under the GHR naming authorities. 145 This document provides an overview of the EPP mapping of both the 146 enterprise object and identifier objects. The syntax for handle 147 identifier namespace described in this document MUST conform to 148 [RFC3650], [RFC3651], [RFC3652]. 150 These conformance requirements might change in the future as a 151 result of progressing work in developing standards for 152 internationalized digital objects. 154 2.2. Client Identifiers 156 All EPP enterprise clients are identified by a server-unique 157 identifier. Client identifiers MUST conform to the "clIDType" syntax 158 described in [RFC5730]. 160 2.3. Dates and Times 162 Date and time attribute values MUST be represented in Universal 163 Coordinated Time (UTC) using the Gregorian calendar. The extended 164 date-time form using upper case "T" and "Z" characters defined in 165 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 166 values, as XML Schema does not support truncated date-time forms or 167 lower case "T" and "Z" characters. 169 2.4. IP Addresses 171 The syntax for IPv4 addresses described in this document MUST 172 conform to[RFC5730]. The syntax for IPv6 addresses described in 173 this document MUST conform to [RFC4291]. Practical considerations 174 for publishing IPv6 address information in zone files are documented 175 in [RFC2874] and [RFC3596]. A server MAY reject IP addresses that 176 have not been allocated for public use by IANA. 178 3. EPP Command Mapping 180 A detailed description of the EPP syntax and semantics is specified 181 in [RFC5730]. The command mappings described here are specifically 182 for use in provisioning and managing enterprises and identifiers 183 allocated to the enterprise via EPP. 185 3.1. EPP Query Commands 187 EPP provides two commands to retrieve object information: to 188 determine if an EPP object can be provisioned within a repository, 189 and to retrieve detailed information associated with an EPP 190 object. 192 3.1.1. EPP Command 194 The EPP command mapping in this document is used to 195 determine if materials of an enterprise object or the enterprise 196 identifier have been registered. It provides a hint that allows a 197 client to anticipate the success or failure of provisioning an 198 object using the command, as object-provisioning 199 requirements are ultimately a matter of server policy. 201 In addition to the standard EPP command elements, the enterprise 202 command MUST contain an element and an EPP 203 enterprise element to illustrate ID of client system. An 204 is made up of the following child elements: 206 o An < ent:shrUserId > element that contains the fully qualified 207 user ID of the Second Handle Registry which is in responsible for 208 the enterprise to be queried. 210 o An element that specifies certification type used 211 by the enterprise. Two types of certifications are acceptable, the 212 digital number 1 represents Unified Social Credit Code, while "3" 213 means others. 215 o An element contains the fully qualified 216 certification code of the enterprise which is used to uniquely 217 identify and certificate the corporation or organization. 219 Example enterprise command: 221 C: 223 C: 225 C: 227 C: 229 C: 231 C: shrUser001 233 C: 000001 235 C: 000001 237 C: 239 C: 241 C: 12345 243 C: 244 C: 246 When an enterprise command has been processed successfully, 247 a server MUST respond with an EPP element, a 248 element and a element: 250 o An EPP element MUST contain a child 251 element. The element has one 252 enterprise-specific element that contains a fully qualified 253 enterprise number generated by the server system to identify the 254 enterprise. 256 o A element MUST contain two child elements: a 257 element to illustrate client ID and a element to 258 specifies the server ID. 260 Example enterprise response: 262 S: 263 S: 264 S: 265 S: 266 S: Command completed successfully 267 S: 268 S: 269 S: 270 S: 00001 271 S: 272 S: 273 S: 274 S: 12345 275 S: s12345 276 S: 277 S: 278 S: 280 The command mapping to illustrate the client's request to 281 check the enterprise identifier MUST contain an EPP 282 element. 284 A < prefix:check> element contains two child elements: 286 o An that contains the Second Handle Registry 287 (SHR)identifier to which the enterprise object is subject. 289 o An provides the sub-prefix under the Second Handle 290 Registry (SHR) prefix. 292 Example enterprise identifier command: 294 C: 296 C: 298 C: 300 C: 302 C: 305 C: 88.1000 307 C: 88.1000.1 309 C: 311 C: 313 C: 12345 315 C: 317 C: 319 When an enterprise identifier command has been processed 320 successfully, a server MUST respond with an EPP element, a 321 element and a element. 323 Example enterprise identifier response: 325 S: 327 S: 329 S: 331 S: 333 S: Command completed successfully 335 S: 337 S: 339 S: 12345 340 S: s12345 342 S: 344 S: 346 S: 348 An EPP error response MUST be returned if a command cannot 349 be processed for any reason. 351 3.1.2. EPP Command 353 Info semantics do not directly apply to enterprise objects, so there 354 is no mapping defined for the EPP command. 356 3.1.3. EPP Command 358 When a client has sent an enterprise identifier command to 359 apply for the enterprise's identifier, handle prefix in this case. 360 The EPP command is defined to discover and retrieve service 361 messages queued by a server for individual clients to synchronize 362 result of the identifier command. 364 The command which is represented as an empty element with no 365 child elements has an "op" attribute with value "req" to retrieve 366 the first message from the server message queue. 368 Example command: 370 C: 372 C: 374 C: 376 C: 378 C: 12345 380 C: 382 C: 383 When the client system sends an EPP enterprise command to the 384 server, and if the message result queue is not empty, a successful 385 response with the first message from the message queue MUST be 386 returned to the client. 388 The standard command response MUST contain the following 389 child elements: 391 o An EPP element that contains a result code and a message 392 that notes a human-readable description of the response code. 394 o A element that describes messages queued for client 395 retrieval. 397 o An object-specific element that contains information of 398 the enterprise object and digital object identifier related to 399 it :a element to specify the client ID of 400 enterprise, a element to identify the server, a 401 element that contains the fully qualified 402 enterprise ID number, a element that includes 403 identifier registered by the enterprise, a element 404 where "1" means normal, and a element with a 405 digital "1" to notify a successful result of the prefix create 406 command. 408 Example response: 410 S: 412 S: 414 S: 416 S: 418 S: Command completed successfully; ack to dequeue 420 S: 422 S: 424 S: 2018-10-19T15:09:37.393+08:00 426 S: 1234 428 S: 430 S: 432 S: 435 S: 123456 436 S: s123456 438 S: 00000001 440 S: 88.1000.1 442 S: 1 444 S: 1 446 S: 448 S: 450 S: 452 S: 454 S: 12345 456 S: s12345 458 S: 460 S: 462 S: 464 The response message is then received by the client, and 465 the client MUST send a response request with a message with an 466 explicit acknowledgement to confirm that the message has been 467 received. 469 Example acknowledgement command: 471 C: 473 C: 475 C: 477 C: 479 C: 12345 481 C: 483 C: 485 An EPP enterprise acknowledgement response notes the ID of 486 the message that has been acknowledged and the number of messages 487 remaining in the queue. 489 Example acknowledgement response: 491 S: 493 S: 495 S: 497 S: 499 S: Command completed successfully 501 S: 503 S: 505 S: 507 S: 12345 509 S: s12345 511 S: 513 S: 515 S: 517 3.1.4. EPP Query Command 519 Transfer query semantics do not directly apply to enterprise 520 objects, so there is no mapping defined for the EPP query 521 command. 523 3.2. EPP Transform Commands 525 EPP provides two commands to transform enterprise objects: 526 to create an instance of an enterprise object, and to 527 change information associated with an enterprise object. This 528 document does not define enterprise-object mappings for the EPP 529 , and commands. 531 Transform commands are typically processed and completed in real 532 time. Server operators MAY receive and process transform commands 533 but defer completing the requested action if human or third-party 534 review is required before the requested action can be completed. In 535 such situations, the server MUST return a 1001 response code to the 536 client to note that the command has been received and processed but 537 that the requested action is pending. The server MUST also manage 538 the status of the object that is the subject of the command to 539 reflect the initiation and completion of the requested action. Once 540 the action has been completed; all clients involved in the 541 transaction MUST be notified using a service message that the action 542 has been completed and that the status of the object has changed. 543 Other notification methods MAY be used in addition to the required 544 service message. 546 Server operators SHOULD confirm that a client is authorized to 547 perform a transform command on an enterprise object. Any attempt to 548 transform an enterprise object by an unauthorized client MUST be 549 rejected, and the server MUST return a 2201 response code to the 550 client to note that the client lacks privileges to execute the 551 requested command. 553 3.2.1. EPP Command 555 The EPP command provides an operation that allows a client 556 to send a create request of an enterprise object under the condition 557 that the Second Handle Registry (SHR) has been registered. 559 In addition to the standard EPP command elements, the 560 command MUST contain an element that specifies the 561 enterprise to be created. The element contains the 562 following child elements: 564 o An element that contains the Second Handle 565 Registry (SHR)identifier to which the enterprise object to be 566 created belongs. 568 o An element that specifies type of the enterprise 569 object. The enterprise object MAY be type of government offices, 570 institutions, social groups, commercial enterprises or others. 571 Detailed category in EPP enterprise mapping completely complies 572 with the national standard of industry categories. 574 o An element that contains fully qualified 575 certification code ,also called Uniform Social Credit Code of the 576 enterprise which is represented by 18 numerals or uppercase 577 English letters. 579 o An element that contains the image information of 580 the enterprise certificate, which is processed with base64 581 encoding schemes. 583 o An element that specifies file format of the 584 enterprise certificate image. Image formats of Joint Photographic 585 Experts Group(.JPEG), Portable Network Graphics(.PNG), or bitmap 586 image(.BMP) are acceptable. 588 o An element that contains the Chinese name 589 associated with the enterprise object to be created. 591 o An element that contains information of the 592 codes for provincial-level administrative divisions to which 593 enterprise object belongs. This document uses province code, city 594 code, and county code conforming to GB-T 2260-2007 to uniquely 595 identify the administrative divisions of the enterprise. 597 o An element that gives information of the city 598 code of the enterprise. 600 o An element that contains information of the 601 codes for county-level administrative divisions of the enterprise 602 object. 604 o An element that contains postal-address 605 information elaborated in Chinese. 607 o An element that contains English name associated 608 with the enterprise object to be created. 610 o An element that contains postal-address 611 information written in English . 613 o An element that contains the URL to the website 614 of the enterprise. 616 o An element that attaches a brief description of the 617 enterprise. 619 o An element that gives information of the contacts of 620 the enterprise object. The contains the following 621 child elements: 623 * An element that contains the name of the individual 624 that act as enterprise contacts. 626 * An element that contains the contact's email 627 address. 629 * An element that contains telephone number 630 associated with the contact. 632 o An element to elaborate the legal person 633 information of the enterprise object. It contains the following 634 child elements: 636 * An element that contains the name of an individual, 637 company, or other entity that has legal rights of the 638 enterprise. 640 * An element that gives information of the legal 641 person's certification type. Six kinds of corporate certificate 642 types are acceptable, which includes People's Republic of Chin 643 a Resident Identity Card, Mainland Travel Permit for Hong Kong 644 and Macao Residents, Mainland Travel Permit for Taiwan resident 645 s, Foreign Permanent Resident ID Card, Residence Permit for Hon 646 g Kong, Macao and Taiwan residents, Passport. 647 * An element that contains fully qualified 648 identification number of the enterprise legal person. 650 * An element that specifies format of legal 651 person's identification image file. 653 * An element that provides image file of the legal 654 person's ID. The image file is encoded using base64 schemas. 656 Example enterprise command: 658 C: 660 C: 662 C: 664 C: 666 C: 668 C: 88.1 670 C: 1 672 C: 1001 674 C: base64 676 C: png 678 C: taieryingfu 680 C: 01 682 C: 01 683 C: 01 685 C: cuihu 687 C: teleinfo 689 C: cuihu 691 C: http://www.teleinfo.cn/ 693 C: desc 695 C: 697 C: zhangsan 699 C: test@test.cn 701 C: 18888888888 703 C: 705 C: 707 C: zhangsan 709 C: 1 711 C: 1100000000000 713 C: png 715 C: base64 717 C: 719 C: 721 C: 723 C: 12345 725 C: 727 C: 729 When an EPP enterprise command has been processed 730 successfully, the EPP enterprise create element MUST be 731 replied to the client. It MUST contain the following child elements: 732 a element that identifies the result of processing, 733 and a element that has one child element. 734 The element with a child element called , 735 gives response information of an enterprise ID generated by the 736 server system for the enterprise object. 738 Example enterprise response: 740 S: 742 S: 744 S: 746 S: 748 S: Command completed successfully 750 S: 752 S: 754 S: 757 S: 00000001 759 S: 761 S: 763 S: 765 S: 12345 767 S: s12345 769 S: 771 S: 773 S: 775 An EPP error response MUST be returned if an enterprise 776 command cannot be processed for any reason. 778 Other than creating the enterprise object itself, EPP 779 command is also used in this mapping to create the digital object 780 identifier (also referred to as enterprise prefix) of the enterprise 781 object. 783 The enterprise identifier create mapping is used to submit an 784 application of an unused prefix under its Second Handle Registry 785 (SHR) prefix, that is also called naming authorities. The 786 element contains the following child element: 788 o A element that specifies the Second Handle 789 Registry (SHR) prefix to which the enterprise is subject. The 790 Second Handle Registry is entitled to allocate sub-prefix. An 791 enterprise can apply for more than one prefix and produces 792 identifier under each enterprise prefix by attaching a suffix. 794 o A element that contains information of an 795 enterprise ID generated by the server system for the enterprise 796 to uniquely identify the enterprise object. 798 o A element that provides the sub-prefix of 799 Second Handle Registry (SHR) prefix the enterprise intends to 800 apply for. 802 Example of enterprise identifier command: 804 C: 806 C: 808 C: 810 C: 812 C: 815 C: 88.1000 817 C: 00000001 819 C: 88.1000.1 821 C: 823 C: 825 C: 123456 827 C: 829 C: 831 When an enterprise identifier command has been processed 832 successfully, the EPP enterprise identifier create 833 replied to the client. 835 Example enterprise identifier response: 837 S: 839 S: 841 S: 843 S: 845 S: Command completed successfully 847 S: 849 S: 851 S: 12345 853 S: s12345 855 S: 857 S: 859 S: 861 An EPP error response MUST be returned if an enterprise identifier 862 command cannot be processed for any reason. 864 3.2.2. EPP Command 866 Delete semantics do not apply to enterprise objects, so there is no 867 enterprise mapping defined for the EPP command. 869 3.2.3. EPP Command 871 Renewal semantics do not apply to enterprise objects, so there is no 872 enterprise mapping defined for the EPP command. 874 3.2.4. EPP Command 876 Transfer semantics do not directly apply to enterprise objects, so 877 there is no mapping defined for the EPP command. 879 3.2.5. EPP Command 881 The EPP command provides an operation that allows a client 882 to modify the attributes of an enterprise. 884 Two enterprise update semantics are defined in this document to 885 update the enterprise object for the purpose of full-update and 886 incremental-update. 888 To modify significant information of the enterprise object such 889 enterprise type, Unified Social Credit Code, image document type of 890 credit certificate, image document, enterprise name, legal person 891 information, legal person's name, ID or other important information, 892 full-update command mapping MUST be used. 894 While incremental-update mapping is adopted to change 895 information like contacts and associated information, postal- 896 address, province code, city code, county code of the enterprise. 898 In addition to the standard EPP command elements, the full-update 899 command MUST contain an element that 900 identifies the enterprise object and attributes to be updated. The 901 full-update element MUST contain the following 902 elements: 904 o An element that contains the Second Handle 905 Registry (SHR)identifier to which the enterprise object belongs. 906 o An that gives information of an enterprise ID that is 907 generated by the server system for the enterprise object to 908 uniquely identify the enterprise. 910 o An element that is made up of the following child 911 elements: 913 * An element that specifies type of the enterprise 914 object. 916 * An element that contains fully qualified 917 certification code ,also called Uniform Social Credit Code of 918 the enterprise. 920 * An element that contains the image information 921 of the enterprise certificate with the format of base64. 923 * An element that specifies file format of 924 the enterprise certificate image. 926 * An element that contains the Chinese name 927 associated with the enterprise object to be updated. 929 * An element that specifies the code for 930 provincial-level administrative divisions to which enterprise 931 object belongs. 933 * An element that gives information of the city 934 code of the enterprise. 936 * An element that contains information of the 937 codes for county-level administrative divisions of the 938 enterprise object. 940 * An element that contains postal-address 941 information elaborated in Chinese. 943 * An element that contains English name 944 associated with the enterprise object to be updated. 946 * An element that contains postal-address 947 information written in English . 949 * An element that contains the URL to the 950 website of the enterprise. 952 * An element that attaches a brief description of 953 the enterprise. 955 * An element that contains three child elements: 956 an element to illustrate name of enterprise contact, 957 element that contains the contact's email address, 958 an element to specifies the contact's telephone 959 number 961 * An element that consists of the following 962 elements to illustrate the enterprise's legal person and 963 information associated: an element that contains the 964 name the enterprise's legal person, an element 965 that gives information of the identification type, an 966 element that illustrates identification number,an 967 element that specifies format of legal person 968 identification image file,an element that provides 969 image file of the legal person's ID. 971 Example full-update command: 973 C: 975 C: 977 C: 979 C: 981 C: 983 C: 88.1000 985 C: 00001 987 C: 989 C: 1 991 C: 1001 992 C: base64 994 C: png 996 C: taieryingfu 998 C: 01 1000 C: 01 1002 C: 01 1004 C: cuihu 1006 C: teleinfo 1008 C: cuihu 1010 C: http://www.teleinfo.cn/ 1012 C: desc 1014 C: 1016 C: zhangsan 1018 C: test@test.cn 1020 C: 18888888888 1022 C: 1024 C: 1026 C: zhangsan 1028 C: 1 1030 C: 1100000000000 1032 C: png 1034 C: base64 1036 C: 1038 C: 1040 C: 1042 C: 1044 C: 12345 1045 C: 1047 C: 1049 When a full-update command has been processed successfully, 1050 a server MUST respond with an EPP response with no 1051 element. 1053 Example full-update response: 1055 S: 1056 S: 1057 S: 1058 S: 1059 S: Command completed successfully 1060 S: 1061 S: 1062 S: 12345 1063 S: s12345 1064 S: 1065 S: 1066 S: 1068 The incremental-update mapping is defined to change part of 1069 the information of the enterprise object. The incremental 1070 command MUST contain an element that identifies the 1071 enterprise object to be updated. The element for 1072 incremental-update MUST contain: 1074 o An element that contains a username of the Second 1075 Handle Registry which is produced for the handle naming authority 1076 when registered. This element is provided to prove its 1077 qualification to change the enterprise object. 1078 o An element that gives information of an enterprise ID 1079 that is generated by the server system for the enterprise object 1080 to uniquely identify the enterprise. 1082 o An element that contains at least one of these child 1083 elements: 1085 * An OPTIONAL element that specifies the 1086 code for provincial-level administrative divisions to which 1087 enterprise object belongs. 1089 * An OPTIONAL element that gives information of 1090 the city code of the enterprise. 1092 * An OPTIONAL element that contains 1093 information of the codes for county-level administrative 1094 divisions of the enterprise object. 1096 * An OPTIONAL element that contains postal- 1097 address information elaborated in Chinese. 1099 * An OPTIONAL element that contains English name 1100 associated with the enterprise object to be updated. 1102 * An OPTIONAL element that contains postal- 1103 address information written in English . 1105 * An OPTIONAL element that contains the URL to 1106 the website of the enterprise. 1108 * An OPTIONAL element that attaches a brief 1109 description of the enterprise. 1111 * An OPTIONAL element that MUST contains all these 1112 elements: an element to illustrate name of 1113 enterprise contact, an element that contains the 1114 contact's email address, an element to specifies 1115 the contact's telephone number 1117 Example incremental-update command: 1118 C: 1120 C: 1122 C: 1124 C: 1126 C: 1128 C: shrUser001 1130 C: 00001 1132 C: 1134 C: 01 1136 C: 01 1138 C: 01 1140 C: cuihu 1141 C: cuihu 1143 C: http://www.teleinfo.cn/ 1145 C: desc 1147 C: 1149 C: zhangsan 1151 C: test@test.cn 1153 C: 18888888888 1155 C: 1157 C: 1159 C: 1161 C: 1163 C: 12345 1165 C: 1167 C: 1169 When an incremental-update command has been processed 1170 successfully, a server MUST respond with an EPP response with no 1171 element. 1173 Example incremental-update command response: 1175 S: 1177 S: 1179 S: 1181 S: 1183 S: Command completed successfully 1185 S: 1187 S: 1189 S: 12345 1191 S: s12345 1192 S: 1194 S: 1196 S: 1198 An EPP error response MUST be returned if an enterprise 1199 command could not be processed for any reason. 1201 4. Internationalization Considerations 1203 EPP is represented in XML, which provides native support for 1204 encoding information using the Unicode character set and its more 1205 compact representations including UTF-8. Conformant XML processors 1206 recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes 1207 provisions to identify and use other character encodings through use 1208 of an "encoding" attribute in an declaration, use of UTF-8 1209 is RECOMMENDED in environments where parser encoding support 1210 incompatibility exists. 1212 All date-time values presented via EPP MUST be expressed in 1213 Universal Coordinated Time using the Gregorian calendar. XML Schema 1214 allows use of time zone enterprises to indicate offsets from the 1215 zero meridian, but this option MUST NOT be used with EPP. The 1216 extended date-time form using upper case "T" and "Z" characters 1217 defined in [W3C.REC-xmlschema-2-20041028] MUST be used to represent 1218 date-time values, as XML Schema does not support truncated date-time 1219 forms or lower case "T" and "Z" characters. 1221 The syntax for handle enterprises described in this document MUST 1222 conform to [RFC3650], [RFC3651], [RFC3652]. The conformance 1223 requirements might change as a result of progressing work in 1224 developing standards for internationalized enterprise techniques. 1226 5. Security Considerations 1228 Authorization information as described in Section 3.2 is REQUIRED to 1229 create an enterprise object and its digital identifiers. This 1230 information is used in some query and transfer operations as an 1231 additional means of determining client authorization to perform the 1232 command. Failure to protect authorization information from 1233 inadvertent disclosure can result in unauthorized transfer 1234 operations and unauthorized information release. Both client and 1235 server MUST ensure that authorization information is stored and 1236 exchanged with high-grade encryption mechanisms to provide privacy 1237 services. 1239 The object mapping described in this document does not provide any 1240 other security services or introduce any additional considerations 1241 beyond those described by [RFC5730] or those caused by the protocol 1242 layers used by EPP. 1244 6. IANA Considerations 1246 This document uses URNs to describe XML namespaces and XML schemas 1247 conforming to a registry mechanism described in [RFC3688]. Two URI 1248 assignments have been registered by the IANA. 1250 Registration request for the enterprise namespace: 1252 URI: urn:ietf:params:xml:ns:enterprise-1.0 1254 Registrant Contact: See the "Author's Address" section of this 1255 document. 1257 XML: None. Namespace URIs do not represent an XML specification. 1259 Registration request for the enterprise XML schema: 1261 URI: urn:ietf:params:xml:schema:enterprise-1.0 1263 Registrant Contact: See the "Author's Address" section of this 1264 document. 1266 XML: See the "Formal Syntax" section of this document. 1268 7. Acknowledgments 1270 This document is based on an enterprise application of EPP.Thus, the 1271 author would like to thank J. Xie who suggested improvements and 1272 provided many invaluable comments. This document are individual 1273 submissions, based on the work done in RFC 5730. 1274 This document was prepared using 2-Word-v2.0.template.dot. 1276 8. References 1278 8.1. Normative References 1280 [W3C.REC-xml-20040204] Sperberg-McQueen, C., Maler, E., Yergeau, 1281 F., Paoli, J., and T. Bray, "Extensible Markup Language 1282 (XML) 1.0 (Third Edition)", World Wide Web Consortium 1283 FirstEdition REC-xml-20040204, February 2004, 1284 . 1286 [W3C.REC-xmlschema-1-20041028] Maloney, M., Thompson, H., 1287 Mendelsohn, N., and D. Beech, "XML Schema Part 1: 1288 Structures Second Edition", World Wide Web Consortium 1289 Recommendation REC-xmlschema-1-20041028, October 2004, 1290 . 1292 [W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML 1293 Schema Part 2: Datatypes Second Edition", World Wide Web 1294 Consortium Recommendation REC-xmlschema-2-20041028, 1295 October 2004, . [RFC0791] Postel, J., "Internet Protocol", 1297 STD 5, RFC 791, September 1981. 1299 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1300 STD 69, RFC 5730, August 2009. 1302 [RFC3650] Sun, S. and L. Lannom, "Handle System Overview", November 1303 2003. 1305 [RFC3651] Sun, S., Reilly, S. and L. Lannom, "Handle System 1306 Namespace and Service Definition", November 2003. 1308 [RFC3652] Sun, S., Reilly, S. and L. Lannom, "Handle System Protocol 1309 (ver 2.1) Specification", November 2003. 1311 8.2. Informative References 1313 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1314 10646", RFC 2781, February 2000. 1316 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support 1317 IPv6 Address Aggregation and Renumbering", RFC 2874, July 1318 2000. 1320 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1321 "DNS Extensions to Support IP Version 6", RFC 3596, 1322 October 2003. 1324 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1325 Architecture", RFC 4291, February 2006. 1327 Author's Address 1329 Yuying Chen 1330 CAICT 1331 No.52 Huayuan North Road, Haidian District 1332 Beijing, Beijing, 100191 1333 China 1335 Phone: +86 188 1008 2358 1336 Email: chenyuying@caict.ac.cn 1337 Jiagui Xie 1338 CAICT 1339 No.52 Huayuan North Road, Haidian District 1340 Beijing, Beijing, 100191 1341 China 1343 Phone: +86 150 0138 5070 1344 Email: xiejiagui@caict.ac.cn 1346 Zhiping Li 1347 CAICT 1348 No.52 Huayuan North Road, Haidian District 1349 Beijing, Beijing, 100191 1350 China 1352 Phone: +86 185 1107 1386 1353 Email: lizhiping@caict.ac.cn 1355 Hongyan Liu 1356 CAICT 1357 No.52 Huayuan North Road, Haidian District 1358 Beijing, Beijing, 100191 1359 China 1361 Phone: +86 13810863339 1362 Email: liuhongyan@caict.ac.cn 1364 Yingying Han 1365 CAICT 1366 No.52 Huayuan North Road, Haidian District 1367 Beijing, Beijing, 100191 1368 China 1370 Phone: +86 15201649023 1371 Email: hanyingying@caict.ac.cn