Skip to main content

National Identifier Top-level Node Interface Protocol
draft-chen-top-level-interface-protocol-00

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]