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
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 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
Chen, et al. Expires October 25,2021 [Page 1]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 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.
Chen, et al. Expires October 25,2021 [Page 4]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 5]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 6]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 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>
Chen, et al. Expires October 25,2021 [Page 8]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 9]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 10]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 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
Chen, et al. Expires October 25,2021 [Page 12]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 13]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 14]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
* 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 October 25,2021 [Page 15]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 16]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 17]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 18]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 19]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 20]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
* 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 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>
Chen, et al. Expires October 25,2021 [Page 22]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 23]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
* 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 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>
Chen, et al. Expires October 25,2021 [Page 25]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 26]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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. 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, "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 October 25,2021 [Page 28]
Internet-Draft Top-Level Node Interface Protocol April 25,2021
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 October 25,2021 [Page 29]