Internet Engineering Task Force Y. Chen
Internet Draft J. Xie
Intended status: Experimental Z. Li
Expires: October 25,2021 H. Liu
China Academy of Information and Communications Technology Y. Han
April 25,2021
National Identifier Top-level Node Interface Protocol
draft-chen-top-level-interface-protocol-03
AbstractThis 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 1, 2021.
Copyright Notice
Copyright (c) 2020 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 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 October 25,2021 [Page 1]
Internet-Draft Top-Level Node Interface Protocol April 25,2021 Chen, et al. Expires October 25,2021 [Page 2]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 3]
Internet-Draft Top-Level Node Interface Protocol April 25,2021 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. 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.
Chen, et al. Expires October 25,2021 [Page 4]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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. Internet-Draft Top-Level Node Interface Protocol April 25,2021 3.1.1. EPP <check> Command
Chen, et al. Expires October 25,2021 [Page 5]
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> C:</epp>
Chen, et al. Expires October 25,2021 [Page 6]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 7]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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> S: <svTRID>s12345</svTRID>
Chen, et al. Expires October 25,2021 [Page 8]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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> 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.
Chen, et al. Expires October 25,2021 [Page 9]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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> S: <prefix:svTRID>s123456</prefix:svTRID>
Chen, et al. Expires October 25,2021 [Page 10]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 11]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 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.
Chen, et al. Expires October 25,2021 [Page 12]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 Experts Group(.JPEG), Portable Network Graphics(.PNG), or bitmap image(.BMP) are acceptable.
Chen, et al. Expires October 25,2021 [Page 13]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
o An <ent:entNameCn> element that contains the Chinese nameassociated 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: * An <ent:name> element that contains the name of an individual, company, or other entity that has legal rights of the enterprise.
Chen, et al. Expires October 25,2021 [Page 14]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
* An <ent:idType> element that gives information of the legalperson'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> C: <ent:entCountyCode>01</ent:entCountyCode>
Chen, et al. Expires October 25,2021 [Page 15]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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>, gives response information of an enterprise ID generated by the server system for the enterprise object.
Chen, et al. Expires October 25,2021 [Page 16]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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: 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.
Chen, et al. Expires October 25,2021 [Page 17]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
o A <prefix:entId> element that contains information of an enterprise ID generated by the server system for the enterpriseto 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: S:<?xml version="1.0" encoding="UTF-8"?>
Chen, et al. Expires October 25,2021 [Page 18]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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. 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.
Chen, et al. Expires October 25,2021 [Page 19]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 20]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
* An <ent:entAddrCn> element that contains postal-addressinformation 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 October 25,2021 [Page 21]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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> C: </command>
Chen, et al. Expires October 25,2021 [Page 22]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 23]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
* An OPTIONAL <ent:entCountyCode> element that containsinformation 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 October 25,2021 [Page 24]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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> S: </trID>
Chen, et al. Expires October 25,2021 [Page 25]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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. Internet-Draft Top-Level Node Interface Protocol April 25,2021 6. IANA Considerations
Chen, et al. Expires October 25,2021 [Page 26]
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. The authors would like to thank J. Xie who suggested improvements and provided many invaluable comments. This document are 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 October 25,2021 [Page 27]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XMLSchema 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 ISO10646", 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 Jiagui Xie CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China
Chen, et al. Expires October 25,2021 [Page 28]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
Phone: +86 150 0138 5070 Email: xiejiagui@caict.ac.cnZhiping 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 October 25,2021 [Page 29]
