National Identifier Top-level Node Interface Protocol
draft-chen-top-level-interface-protocol-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Yuying Chen , Jiagui Xie , Zhiping Li , Hongyan Liu | ||
Last updated | 2019-11-17 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-chen-top-level-interface-protocol-00
Internet Engineering Task Force Y. Chen Internet Draft J. Xie Intended status: Experimental Z. Li Expires: MAY 17, 2020 November 17, 2019 H. Liu China Academy of Information and Communications Technology Y. Han National Identifier Top-level Node Interface Protocol draft-chen-top-level-interface-protocol-00 Abstract This document describes an Extensible Provisioning Protocol (EPP) for the provisioning and management of enterprises and identifiers between the server which is called Business Management System(BMS) and is entitled to manage the identifier top-level node and the client which is also referred to as Second Node Management System (SNMS).Specified in XML, the mapping defines EPP command syntax and semantics as applied to enterprise and identifier management. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 18, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Chen, et al. Expires May 17, 2020 [Page 1] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Chen, et al. Expires May 17,2020 [Page 2] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 Table of Contents 1. Introduction...................................................4 1.1. Conventions Used in This Document.........................4 2. Object Attributes..............................................4 2.1. Object Attributes.........................................4 2.2. Client Identifiers........................................5 2.3. Dates and Times...........................................5 2.4. IP Addresses..............................................5 3. EPP Command Mapping............................................5 3.1. EPP Query Commands........................................5 3.1.1. EPP <check> Command..................................6 3.1.2. EPP <info> Command...................................9 3.1.3. EPP <poll> Command...................................9 3.1.4. EPP <transfer> Query Command........................12 3.2. EPP Transform Commands...................................12 3.2.1. EPP <create> Command................................13 3.2.2. EPP <delete> Command................................19 3.2.3. EPP <renew> Command.................................19 3.2.4. EPP <transfer> Command..............................19 3.2.5. EPP <update> Command................................19 4. Internationalization Considerations...........................26 5. Security Considerations.......................................26 6. IANA Considerations...........................................27 7. Acknowledgments...............................................27 8. References....................................................27 8.1. Normative References.....................................27 8.2. Informative References...................................28 Chen, et al. Expires May 17,2020 [Page 3] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 1. Introduction Identifier Enterprises in this context are individuals or companies that act as digital object identifier registrars. Digital object identifier is a set of globally unique character strings with a specified format that may consist of digits, letters or notations which is an essential element of a digital object. This document describes the interface protocol of National identifier top-level node for the provision and management of identifiers and enterprises for version 1.0 of the Extensible Provisioning Protocol (EPP). This mapping is specified using the Extensible Markup Language (XML)1.0 as described in [W3C.REC-xml- 20040204] and XML Schema notation as described in [W3C.REC- xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. [RFC5730]provides a complete description of EPP command and response structures. A thorough understanding of the base protocol specification is necessary to understand the mapping described in this document. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this protocol. 2. Object Attributes EPP enterprise object and identifier object both have attributes and associated values that can be viewed and modified by the sponsoring client or the server. This section describes each attribute type in detail. The formal syntax for the attribute values described here can be found in the "Formal Syntax" section of this document and in the appropriate normative references. 2.1. Object Attributes Enterprise objects represent the registrar and the information resources related to an enterprise, such as identifier to be applied, certificate code, legal person, contacts, etc. Chen, et al. Expires May 17,2020 [Page 4] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 Business Management System (BMS) in this document represents a server system that is entitled to administrate the Global Handle Registry naming authorities, while Second Node Management System (SNMS) acts as an administrator to manage sub-naming authorities under the GHR naming authorities. This document provides an overview of the EPP mapping of both the enterprise object and identifier objects. The syntax for handle identifier namespace described in this document MUST conform to [RFC3650], [RFC3651], [RFC3652]. These conformance requirements might change in the future as a result of progressing work in developing standards for internationalized digital objects. 2.2. Client Identifiers All EPP enterprise clients are identified by a server-unique identifier. Client identifiers MUST conform to the "clIDType" syntax described in [RFC5730]. 2.3. Dates and Times Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form using upper case "T" and "Z" characters defined in [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time values, as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters. 2.4. IP Addresses The syntax for IPv4 addresses described in this document MUST conform to[RFC5730]. The syntax for IPv6 addresses described in this document MUST conform to [RFC4291]. Practical considerations for publishing IPv6 address information in zone files are documented in [RFC2874] and [RFC3596]. A server MAY reject IP addresses that have not been allocated for public use by IANA. 3. EPP Command Mapping A detailed description of the EPP syntax and semantics is specified in [RFC5730]. The command mappings described here are specifically for use in provisioning and managing enterprises and identifiers allocated to the enterprise via EPP. 3.1. EPP Query Commands EPP provides two commands to retrieve object information: <check> to determine if an EPP object can be provisioned within a repository, and <info> to retrieve detailed information associated with an EPP object. Chen, et al. Expires May 17,2020 [Page 5] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 3.1.1. EPP <check> Command The EPP <check> command mapping in this document is used to determine if materials of an enterprise object or the enterprise identifier have been registered. It provides a hint that allows a client to anticipate the success or failure of provisioning an object using the <create> command, as object-provisioning requirements are ultimately a matter of server policy. In addition to the standard EPP command elements, the enterprise <check> command MUST contain an <ent:check> element and an EPP enterprise <clTRID> element to illustrate ID of client system. An <ent:check> is made up of the following child elements: o An < ent:shrUserId > element that contains the fully qualified user ID of the Second Handle Registry which is in responsible for the enterprise to be queried. o An <ent:entCrtType> element that specifies certification type used by the enterprise. Two types of certifications are acceptable, the digital number 1 represents Unified Social Credit Code, while "3" means others. o An <ent:entCrtCode> element contains the fully qualified certification code of the enterprise which is used to uniquely identify and certificate the corporation or organization. Example enterprise <check> command: C:<?xml version="1.0" encoding="UTF-8"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <check> C: <ent:check xmlns:ent="urn:ietf:params:xml:ns:idis-ent-1.0"> C: <ent:shrUserId>shrUser001</ent:shrUserId> C: <ent:entCrtType>000001</ent:entCrtType> C: <ent:entCrtCode>000001</ent:entCrtCode> C: </ent:check> C: </check> C: <clTRID>12345</clTRID> C: </command> Chen, et al. Expires May 17,2020 [Page 6] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 C:</epp> When an enterprise <check> command has been processed successfully, a server MUST respond with an EPP <result> element, a <resData> element and a <trID> element: o An EPP <resData> element MUST contain a child <ent:chkData> element. The <ent:chkData > element has one <ent:entId> enterprise-specific element that contains a fully qualified enterprise number generated by the server system to identify the enterprise. o A <trID> element MUST contain two child elements: a <clTRID> element to illustrate client ID and a <svTRID> element to specifies the server ID. Example enterprise <check> response: S:<?xml version="1.0" encoding="UTF-8"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <ent:chkData xmlns:ent="urn:ietf:params:xml:ns:idis-ent-1.0"> S: <ent:entId>00001</ent:entId> S: </ent:chkData> S: </resData> S: <trID> S: <clTRID>12345</clTRID> S: <svTRID>s12345</svTRID> S: </trID> S: </response> S:</epp> The <check> command mapping to illustrate the client's request to check the enterprise identifier MUST contain an EPP <prefix:check> element. A < prefix:check> element contains two child elements: o An <prefix:shrPrefix> that contains the Second Handle Registry (SHR)identifier to which the enterprise object is subject. o An <prefix:prefix> provides the sub-prefix under the Second Handle Registry (SHR) prefix. Chen, et al. Expires May 17,2020 [Page 7] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 Example enterprise identifier <check> command: C:<?xml version="1.0" encoding="UTF-8"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <check> C: <prefix:check xmlns:prefix="urn:ietf:params:xml:ns:idis- entprefix-1.0"> C: <prefix:shrPrefix>88.1000</prefix:shrPrefix> C: <prefix:prefix>88.1000.1</prefix:prefix> C: </prefix:check> C: </check> C: <clTRID>12345</clTRID> C: </command> C:</epp> When an enterprise identifier <check> command has been processed successfully, a server MUST respond with an EPP <result> element, a <resData> element and a <trID> element. Example enterprise identifier <check> response: S:<?xml version="1.0" encoding="UTF-8"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <trID> S: <clTRID>12345</clTRID> Chen, et al. Expires May 17,2020 [Page 8] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 S: <svTRID>s12345</svTRID> S: </trID> S: </response> S:</epp> An EPP error response MUST be returned if a <check> command cannot be processed for any reason. 3.1.2. EPP <info> Command Info semantics do not directly apply to enterprise objects, so there is no mapping defined for the EPP <info> command. 3.1.3. EPP <poll> Command When a client has sent an enterprise identifier <create> command to apply for the enterprise's identifier, handle prefix in this case. The EPP <poll> command is defined to discover and retrieve service messages queued by a server for individual clients to synchronize result of the identifier <create> command. The <poll> command which is represented as an empty element with no child elements has an "op" attribute with value "req" to retrieve the first message from the server message queue. Example <poll> command: C:<?xml version="1.0" encoding="UTF-8"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="req"></poll> C: <clTRID>12345</clTRID> C: </command> C:</epp> Chen, et al. Expires May 17,2020 [Page 9] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 When the client system sends an EPP enterprise <poll> command to the server, and if the message result queue is not empty, a successful response with the first message from the message queue MUST be returned to the client. The standard <poll> command response MUST contain the following child elements: o An EPP <result> element that contains a result code and a message that notes a human-readable description of the response code. o A <msgQ> element that describes messages queued for client retrieval. o An object-specific <resData> element that contains information of the enterprise object and digital object identifier related to it :a <prefix:clTRID> element to specify the client ID of enterprise, a <prefix:svTRID> element to identify the server, a <prefix:entId> element that contains the fully qualified enterprise ID number, a <prefix:prefix> element that includes identifier registered by the enterprise, a <prefix:state> element where "1" means normal, and a <prefix:auditResult> element with a digital "1" to notify a successful result of the prefix create command. Example <poll> response: S:<?xml version="1.0" encoding="UTF-8"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="5" id="12345"> S: <qDate>2018-10-19T15:09:37.393+08:00</qDate> S: <msg>1234</msg> S: </msgQ> S: <resData> S: <prefix:resData xmlns:prefix="urn:ietf:params:xml:ns:idis- entprefix-1.0"> S: <prefix:clTRID>123456</prefix:clTRID> Chen, et al. Expires May 17,2020 [Page 10] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 S: <prefix:svTRID>s123456</prefix:svTRID> S: <prefix:entId>00000001</prefix:entId> S: <prefix:prefix>88.1000.1</prefix:prefix> S: <prefix:state>1</prefix:state> S: <prefix:auditResult>1</prefix:auditResult> S: <prefix:auditResultMsg> </prefix:auditResultMsg> S: </prefix:resData> S: </resData> S: <trID> S: <clTRID>12345</clTRID> S: <svTRID>s12345</svTRID> S: </trID> S: </response> S:</epp> The <poll> response message is then received by the client, and the client MUST send a response request with a message with an explicit acknowledgement to confirm that the message has been received. Example <poll> acknowledgement command: C:<?xml version="1.0" encoding="UTF-8"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="ack" msgID="00001"></poll> C: <clTRID>12345</clTRID> C: </command> C:</epp> An EPP enterprise <poll> acknowledgement response notes the ID of the message that has been acknowledged and the number of messages remaining in the queue. Chen, et al. Expires May 17,2020 [Page 11] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 Example <poll> acknowledgement response: S:<?xml version="1.0" encoding="UTF-8"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <msgQ count="5" id="12345"></msgQ> S: <trID> S: <clTRID>12345</clTRID> S: <svTRID>s12345</svTRID> S: </trID> S: </response> S:</epp> 3.1.4. EPP <transfer> Query Command Transfer query semantics do not directly apply to enterprise objects, so there is no mapping defined for the EPP <transfer> query command. 3.2. EPP Transform Commands EPP provides two commands to transform enterprise objects: <create> to create an instance of an enterprise object, and <update> to change information associated with an enterprise object. This document does not define enterprise-object mappings for the EPP <renew>, <delete> and <transfer> commands. Transform commands are typically processed and completed in real time. Server operators MAY receive and process transform commands but defer completing the requested action if human or third-party review is required before the requested action can be completed. In such situations, the server MUST return a 1001 response code to the Chen, et al. Expires May 17,2020 [Page 12] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 client to note that the command has been received and processed but that the requested action is pending. The server MUST also manage the status of the object that is the subject of the command to reflect the initiation and completion of the requested action. Once the action has been completed; all clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed. Other notification methods MAY be used in addition to the required service message. Server operators SHOULD confirm that a client is authorized to perform a transform command on an enterprise object. Any attempt to transform an enterprise object by an unauthorized client MUST be rejected, and the server MUST return a 2201 response code to the client to note that the client lacks privileges to execute the requested command. 3.2.1. EPP <create> Command The EPP <create> command provides an operation that allows a client to send a create request of an enterprise object under the condition that the Second Handle Registry (SHR) has been registered. In addition to the standard EPP command elements, the <create> command MUST contain an <ent:create> element that specifies the enterprise to be created. The <ent:create> element contains the following child elements: o An <ent:shrPrefix> element that contains the Second Handle Registry (SHR)identifier to which the enterprise object to be created belongs. o An <ent:entType> element that specifies type of the enterprise object. The enterprise object MAY be type of government offices, institutions, social groups, commercial enterprises or others. Detailed category in EPP enterprise mapping completely complies with the national standard of industry categories. o An <ent:entCrCode> element that contains fully qualified certification code ,also called Uniform Social Credit Code of the enterprise which is represented by 18 numerals or uppercase English letters. o An <ent:entCrtImg> element that contains the image information of the enterprise certificate, which is processed with base64 encoding schemes. o An <ent:entCrtImgType> element that specifies file format of the enterprise certificate image. Image formats of Joint Photographic Chen, et al. Expires May 17,2020 [Page 13] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 Experts Group(.JPEG), Portable Network Graphics(.PNG), or bitmap image(.BMP) are acceptable. o An <ent:entNameCn> element that contains the Chinese name associated with the enterprise object to be created. o An <ent:entProvinceCode> element that contains information of the codes for provincial-level administrative divisions to which enterprise object belongs. This document uses province code, city code, and county code conforming to GB-T 2260-2007 to uniquely identify the administrative divisions of the enterprise. o An <ent:entCityCode> element that gives information of the city code of the enterprise. o An <ent:entCountyCode> element that contains information of the codes for county-level administrative divisions of the enterprise object. o An <ent:entAddrCn> element that contains postal-address information elaborated in Chinese. o An <ent:entNameEn> element that contains English name associated with the enterprise object to be created. o An <ent:entAddrEn > element that contains postal-address information written in English . o An <ent:entWebSite> element that contains the URL to the website of the enterprise. o An <ent:entDesc> element that attaches a brief description of the enterprise. o An <ent:contact> element that gives information of the contacts of the enterprise object. The <ent:contact> contains the following child elements: * An <ent:name> element that contains the name of the individual that act as enterprise contacts. * An <ent:email> element that contains the contact's email address. * An <ent:phone> element that contains telephone number associated with the contact. o An <ent:legalPerson > element to elaborate the legal person information of the enterprise object. It contains the following child elements: Chen, et al. Expires May 17,2020 [Page 14] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 * An <ent:name> element that contains the name of an individual, company, or other entity that has legal rights of the enterprise. * An <ent:idType> element that gives information of the legal person's certification type. Six kinds of corporate certificate types are acceptable, which includes People's Republic of Chin a Resident Identity Card, Mainland Travel Permit for Hong Kong and Macao Residents, Mainland Travel Permit for Taiwan resident s, Foreign Permanent Resident ID Card, Residence Permit for Hon g Kong, Macao and Taiwan residents, Passport. * An <ent:idNo> element that contains fully qualified identification number of the enterprise legal person. * An <ent:idImgType> element that specifies format of legal person's identification image file. * An <ent:idImg> element that provides image file of the legal person's ID. The image file is encoded using base64 schemas. Example enterprise <create> command: C:<?xml version="1.0" encoding="UTF-8"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <ent:create xmlns:ent="urn:ietf:params:xml:ns:idis-ent-1.0"> C: <ent:shrPrefix>88.1</ent:shrPrefix> C: <ent:entType>1</ent:entType> C: <ent:entCrCode>1001</ent:entCrCode> C: <ent:entCrtImg>base64</ent:entCrtImg> C: <ent:entCrtImgType>png</ent:entCrtImgType> C: <ent:entNameCn>taieryingfu</ent:entNameCn> C: <ent:entProvinceCode>01</ent:entProvinceCode> C: <ent:entCityCode>01</ent:entCityCode> Chen, et al. Expires May 17,2020 [Page 15] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 C: <ent:entCountyCode>01</ent:entCountyCode> C: <ent:entAddrCn>cuihu</ent:entAddrCn> C: <ent:entNameEn>teleinfo</ent:entNameEn> C: <ent:entAddrEn>cuihu</ent:entAddrEn> C: <ent:entWebSite>http://www.teleinfo.cn/</ent:entWebSite> C: <ent:entDesc>desc</ent:entDesc> C: <ent:contact> C: <ent:name>zhangsan</ent:name> C: <ent:email>test@test.cn</ent:email> C: <ent:phone>18888888888</ent:phone> C: </ent:contact> C: <ent:legalPerson> C: <ent:name>zhangsan</ent:name> C: <ent:idType>1</ent:idType> C: <ent:idNo>1100000000000</ent:idNo> C: <ent:idImgType>png</ent:idImgType> C: <ent:idImg>base64</ent:idImg> C: </ent:legalPerson> C: </ent:create> C: </create> C: <clTRID>12345</clTRID> C: </command> C:</epp> When an EPP enterprise <create> command has been processed successfully, the EPP enterprise create <response> element MUST be replied to the client. It MUST contain the following child elements: a <result code> element that identifies the result of processing, and a <resData> element that has one child <ent:creData> element. The <ent:creData> element with a child element called <ent:entId>, Chen, et al. Expires May 17,2020 [Page 16] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 gives response information of an enterprise ID generated by the server system for the enterprise object. Example enterprise <create> response: S:<?xml version="1.0" encoding="UTF-8"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <ent:creData xmlns:ent="urn:ietf:params:xml:ns:idis-ent- 1.0"> S: <ent:entId>00000001</ent:entId> S: </ent:creData> S: </resData> S: <trID> S: <clTRID>12345</clTRID> S: <svTRID>s12345</svTRID> S: </trID> S: </response> S:</epp> An EPP error response MUST be returned if an enterprise <create> command cannot be processed for any reason. Other than creating the enterprise object itself, EPP <create> command is also used in this mapping to create the digital object identifier (also referred to as enterprise prefix) of the enterprise object. The enterprise identifier create mapping is used to submit an application of an unused prefix under its Second Handle Registry (SHR) prefix, that is also called naming authorities. The <prefix:create> element contains the following child element: Chen, et al. Expires May 17,2020 [Page 17] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 o A <prefix:shrPrefix> element that specifies the Second Handle Registry (SHR) prefix to which the enterprise is subject. The Second Handle Registry is entitled to allocate sub-prefix. An enterprise can apply for more than one prefix and produces identifier under each enterprise prefix by attaching a suffix. o A <prefix:entId> element that contains information of an enterprise ID generated by the server system for the enterprise to uniquely identify the enterprise object. o A <prefix:prefix> element that provides the sub-prefix of Second Handle Registry (SHR) prefix the enterprise intends to apply for. Example of enterprise identifier <create> command: C:<?xml version="1.0" encoding="UTF-8"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <prefix:create xmlns:prefix="urn:ietf:params:xml:ns:prefix- 1.0"> C: <prefix:shrPrefix>88.1000</prefix:shrPrefix> C: <prefix:entId>00000001</prefix:entId> C: <prefix:prefix>88.1000.1</prefix:prefix> C: </prefix:create> C: </create> C: <clTRID>123456</clTRID> C: </command> C:</epp> When an enterprise identifier <create> command has been processed successfully, the EPP enterprise identifier create <response> replied to the client. Example enterprise identifier <create> response: Chen, et al. Expires May 17,2020 [Page 18] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 S:<?xml version="1.0" encoding="UTF-8"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <trID> S: <clTRID>12345</clTRID> S: <svTRID>s12345</svTRID> S: </trID> S: </response> S:</epp> An EPP error response MUST be returned if an enterprise identifier <create> command cannot be processed for any reason. 3.2.2. EPP <delete> Command Delete semantics do not apply to enterprise objects, so there is no enterprise mapping defined for the EPP <delete> command. 3.2.3. EPP <renew> Command Renewal semantics do not apply to enterprise objects, so there is no enterprise mapping defined for the EPP <renew> command. 3.2.4. EPP <transfer> Command Transfer semantics do not directly apply to enterprise objects, so there is no mapping defined for the EPP <transfer> command. 3.2.5. EPP <update> Command The EPP <update> command provides an operation that allows a client to modify the attributes of an enterprise. Two enterprise update semantics are defined in this document to update the enterprise object for the purpose of full-update and incremental-update. Chen, et al. Expires May 17,2020 [Page 19] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 To modify significant information of the enterprise object such enterprise type, Unified Social Credit Code, image document type of credit certificate, image document, enterprise name, legal person information, legal person's name, ID or other important information, full-update <update> command mapping MUST be used. While incremental-update <update> mapping is adopted to change information like contacts and associated information, postal- address, province code, city code, county code of the enterprise. In addition to the standard EPP command elements, the full-update <update> command MUST contain an <ent:update > element that identifies the enterprise object and attributes to be updated. The full-update <ent:update> element MUST contain the following elements: o An <ent:shrPrefix> element that contains the Second Handle Registry (SHR)identifier to which the enterprise object belongs. o An <ent:entId> that gives information of an enterprise ID that is generated by the server system for the enterprise object to uniquely identify the enterprise. o An <ent:chgAll> element that is made up of the following child elements: * An <ent:entType> element that specifies type of the enterprise object. * An <ent:entCrCode> element that contains fully qualified certification code ,also called Uniform Social Credit Code of the enterprise. * An <ent:entCrtImg> element that contains the image information of the enterprise certificate with the format of base64. * An <ent:entCrtImgType> element that specifies file format of the enterprise certificate image. * An <ent:entNameCn> element that contains the Chinese name associated with the enterprise object to be updated. * An <ent:entProvinceCode> element that specifies the code for provincial-level administrative divisions to which enterprise object belongs. * An <ent:entCityCode> element that gives information of the city code of the enterprise. * An <ent:entCountyCode> element that contains information of the codes for county-level administrative divisions of the enterprise object. Chen, et al. Expires May 17,2020 [Page 20] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 * An <ent:entAddrCn> element that contains postal-address information elaborated in Chinese. * An <ent:entNameEn> element that contains English name associated with the enterprise object to be updated. * An <ent:entAddrEn > element that contains postal-address information written in English . * An <ent:entWebSite> element that contains the URL to the website of the enterprise. * An <ent:entDesc> element that attaches a brief description of the enterprise. * An <ent:contact> element that contains three child elements: an <ent:name> element to illustrate name of enterprise contact, <ent:email> element that contains the contact's email address, an <ent:phone> element to specifies the contact's telephone number * An <ent:legalPerson> element that consists of the following elements to illustrate the enterprise's legal person and information associated: an <ent:name> element that contains the name the enterprise's legal person, an <ent:idType> element that gives information of the identification type, an <ent:idNo> element that illustrates identification number,an <ent:idImgType> element that specifies format of legal person identification image file,an <ent:idImg> element that provides image file of the legal person's ID. Example full-update <update> command: C:<?xml version="1.0" encoding="UTF-8"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <ent:update xmlns:ent="urn:ietf:params:xml:ns:idis-ent-1.0"> C: <ent:shrPrefix>88.1000</ent:shrPrefix> C: <ent:entId>00001</ent:entId> C: <ent:chgAll> C: <ent:entType>1</ent:entType> C: <ent:entCrCode>1001</ent:entCrCode> Chen, et al. Expires May 17,2020 [Page 21] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 C: <ent:entCrtImg>base64</ent:entCrtImg> C: <ent:entCrtImgType>png</ent:entCrtImgType> C: <ent:entNameCn>taieryingfu</ent:entNameCn> C: <ent:entProvinceCode>01</ent:entProvinceCode> C: <ent:entCityCode>01</ent:entCityCode> C: <ent:entCountyCode>01</ent:entCountyCode> C: <ent:entAddrCn>cuihu</ent:entAddrCn> C: <ent:entNameEn>teleinfo</ent:entNameEn> C: <ent:entAddrEn>cuihu</ent:entAddrEn> C: <ent:entWebSite>http://www.teleinfo.cn/</ent:entWebSite> C: <ent:entDesc>desc</ent:entDesc> C: <ent:contact> C: <ent:name>zhangsan</ent:name> C: <ent:email>test@test.cn</ent:email> C: <ent:phone>18888888888</ent:phone> C: </ent:contact> C: <ent:legalPerson> C: <ent:name>zhangsan</ent:name> C: <ent:idType>1</ent:idType> C: <ent:idNo>1100000000000</ent:idNo> C: <ent:idImgType>png</ent:idImgType> C: <ent:idImg>base64</ent:idImg> C: </ent:legalPerson> C: </ent:chgAll> C: </ent:update> C: </update> C: <clTRID>12345</clTRID> Chen, et al. Expires May 17,2020 [Page 22] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 C: </command> C:</epp> When a full-update <update> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element. Example full-update <update> response: S:<?xml version="1.0" encoding="UTF-8"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <trID> S: <clTRID>12345</clTRID> S: <svTRID>s12345</svTRID> S: </trID> S: </response> S:</epp> The incremental-update <update> mapping is defined to change part of the information of the enterprise object. The incremental <update> command MUST contain an <ent:update > element that identifies the enterprise object to be updated. The <ent:update> element for incremental-update MUST contain: o An <ent:shrUserId> element that contains a username of the Second Handle Registry which is produced for the handle naming authority when registered. This element is provided to prove its qualification to change the enterprise object. o An <ent:entId> element that gives information of an enterprise ID that is generated by the server system for the enterprise object to uniquely identify the enterprise. o An <ent:chg> element that contains at least one of these child elements: * An OPTIONAL <ent:entProvinceCode> element that specifies the code for provincial-level administrative divisions to which enterprise object belongs. * An OPTIONAL <ent:entCityCode> element that gives information of the city code of the enterprise. Chen, et al. Expires May 17,2020 [Page 23] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 * An OPTIONAL <ent:entCountyCode> element that contains information of the codes for county-level administrative divisions of the enterprise object. * An OPTIONAL <ent:entAddrCn> element that contains postal- address information elaborated in Chinese. * An OPTIONAL <ent:entNameEn> element that contains English name associated with the enterprise object to be updated. * An OPTIONAL <ent:entAddrEn > element that contains postal- address information written in English . * An OPTIONAL <ent:entWebSite> element that contains the URL to the website of the enterprise. * An OPTIONAL <ent:entDesc> element that attaches a brief description of the enterprise. * An OPTIONAL <ent:contact> element that MUST contains all these elements: an <ent:name> element to illustrate name of enterprise contact, an <ent:email> element that contains the contact's email address, an <ent:phone> element to specifies the contact's telephone number Example incremental-update <update> command: C:<?xml version="1.0" encoding="UTF-8"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <ent:update xmlns:ent="urn:ietf:params:xml:ns:idis-ent-1.0"> C: <ent:shrUserId>shrUser001</ent:shrUserId> C: <ent:entId>00001</ent:entId> C: <ent:chg> C: <ent:entProvinceCode>01</ent:entProvinceCode> C: <ent:entCityCode>01</ent:entCityCode> C: <ent:entCountyCode>01</ent:entCountyCode> C: <ent:entAddrCn>cuihu</ent:entAddrCn> Chen, et al. Expires May 17,2020 [Page 24] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 C: <ent:entAddrEn>cuihu</ent:entAddrEn> C: <ent:entWebSite>http://www.teleinfo.cn/</ent:entWebSite> C: <ent:entDesc>desc</ent:entDesc> C: <ent:contact> C: <ent:name>zhangsan</ent:name> C: <ent:email>test@test.cn</ent:email> C: <ent:phone>18888888888</ent:phone> C: </ent:contact> C: </ent:chg> C: </ent:update> C: </update> C: <clTRID>12345</clTRID> C: </command> C:</epp> When an incremental-update <update> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element. Example incremental-update <update> command response: S:<?xml version="1.0" encoding="UTF-8"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <trID> S: <clTRID>12345</clTRID> S: <svTRID>s12345</svTRID> Chen, et al. Expires May 17,2020 [Page 25] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 S: </trID> S: </response> S:</epp> An EPP error response MUST be returned if an enterprise <update> command could not be processed for any reason. 4. Internationalization Considerations EPP is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists. All date-time values presented via EPP MUST be expressed in Universal Coordinated Time using the Gregorian calendar. XML Schema allows use of time zone enterprises to indicate offsets from the zero meridian, but this option MUST NOT be used with EPP. The extended date-time form using upper case "T" and "Z" characters defined in [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time values, as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters. The syntax for handle enterprises described in this document MUST conform to [RFC3650], [RFC3651], [RFC3652]. The conformance requirements might change as a result of progressing work in developing standards for internationalized enterprise techniques. 5. Security Considerations Authorization information as described in Section 3.2 is REQUIRED to create an enterprise object and its digital identifiers. This information is used in some query and transfer operations as an additional means of determining client authorization to perform the command. Failure to protect authorization information from inadvertent disclosure can result in unauthorized transfer operations and unauthorized information release. Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy services. The object mapping described in this document does not provide any other security services or introduce any additional considerations beyond those described by [RFC5730] or those caused by the protocol layers used by EPP. Chen, et al. Expires May 17,2020 [Page 26] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 6. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been registered by the IANA. Registration request for the enterprise namespace: URI: urn:ietf:params:xml:ns:enterprise-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: None. Namespace URIs do not represent an XML specification. Registration request for the enterprise XML schema: URI: urn:ietf:params:xml:schema:enterprise-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: See the "Formal Syntax" section of this document. 7. Acknowledgments This document is based on an enterprise application of EPP.Thus, the author would like to thank J. Xie who suggested improvements and provided many invaluable comments. This document are individual submissions, based on the work done in RFC 5730. This document was prepared using 2-Word-v2.0.template.dot. 8. References 8.1. Normative References [W3C.REC-xml-20040204] Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J., and T. Bray, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>. [W3C.REC-xmlschema-1-20041028] Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. Chen, et al. Expires May 17,2020 [Page 27] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 [W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2- 20041028>. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009. [RFC3650] Sun, S. and L. Lannom, "Handle System Overview", November 2003. [RFC3651] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace and Service Definition", November 2003. [RFC3652] Sun, S., Reilly, S. and L. Lannom, "Handle System Protocol (ver 2.1) Specification", November 2003. 8.2. Informative References [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. Author's Address Yuying Chen CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China Phone: +86 188 1008 2358 Email: chenyuying@caict.ac.cn Chen, et al. Expires May 17,2020 [Page 28] Internet-Draft Top-Level Node Interface Protocol November 16, 2019 Jiagui Xie CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China Phone: +86 150 0138 5070 Email: xiejiagui@caict.ac.cn Zhiping Li CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China Phone: +86 185 1107 1386 Email: lizhiping@caict.ac.cn Hongyan Liu CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China Phone: +86 13810863339 Email: liuhongyan@caict.ac.cn Yingying Han CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China Phone: +86 15201649023 Email: hanyingying@caict.ac.cn Chen, et al. Expires May 17,2020 [Page 29]