Internet DRAFT - draft-chen-epp-identifier-mapping
draft-chen-epp-identifier-mapping
Internet Engineering Task Force Y. Chen
Internet Draft J. Xie
Intended status: Experimental Z. Li
Expires: February 24, 2021 Z. Fan
China Academy of Information and Communications Technology
August 17, 2020
Extensible Provisioning Protocol (EPP) Industrial Internet
Identifier Mapping
draft-chen-epp-identifier-mapping-03
Abstract
This document describes an Extensible Provisioning Protocol
(EPP)mapping for the provisioning and management of Industrial
Internet Identifiers. Specified in XML, the mapping defines EPP
command syntax and semantics as applied to identifiers.
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 February 24, 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 February 17,2021 [Page 1]
Internet-Draft EPP Identifier Mapping August 17,2020
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 February 17,2021 [Page 2]
Internet-Draft EPP Identifier Mapping August 17,2020
Table of Contents
1. Introduction ................................................... 4
1.1. Conventions Used in This Document ......................... 4
1.2. Scope of Experimentation ................................ 4
2. Object Attributes .............................................. 4
2.1. Industrial Internet Identifier Object ..................... 5
2.2. Client Identifiers ........................................ 5
2.3. Status Values ............................................. 5
2.4. Dates and Times.............................................7
2.5. IP Addresses ...............................................7
3. EPP Command Mapping ............................................ 7
3.1. EPP Query Commands ........................................ 7
3.1.1. EPP <check> Command ................................ 8
3.1.2. EPP <info> Command ................................ 10
3.1.3. EPP <transfer> Query Command ........................ 14
3.2. EPP Transform Commands .................................. 14
3.2.1. EPP <create> Command .............................. 15
3.2.2. EPP <delete> Command .............................. 19
3.2.3. EPP <renew> Command .............................. 20
3.2.4. EPP <transfer> Command ............................ 20
3.2.5. EPP <update> Command ............................. 20
4. Formal Syntax ................................................. 25
5. Internationalization Considerations ........................... 33
6. Security Considerations ..................................... 34
7. IANA Considerations ........................................... 34
8. Acknowledgments ................................................35
9. References .....................................................35
9.1. Normative References ................................... 35
9.2. Informative References ................................. 36
Chen, et al. Expires February 17,2021 [Page 3]
Internet-Draft EPP Identifier Mapping August 17,2020
1. Introduction
Industrial Internet Identifiers are character strings with a
specified format that may consist of digits, letters or notations
being structured in a way that is interpretable by one or more
computational facilities.
This document describes an Industrial Internet Identifier mapping
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
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.
1.2. Scope of Experimentation
This document describes an experimental extension to EPP protocol.
This section specifies scope of this experiment and how it can yield
useful information.
This EPP extension is designed to manage the registration,
modification and resolution of digital objects, handles, OID, for
example throughout the Industrial Internet. According to the
definition of EPP, this extension is an XML text protocol that
permits multiple service providers to perform object-provisioning
operations using a shared central object repository. It is designed
for use in a layered protocol environment. Bindings to specific
transport and security protocols are outside the scope of this
specification.
Chen, et al. Expires February 17,2021 [Page 4]
Internet-Draft EPP Identifier Mapping August 17,2020
Given the above points, the experiment can be run on the open
Internet between consenting client and server implementations.
2. Object Attributes
An EPP identifier object has 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. Industrial Internet Identifier Object
Industrial Internet Identifiers are character strings with a
specified format that may consist of digits, letters or notations
being structured in a way that is interpretable by one or more
computational facilities.
It is an unique persistent set of bits used to identify and obtain
state information about physical resource such as machines,
products, or digital resources such as algorithms, manufacturing
process, etc.
This document provides an overview of the EPP mapping of Industrial
Internet Identification. Handle mapping is specified as an example,
while description in this document applies to other identification
techniques as well.
The syntax for handle namespace described in this document MUST
conform to [RFC3650], [RFC3651], [RFC3652]. Handle identifiers are
character strings with a specified length and a specified format.
All handle identifiers are of the form prefix/suffix where, by
default, the prefix may first be resolved to locate the specific
identifier service and the suffix may be any bit sequence. Epp
mapping on the prefix examples are provided in this document while
it MAY also apply to handle identifiers with suffix.
These conformance requirements might change in the future as a
result of progressing work in developing standards for
internationalized digital object identification.
2.2. Client Identifiers
All EPP clients are identified by a server-unique identifier. Client
identifiers conform to the "clIDType" syntax described in [RFC5730].
2.3. Status Values
An EPP identifier object MUST always have at least one associated
status value. Status values MAY be set only by the client that
sponsors an identifier object and by the server on which the object
Chen, et al. Expires February 17,2021 [Page 5]
Internet-Draft EPP Identifier Mapping August 17,2020
resides. A client can change the status of object using the EPP
<update> command. Each status value MAY be accompanied by a string
of human-readable text that describes the rationale for the status
applied to the object.
A client MUST NOT alter status values set by the server. A server
MAY alter or override status values set by a client, subject to
local server policies. The status of an object MAY change as a
result of either a client-initiated transform command or an action
performed by a server operator.
Status values that can be added or removed by a client are prefixed
with "client". Corresponding status values that can be added or
removed by a server are prefixed with "server". Status values that
do not begin with either "client" or "server" are server-managed.
Status Value Descriptions:
- clientDeleteProhibited, serverDeleteProhibited
Requests to delete the object MUST be rejected.
- clientUpdateProhibited, serverUpdateProhibited
Requests to update the object (other than to remove this status)
MUST be rejected.
- linked
The identifier object has at least one active association with
another object. Servers SHOULD provide services to determine
existing object associations.
- ok
This is the normal status value for an object that has no pending
operations or prohibitions. This value is set and removed by the
server as other status values are added or removed.
- pendingCreate, pendingDelete, pendingTransfer, pendingUpdate
A transform command has been processed for the object, but the
action has not been completed by the server. Server operators can
delay action completion for a variety of reasons, such as to allow
for human review or third-party action. A transform command that is
processed, but whose requested action is pending, is noted with
response code 1001.
When the requested action has been completed, the pendingCreate,
pendingDelete, pendingTransfer, or pendingUpdate status value MUST
be removed. All clients involved in the transaction MUST be
Chen, et al. Expires February 17,2021 [Page 6]
Internet-Draft EPP Identifier Mapping August 17,2020
notified using a service message that the action has been completed
and that the status of the object has changed.
"ok" status MAY only be combined with "linked" status.
"linked" status MAY be combined with any status.
"pendingDelete" status MUST NOT be combined with either
"clientDeleteProhibited" or "serverDeleteProhibited" status.
"pendingUpdate" status MUST NOT be combined with either
"clientUpdateProhibited" or "serverUpdateProhibited" status.
The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate
status values MUST NOT be combined with each other.
Other status combinations not expressly prohibited MAY be used.
2.4. 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.5. 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 Industrial Internet identifiers
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,
Chen, et al. Expires February 17,2021 [Page 7]
Internet-Draft EPP Identifier Mapping August 17,2020
and <info> to retrieve detailed information associated with an EPP
object.
3.1.1. EPP <check> Command
The EPP <check> command is used to determine if an object can be
provisioned within a repository. 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 <check>
command MUST contain an <identifier: check> element that recognizes
the identifier namespace. The <identifier: check> element contains
the following child elements:
o One or more <identifier:name> elements that contain the fully
qualified names of the identifier objects to be queried.
example <check> command:
C:<?xml version="1.0" encoding="utf-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi=
C:"http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=
C:"urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
C: <command>
C: <check>
C: <identifier:check xmlns:identifier="urn:ietf:params:xml:ns:
C: identifier-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:
C: identifier-1.0 identifier-1.0.xsd">
C: <identifier:name>88.1000.1</identifier:name>
C: <identifier:name>88.1000.2</identifier:name>
C: </identifier:check>
C: </check>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <check> command has been processed successfully, a server
MUST respond with an EPP <resData> element that MUST contain a child
element that identifies the identifier object namespace. The child
elements of the <resData> element are identifier-specific, though
the EPP <resData> element MUST contain a child <identifier:chkData>
element that contains one or more <identifier:cd> (check data)
elements. Each <identifier:cd> element contains the following child
elements:
Chen, et al. Expires February 17,2021 [Page 8]
Internet-Draft EPP Identifier Mapping August 17,2020
o An identifier-specific element that identifies the queried
identifier.
This element MUST contain an "avail" attribute whose value
indicates object availability (can it be provisioned or not) at
the moment the <check> command was completed. A value of "1" or
"true" means that the identifier can be provisioned. A value of "0"
or "false" means that the identifier cannot be provisioned.
o An <identifier:reason> element that is provided when an
identifier cannot be provisioned. This element contains server-
specific text to help explain why the identifier cannot be
provisioned. This text MUST be represented in the response
language previously negotiated with the client; an OPTIONAL "lang"
attribute MAY be present to identify the language if the
negotiated value is something other than the default value of "en"
(English).
Example <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: <identifier:chkData xmlns:identifier="urn:ietf:params:
S: xml:ns:identifier-1.0">
S: <identifier:cd>
S: <identifier:name avail="false">88.1000.1
S: </identifier:name>
S: <identifier:reason>The identifier already exists
S: </identifier:reason>
S: </identifier:cd>
S: <identifier:cd>
S: <identifier:name avail="true">88.1000.1
S: </identifier:name>
S: </identifier:cd>
S: </identifier:chkData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
Chen, et al. Expires February 17,2021 [Page 9]
Internet-Draft EPP Identifier Mapping August 17,2020
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <check> command cannotbe
processed for any reason.
3.1.2. EPP <info> Command
The EPP <info> command is used to retrieve information associated
with an Industrial Internet Identifier object. In addition to the
standard EPP command elements, the <info> command MUST contain an
<identifier:info> element that identifies the identifier namespace.
The <identifier:info> element contains one child element:
An <identifier:name> element that contains the fully qualified name
of the identifier object for which information is requested.
Example <info> command:
C:<?xml version="1.0" encoding="utf-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi=
C:"http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation
C:="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
C: <command>
C: <info>
C: <identifier:info xmlns:identifier="urn:ietf:params:xml:
C: ns:identifier-1.0" xsi:schemaLocation="urn:ietf:params:xml
C: :ns:identifier-1.0 identifier-1.0.xsd">
C: <identifier:name>88.1000.1</identifier:name>
C: </identifier:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an <info> command has been processed successfully, the EPP
<resData> element MUST contain a child <identifier:infData> element
that identifies the identifier namespace. The <identifier:infData>
element contains the following child elements:
o An <identifier:name> element that contains the fully qualified
name of the identifier object to be created. The identifier name
with a minimum length of 1 byte and a maximum length of 255 bytes
SHOULD be unique and SHOULD NOT be reused.
Chen, et al. Expires February 17,2021 [Page 10]
Internet-Draft EPP Identifier Mapping August 17,2020
o An <identifier:type> element that specifies type of identification
technique of the identifier object. Handle is taken as an example
in this document.
o Zero or more OPTIONAL <identifier:contact> elements that contain
contact information of the enterprise that applies for the
identifier to be queried.
o Zero or more OPTIONAL <identifier:URL> elements that contain the
URL associated with the identifier object to be queried.
o An <identifier:administratorList> element that contains one or more
<identifier:administrator> elements that specify administrator
information of the identifier object. Identifier administrators
are entitled to create identifier or sub-naming authorities under
the handle prefix according to the permission defined by its
<identifier:permissionList> sub-element.
Each <identifier:administrator> element includes the following
child elements:
An <identifier:adminIndex> element that provides the reference to
the authentication key that can be used to authenticate the
administrator.
An <identifier:pubkey> element that contains the authentication
key of the administrator and information of the type of the
technique used to authenticate administrator. The public key is
processed with base64 encoding schemes.
Three types of algorithms are recommended to authenticate the
identifier administrator: Digital Signature Algorithm (DSA)
public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key
cryptography, or the password-based authentication mechanism.
The Digital Signature Algorithm (DSA) is a typical kind of
cryptographic algorithm to generate pairs of keys used in
public-key system: public keys which may be stored in the
server, and private keys which are known only to the client.
The RSA is one of the first public-key cryptosystems and is another
kind of cryptographic algorithm used for secure data transmission.
The password is a word or string of characters used for user
authentication to prove identity of the administrator.
An <identifier:permissionList> element MAY contain zero or more
<identifier:permission> elements that specify information about
the administration authority of the administrator. A set of
administration functions that include adding, deleting, and
modifying identifier or identifier values are supported by the
identifier service. Before fulfilling any administration request,
Chen, et al. Expires February 17,2021 [Page 11]
Internet-Draft EPP Identifier Mapping August 17,2020
the server must authenticate the client as the identifier
administrator that is authorized for the administrative operation.
List of all the permissions see the "Formal Syntax" section of this
document.
o An <identifier:siteList> element that contains one or more
<identifier:siteInfo> elements that provide information to locate
the site to implement provisions and resolution of the identifier.
In this section, the element defines a handle service site by
identifying the server computers that comprise the site along with
their service configurations (e.g., port numbers).
Each <identifier:siteInfo> contains the following child elements:
An <identifier:siteIndex> element that indicates the specific
index of a site.
An <identifier:protocolVersion> element that indicates handle
protocol version used to create the handle identifier.
One or more <identifier:serviceInfo> elements that contain the
following elements:
An <identifier:serverID> element defines the number of servers in
the service site.
One or more <identifier:addr> elements that describe IP address of
the identifier service. Each <identifier:addr> element MAY
contain an "ip" attribute to identify the IP address format.
Attribute value "v4" is used to note IPv4 address format.
Attribute value "v6" is used to note IPv6 address format. If the
"ip" attribute is not specified,"v4" is the default attribute
value.
An <identifier:pubkey> element that contains the server's public
key with a "type" attribute that specifies algorithms used to
generate the public key. Public key in the
<identifier:serviceInfo> can be used to authenticate any service
response from the handle server.
One or more <identifier:serviceInterfaces> elements that have
three child elements: an <identifier:serviceType> element that
indicates whether the service is for query or for administration,
an <identifier:protocol> element that specifies transmission
protocol, where UDP and HTTP could be considered as alternative
protocols, and the <identifier:port> element that represents
service port of specific the service component.
Example <info> response:
Chen, et al. Expires February 17,2021 [Page 12]
Internet-Draft EPP Identifier Mapping August 17,2020
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: <identifier:infData
S: xmlns:identifier="urn:ietf:params:xml:ns:identifier-1.0">
S: <identifier:name>88.1000.1</identifier:name>
S: <identifier:type>handle</identifier:type>
S: <identifier:status s="clientUpdateProhibited"/>
S: <identifier:contact>jd1234</identifier:contact>
S: <identifier:url>www.caict.ac.cn</identifier:url>
S: <identifier:administratorList>
S: <identifier:administrator>
S: <identifier:adminIndex>100</identifier:adminIndex>
S: <identifier:pubkey type="dsa_pub_key">
S: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf
S: wYFTfB05hhLDC1...</identifier:pubkey>
S: <identifier:permissionList>
S: <identifier:permission>add_handle
S: </identifier:permission>
S: <identifier:permission>delete_handle
S: </identifier:permission>
S: <identifier:permission>add_value
S: </identifier:permission>
S: <identifier:permission>modify_admin
S: </identifier:permission>
S: <identifier:permission>remove_admin
S: </identifier:permission>
S: </identifier:permissionList>
S: </identifier:administrator>
S: </identifier:administratorList>
S: <identifier:siteList>
S: <identifier:siteInfo>
S: <identifier:siteIndex>500</identifier:siteIndex>
S: <identifier:protocolVersion>2.10
S: </identifier:protocolVersion>
S: <identifier:serviceInfo>
S: <identifier:serverID>1</identifier:serverID>
S: <identifier:addr ip="v4">192.0.2.2</identifier:addr>
S: <identifier:addr ip="v6">
S: 1080:0:0:0:8:800:200C:417A
S: </identifier:addr>
Chen, et al. Expires February 17,2021 [Page 13]
Internet-Draft EPP Identifier Mapping August 17,2020
S: <identifier:pubkey type="dsa_pub_key">
S: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03QfwY
S: FTfB05hhLDC1...</identifier:pubkey>
S: <identifier:serviceInterfaces>
S: <identifier:serviceType>query
S: </identifier:serviceType>
S: <identifier:protocol>tcp</identifier:protocol>
S: <identifier:port>2641</identifier:port>
S: </identifier:serviceInterfaces>
S: </identifier:serviceInfo>
S: </identifier:siteInfo>
S: </identifier:siteList>
S: </identifier:infData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if an <info> command cannot
be processed for any reason.
3.1.3. EPP <transfer> Query Command
Transfer semantics do not directly apply to identifier objects, so
there is no mapping defined for the EPP <transfer> query command.
3.2. EPP Transform Commands
EPP provides three commands to transform identifier objects:
<create> to create an instance of an identifier object, <delete> to
delete an instance of an identifier object, and <update> to change
information associated with an identifier object. This document
does not define identifier-object mappings for the EPP <renew> and
<transfer> commands.
Transform commands are typically processed and completed in real
time. Server operators MAY receive and process transform commands
but defer completing the requested action if human or third-party
review is required before the requested action can be completed. In
such situations, the server MUST return a 1001 response code to the
client to note that the command has been received and processed but
that the requested action is pending. The server MUST also manage
the status of the object that is the subject of the command to
reflect the initiation and completion of the requested action. Once
the action has been completed; all clients involved in the
transaction MUST be notified using a service message that the action
has been completed and that the status of the object has changed.
Chen, et al. Expires February 17,2021 [Page 14]
Internet-Draft EPP Identifier Mapping August 17,2020
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 a given object. Any attempt to
transform an 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 create an identifier object. In addition to the standard EPP
command elements, the <create> command MUST contain an <identifier:
create> element that identifies the identifier to be created. The
<identifier:create> element contains the following child elements:
o An <identifier:name> element that contains the fully qualified
name of the identifier object to be created. The identifier name
with a minimum length of 1 byte and a maximum length of 255 bytes
SHOULD be unique and SHOULD NOT be reused.
o An <identifier:type> element that specifies type of identification
technique of the identifier object. Handle is taken as an example
in this document.
o Zero or more OPTIONAL <identifier:contact> elements that contain
contact information of the enterprise that applies for the
identifier to be created.
o Zero or more OPTIONAL <identifier:URL> elements that contain the
URL associated with the identifier object to be created.
o An <identifier:administratorList> element that contains one or
more <identifier:administrator> elements that specify
administrator information of the identifier object. Identifier
administrators are entitled to administrate or resolve identifier
or identifier values according to the permission defined by its
<identifier:permissionList> sub-element.
Each <identifier:administrator> element includes the following
child elements:
An <identifier:adminIndex> element that provides the reference to
the authentication key that can be used to authenticate the
administrator.
An <identifier:pubkey> element that contains the authentication
key of the administrator and information of the type of the
technique used to authenticate administrator. The public key is
processed with base64 encoding schemes.
Chen, et al. Expires February 17,2021 [Page 15]
Internet-Draft EPP Identifier Mapping August 17,2020
Three types of algorithms are recommended to authenticate the
identifier administrator: Digital Signature Algorithm (DSA)
public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key
cryptography, or the password-based authentication mechanism.
The Digital Signature Algorithm (DSA) is a typical kind of
cryptographic algorithm to generate pairs of keys used in public-
key system: public keys which may be stored in the server, and
private keys which are known only to the client.
The RSA is one of the first public-key cryptosystems and is
another kind of cryptographic algorithm used for secure data
transmission.
The password is a word or string of characters used for user
authentication to prove identity of the administrator.
An <identifier:permissionList> element MAY contain zero or more
<identifier:permission> elements that specify information about
the administration authority of the administrator. A set of
administration functions that include adding, deleting, and
modifying identifier or identifier values are supported by the
identifier service. Before fulfilling any administration request,
the server must authenticate the client as the identifier
administrator that is authorized for the administrative operation.
List of all the permissions see the "Formal Syntax" section of
this document.
o An <identifier:siteList> element that contains one or more
<identifier:siteInfo> elements that provide information to locate
the site to implement provisions and resolution of the identifier.
In this section, the element defines a handle service site by
identifying the server computers that comprise the site along with
their service configurations (e.g., port numbers).
Each <identifier:siteInfo> contains the following child elements:
An <identifier:siteIndex> element that indicates the specific
index of a site.
An <identifier:protocolVersion> element that indicates handle
protocol version used to create the handle identifier.
One or more <identifier:serviceInfo> elements that contain the
following elements:
An <identifier:serverID> element defines the number of servers in
the service site.
One or more <identifier:addr> elements that describe IP address of
the identifier service. Each <identifier:addr> element MAY
contain an "ip" attribute to identify the IP address format.
Chen, et al. Expires February 17,2021 [Page 16]
Internet-Draft EPP Identifier Mapping August 17,2020
Attribute value "v4" is used to note IPv4 address format.
Attribute value "v6" is used to note IPv6 address format. If the
"ip" attribute is not specified,"v4" is the default attribute
value.
An <identifier:pubkey> element that contains the server's public
key with a "type" attribute that specifies algorithms used to
generate the public key. Public key in the
<identifier:serviceInfo> can be used to authenticate any service
response from the handle server.
One or more <identifier:serviceInterfaces> elements that have
three child elements: an <identifier:serviceType> element that
indicates whether the service is for query or for administration,
an <identifier:protocol> element that specifies transmission
protocol, where UDP and HTTP could be considered as alternative
protocols, and the <identifier:port> element that represents
service port of specific the service component.
Example <create> command:
C:<?xml version="1.0" encoding="utf-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
C: <command>
C: <create>
C: <identifier:create
C: xmlns:identifier="urn:ietf:params:xml:ns:identifier-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:identifier-1.0
C: identifier-1.0.xsd">
C: <identifier:name>88.1000.1</identifier:name>
C: <identifier:type>handle</identifier:type>
C: <identifier:contact>jd1234</identifier:contact>
C: <identifier:url>www.caict.ac.cn</identifier:url>
C: <identifier:administratorList>
C: <identifier:administrator>
C: <identifier:adminIndex>100</identifier:adminIndex>
C: <identifier:pubkey type="dsa_pub_key">
C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4
C: e175lVnv03QfwYFTfB05hhLDC1...</identifier:pubkey>
C: <identifier:permissionList>
C: <identifier:permission>add_handle
C: </identifier:permission>
C: <identifier:permission>delete_handle
C: </identifier:permission>
C: <identifier:permission>add_value
Chen, et al. Expires February 17,2021 [Page 17]
Internet-Draft EPP Identifier Mapping August 17,2020
C: </identifier:permission>
C: <identifier:permission>modify_admin
C: </identifier:permission>
C: <identifier:permission>remove_admin
C: </identifier:permission>
C: </identifier:permissionList>
C: </identifier:administrator>
C: </identifier:administratorList>
C: <identifier:siteList>
C: <identifier:siteInfo>
C: <identifier:siteIndex>500</identifier:siteIndex>
C: <identifier:protocolVersion>2.10
C: </identifier:protocolVersion>
C: <identifier:serviceInfo>
C: <identifier:serverID>1</identifier:serverID>
C: <identifier:addr ip="v4">192.0.2.2</identifier:addr>
C: <identifier:addr ip="v6">1080:0:0:0:8:800:200C:417A
C: </identifier:addr>
C: <identifier:pubkey type="dsa_pub_key">
C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e
C: 175lVnv03QfwYFTfB05hhLDC1...</identifier:pubkey>
C: <identifier:serviceInterfaces>
C: <identifier:serviceType>query
C: </identifier:serviceType>
C: <identifier:protocol>tcp</identifier:protocol>
C: <identifier:port>2641</identifier:port>
C: </identifier:serviceInterfaces>
C: </identifier:serviceInfo>
C: </identifier:siteInfo>
C: </identifier:siteList>
C: </identifier:create>
C: </create>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <create> command has been processed successfully, the EPP
<response> element MUST contain a child <result code> element that
identifies the result of processing.
Example <create> response:
S:<?xml version="1.0" encoding="utf-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
Chen, et al. Expires February 17,2021 [Page 18]
Internet-Draft EPP Identifier Mapping August 17,2020
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <create> command cannot
be processed for any reason.
3.2.2. EPP <delete> Command
The EPP <delete> command provides an operation that allows a client
to delete an identifier object. In addition to the standard EPP
command elements, the <delete> command MUST contain an
<identifier:delete> element that specifies the identifier namespace.
The<identifier:delete> element contains the following child element:
o An <identifier:name> element that contains the fully qualified
name of the identifier object to be deleted.
Example <delete> command:
C:<?xml version="1.0" encoding="utf-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi=
C:"http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=
C:"urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
C: <command>
C: <delete>
C: <identifier:delete xmlns:identifier="urn:ietf:params:
C: xml:ns:identifier-1.0" xsi:schemaLocation="urn:ietf:
C: params:xml:ns:identifier-1.0 identifier-1.0.xsd">
C: <identifier:name>88.1000.1</identifier:name>
C: </identifier:delete>
C: </delete>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <delete> command has been processed successfully, a server
MUST respond with an EPP response with no <resData> element.
Chen, et al. Expires February 17,2021 [Page 19]
Internet-Draft EPP Identifier Mapping August 17,2020
Example <delete> response
<?xml version="1.0" encoding="utf-8"?>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
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>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <delete> command cannot
be processed for any reason.
3.2.3. EPP <renew> Command
Renewal semantics do not apply to identifier objects, so there is no
identifier mapping defined for the EPP <renew> command.
3.2.4. EPP <transfer> Command
Transfer semantics do not directly apply to identifier 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 identifier. In addition to the
standard EPP command elements, the <update> command MUST contain an
<identifier:update> element that identifies the identifier object
and attributes to be updated. The <identifier:update> element
contains the following child elements:
o An <identifier:name> element that contains the fully qualified
name of the identifier object to be updated.
o An OPTIONAL <identifier:add> element that contains attribute
values to be added to the identifier object.
o An OPTIONAL <identifier:rem> element that contains attribute
values to be removed from the object. It has the following child
elements: An OPTIONAL <identifier:contact> element that contains
contact information that is to be removed from the identifier.
Chen, et al. Expires February 17,2021 [Page 20]
Internet-Draft EPP Identifier Mapping August 17,2020
An optional <identifier:url> element that contains the URL to be
removed. An OPTIONAL <identifier:adminIndex> element that
specifies the index of the identifier administrator to be deleted.
An OPTIONAL <identifier:siteIndex> element that contains
information about index of the site to be removed from the
identifier object. At least one child element of MUST be provided
if the <identifier:rem> element is present.
o An OPTIONAL <identifier:chg> element that contains object
attribute values to be changed. The name of an identifier MUST NOT
be changed, due to impacts on associated identifier objects.
At least one <identifier:add>, <identifier:rem>, or <identifier:chg>
element MUST be provided if the command is not being extended. All
of these elements MAY be omitted if an <update> extension is
present. The <identifier:add> and <identifier:chg> elements share
two common child elements: <identifier:administrator> and the
<identifier:siteInfo> element.
The <identifier:add> element has two additional child elements:
<identifier:contact> and <identifier:url> other than the common
element.
Whereas the <identifier:chg> has an additional <identifier:status>
element that specifies status of the identifier object. Description
of the common child elements of <identifier:add> and
<identifier:chg> goes as follows:
- An <identifier:administrator> element that specifies
administrator information of the identifier object. Identifier
administrators are entitled to administrate or resolve
identifier or identifier values according to the permission
defined by its <identifier:permissionList> sub-element. An
<identifier:administrator> element includes the following
child elements:
An <identifier:adminIndex> element that provides the reference
to the authentication key that can be used to authenticate the
administrator.
An <identifier:pubkey> element that contains the authentication
key of the administrator and information of the type of the
technique used to authenticate administrator. The public key is
processed with base64 encoding schemes.
Three types of algorithms are recommended to authenticate the
identifier administrator: Digital Signature Algorithm (DSA)
public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key
cryptography, or the password-based authentication mechanism.
An <identifier:permissionList> element MAY contain zero or more
<identifier:permission> elements that specify information about
Chen, et al. Expires February 17,2021 [Page 21]
Internet-Draft EPP Identifier Mapping August 17,2020
the administration authority of the administrator. A set of
administration functions that include adding, deleting, and
modifying identifier or identifier values are supported by the
identifier service. Before fulfilling any administration
request, the server must authenticate the client as the
identifier administrator that is authorized for the
administrative operation.
Lists of all the permissions see the "Formal Syntax" section of
this document.
- An <identifier:siteInfo> element that provides information to
locate the site to implement provisions and resolution of the
identifier.The <identifier:siteInfo> element defines a handle
service site by identifying the server computers that comprise
the site along with their service configurations (e.g., port
numbers).It contains the following child elements:
An <identifier:siteIndex> element that indicates the specific
index of a site that is added or modified.
An <identifier:protocolVersion> element that indicates handle
protocol version used to create the handle identifier.
One or more <identifier:serviceInfo> elements that contain the
following elements: An <identifier:serverID> element defines the
number of servers in the service site. One or more
<identifier:addr> elements that describe IP address of the
identifier service. Each <identifier:addr> element MAY contain
an "ip" attribute to identify the IP address format. Attribute
value "v4" is used to note IPv4 address format. Attribute value
"v6" is used to note IPv6 address format. If the "ip" attribute
is not specified,"v4" is the default attribute value. An
<identifier:pubkey> element that contains the server's public key
with a "type" attribute that specifies algorithms used to
generate the public key. Public key in the
<identifier:serviceInfo> can be used to authenticate any service
response from the handle server. One or more
<identifier:serviceInterfaces> elements that have three child
elements: an <identifier:serviceType> element that indicates
whether the service is for query or for administration, an
<identifier:protocol> element that specifies transmission
protocol, where UDP and HTTP could be considered as alternative
protocols, and the <identifier:port> element that represents
service port of specific the service component.
Example <update> command:
C:<?xml version="1.0" encoding="utf-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Chen, et al. Expires February 17,2021 [Page 22]
Internet-Draft EPP Identifier Mapping August 17,2020
C:xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
C: <command>
C: <update>
C: <identifier:update
C: xmlns:identifier="urn:ietf:params:xml:ns:identifier-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:identifier-1.0
C: identifier-1.0.xsd">
C: <identifier:name>88.1000.1</identifier:name>
C: <identifier:add>
C: <identifier:contact>jd12345</identifier:contact>
C: <identifier:url>www.abc.com</identifier:url>
C: <identifier:administrator>
C: <identifier:adminIndex>101</identifier:adminIndex>
C: <identifier:pubkey type="dsa_pub_key">
C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf
C: wYFTfB05hhLDC1...</identifier:pubkey>
C: <identifier:permissionList>
C: <identifier:permission>add_handle
C: </identifier:permission>
C: <identifier:permission>delete_handle
C: </identifier:permission>
C: <identifier:permission>add_value
C: </identifier:permission>
C: <identifier:permission>modify_admin
C: </identifier:permission>
C: <identifier:permission>remove_admin
C: </identifier:permission>
C: </identifier:permissionList>
C: </identifier:administrator>
C: <identifier:siteInfo>
C: <identifier:siteIndex>501</identifier:siteIndex>
C: <identifier:protocolVersion>2.10
C: </identifier:protocolVersion>
C: <identifier:serviceInfo>
C: <identifier:serverID>1</identifier:serverID>
C: <identifier:addr ip="v4">192.0.2.2</identifier:addr>
C: <identifier:addr ip="v6">1080:0:0:0:8:800:200C:417A
C: </identifier:addr>
C: <identifier:pubkey type="dsa_pub_key">
C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e
C: 175lVnv03QfwYFTfB05hhLDC1...</identifier:pubkey>
C: <identifier:serviceInterfaces>
C: <identifier:serviceType>admin
C: </identifier:serviceType>
C: <identifier:protocol>tcp</identifier:protocol>
Chen, et al. Expires February 17,2021 [Page 23]
Internet-Draft EPP Identifier Mapping August 17,2020
C: <identifier:port>2641</identifier:port>
C: </identifier:serviceInterfaces>
C: </identifier:serviceInfo>
C: </identifier:siteInfo>
C: </identifier:add>
C: <identifier:rem>
C: <identifier:contact>jd12345</identifier:contact>
C: <identifier:url>www.abc.com</identifier:url>
C: <identifier:adminIndex>101</identifier:adminIndex>
C: <identifier:siteIndex>500</identifier:siteIndex>
C: </identifier:rem>
C: <identifier:chg>
C: <identifier:status s="clientUpdateProhibited"/>
C: <identifier:administrator>
C: <identifier:adminIndex>102</identifier:adminIndex>
C: <identifier:pubkey type="dsa_pub_key">
C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf
C: wYFTfB05hhLDC1...</identifier:pubkey>
C: <identifier:permissionList>
C: <identifier:permission>add_handle
C: </identifier:permission>
C: <identifier:permission>delete_handle
C: </identifier:permission>
C: <identifier:permission>add_value
C: </identifier:permission>
C: </identifier:permissionList>
C: </identifier:administrator>
C: <identifier:siteInfo>
C: <identifier:siteIndex>500</identifier:siteIndex>
C: <identifier:protocolVersion>2.10
C: </identifier:protocolVersion>
C: <identifier:serviceInfo>
C: <identifier:serverID>2</identifier:serverID>
C: <identifier:addr ip="v4">192.0.2.2</identifier:addr>
C: <identifier:addr ip="v6">1080:0:0:0:8:800:200C:417A
C: </identifier:addr>
C: <identifier:serviceInterfaces>
C: <identifier:serviceType>query
C: </identifier:serviceType>
C: <identifier:protocol>tcp</identifier:protocol>
C: <identifier:port>2641</identifier:port>
C: </identifier:serviceInterfaces>
C: </identifier:serviceInfo>
C: </identifier:siteInfo>
C: </identifier:chg>
Chen, et al. Expires February 17,2021 [Page 24]
Internet-Draft EPP Identifier Mapping August 17,2020
C: </identifier:update>
C: </update>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an <update> command has been processed successfully, a server
MUST respond with an EPP response with no <resData> element.
Example <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>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if an <update> command could
not be processed for any reason.
4. Formal Syntax
An EPP object mapping is specified in XML Schema notation. The
formal syntax presented here is a complete schema representation of
the object mapping suitable for automated validation of EPP XML
instances. The BEGIN and END tags are not part of the schema; they
are used to note the beginning and ending of the schema for URI
registration purposes.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
Chen, et al. Expires February 17,2021 [Page 25]
Internet-Draft EPP Identifier Mapping August 17,2020
o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL,SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
BEGIN
<?xml version="1.0" encoding="utf-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:identifier="urn:ietf:params:xml:ns:identifier-1.0"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
targetNamespace="urn:ietf:params:xml:ns:identifier-1.0"
elementFormDefault="qualified">
<!--
Import common element types.
-->
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:epp-1.0"
schemaLocation="epp-1.0.xsd"/>
<annotation>
<documentation>Extensible Provisioning Protocol v1.0
identifier provisioning schema.</documentation>
</annotation>
<!--
Child elements found in EPP commands.
-->
<element name="check" type="identifier:mNameType"/>
<element name="create" type="identifier:createType"/>
<element name="update" type="identifier:updateType"/>
<element name="info" type="identifier:sNameType"/>
<element name="delete" type="identifier:sNameType"/>
<!--
Chen, et al. Expires February 17,2021 [Page 26]
Internet-Draft EPP Identifier Mapping August 17,2020
Child elements of the <create> command.
-->
<complexType name="createType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="type" type="identifier:typeEnumType"/>
<element name="contact" type="identifier:contactType"
maxOccurs="unbounded"/>
<element name="url" type="anyURI" maxOccurs="unbounded"/>
<element name="administratorList"
type="identifier:administratorListType" minOccurs="0"/>
<element name="siteList"
type="identifier:siteListType" minOccurs="0"/>
</sequence>
</complexType>
<!--
Child elements of the <delete> and <info> commands.
-->
<complexType name="sNameType">
<sequence>
<element name="name" type="eppcom:labelType"/>
</sequence>
</complexType>
<!--
Child element of commands that accept multiple names.
-->
<complexType name="mNameType">
<sequence>
<element name="name" type="eppcom:labelType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<simpleType name="typeEnumType">
<restriction base="token">
<enumeration value="handle"/>
<enumeration value="oid"/>
<enumeration value="ecode"/>
<enumeration value="epc"/>
<enumeration value="other"/>
</restriction>
</simpleType>
<complexType name="contactType">
<simpleContent>
<extension base="eppcom:clIDType">
<attribute name="type" type="identifier:contactAttrType"/>
Chen, et al. Expires February 17,2021 [Page 27]
Internet-Draft EPP Identifier Mapping August 17,2020
</extension>
</simpleContent>
</complexType>
<simpleType name="contactAttrType">
<restriction base="token">
<enumeration value="admin"/>
<enumeration value="billing"/>
<enumeration value="tech"/>
</restriction>
</simpleType>
<complexType name="administratorListType">
<sequence>
<element name="administrator"
type="identifier:administratorType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="administratorType">
<sequence>
<element name="adminIndex" type="unsignedInt"/>
<element name="pubkey" type="identifier:pubkeyType"/>
<element name="permissionList" type="identifier:
permissionListType"/>
</sequence>
</complexType>
<complexType name="pubkeyType">
<simpleContent>
<extension base="base64Binary">
<attribute name="type" type="identifier:
pubkeyTypeType"/>
</extension>
</simpleContent>
</complexType>
<simpleType name="pubkeyTypeType">
<restriction base="token">
<enumeration value="dsa_pub_key"/>
<enumeration value="rsa_pub_key"/>
<enumeration value="secret_key"/>
</restriction>
</simpleType>
<complexType name="permissionListType">
<sequence>
<element name="permission" type="identifier:permissionType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
Chen, et al. Expires February 17,2021 [Page 28]
Internet-Draft EPP Identifier Mapping August 17,2020
</complexType>
<simpleType name="permissionType">
<restriction base="token">
<enumeration value="add_handle"/>
<enumeration value="delete_handle"/>
<enumeration value="add_na"/>
<enumeration value="delete_na"/>
<enumeration value="modify_value"/>
<enumeration value="delete_value"/>
<enumeration value="add_value"/>
<enumeration value="modify_admin"/>
<enumeration value="remove_admin"/>
<enumeration value="add_admin"/>
<enumeration value="authorized_read"/>
<enumeration value="list_handle"/>
</restriction>
</simpleType>
<complexType name="siteListType">
<sequence>
<element name="siteInfo" type="identifier:siteInfoType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="siteInfoType">
<sequence>
<element name="siteIndex" type="unsignedInt"/>
<element name="protocolVersion" type="token"/>
<element name="serviceInfo" type="identifier:serviceInfoType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="serviceInfoType">
<sequence>
<element name="serverID" type="unsignedInt"/>
<element name="addr" type="identifier:addrType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="pubkey" type="identifier:pubkeyType"
minOccurs="0" maxOccurs="1"/>
<element name="serviceInterfaces"
type="identifier:serviceInterfacesType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="addrType">
<simpleContent>
Chen, et al. Expires February 17,2021 [Page 29]
Internet-Draft EPP Identifier Mapping August 17,2020
<extension base="identifier:addrStringType">
<attribute name="ip" type="identifier:ipType" default="v4"/>
</extension>
</simpleContent>
</complexType>
<simpleType name="addrStringType">
<restriction base="token">
<minLength value="3"/>
<maxLength value="45"/>
</restriction>
</simpleType>
<simpleType name="ipType">
<restriction base="token">
<enumeration value="v4"/>
<enumeration value="v6"/>
</restriction>
</simpleType>
<complexType name="serviceInterfacesType">
<sequence>
<element name="serviceType"
type="identifier:serviceTypeType"/>
<element name="protocol" type="identifier:protocolType"/>
<element name="port" type="unsignedShort"/>
</sequence>
</complexType>
<simpleType name="serviceTypeType">
<restriction base="token">
<enumeration value="query"/>
<enumeration value="admin"/>
</restriction>
</simpleType>
<simpleType name="protocolType">
<restriction base="token">
<enumeration value="tcp"/>
<enumeration value="udp"/>
<enumeration value="http"/>
</restriction>
</simpleType>
<!--
Child elements of the <update> command.
-->
<complexType name="updateType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="add" type="identifier:addType" minOccurs="0"/>
Chen, et al. Expires February 17,2021 [Page 30]
Internet-Draft EPP Identifier Mapping August 17,2020
<element name="rem" type="identifier:remType" minOccurs="0"/>
<element name="chg" type="identifier:chgType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="addType">
<sequence>
<element name="contact" type="identifier:contactType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="url" type="eppcom:labelType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="administrator"
type="identifier:administratorType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="siteInfo" type="identifier:siteInfoType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="cert" type="token" minOccurs="0"
maxOccurs="1"/>
<element name="signature" type="token" minOccurs="0"
maxOccurs="1"/>
</sequence>
</complexType>
<complexType name="remType">
<sequence>
<element name="contact" type="identifier:contactType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="url" type="eppcom:labelType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="adminIndex" type="unsignedInt" minOccurs="0"
maxOccurs="unbounded"/>
<element name="siteIndex" type="unsignedInt" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="chgType">
<sequence>
<element name="status" type="identifier:statusType"
minOccurs="0"/>
<element name="administrator"
type="identifier:administratorType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="siteInfo" type="identifier:siteInfoType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="cert" type="token" minOccurs="0"
maxOccurs="1"/>
<element name="signature" type="token" minOccurs="0"
Chen, et al. Expires February 17,2021 [Page 31]
Internet-Draft EPP Identifier Mapping August 17,2020
maxOccurs="1"/>
</sequence>
</complexType>
<!--
Status is a combination of attributes and an optional
human-readable message that may be expressed in languages other
than English.
-->
<complexType name="statusType">
<simpleContent>
<extension base="normalizedString">
<attribute name="s" type="identifier:statusValueType"
use="required"/>
<attribute name="lang" type="language" default="en"/>
</extension>
</simpleContent>
</complexType>
<simpleType name="statusValueType">
<restriction base="token">
<enumeration value="clientDeleteProhibited"/>
<enumeration value="clientHold"/>
<enumeration value="clientRenewProhibited"/>
<enumeration value="clientTransferProhibited"/>
<enumeration value="clientUpdateProhibited"/>
<enumeration value="inactive"/>
<enumeration value="ok"/>
<enumeration value="pendingCreate"/>
<enumeration value="pendingDelete"/>
<enumeration value="pendingRenew"/>
<enumeration value="pendingTransfer"/>
<enumeration value="pendingUpdate"/>
<enumeration value="serverDeleteProhibited"/>
<enumeration value="serverHold"/>
<enumeration value="serverRenewProhibited"/>
<enumeration value="serverTransferProhibited"/>
<enumeration value="serverUpdateProhibited"/>
</restriction>
</simpleType>
<!--
Child response elements.
-->
<element name="chkData" type="identifier:chkDataType"/>
<element name="infData" type="identifier:infDataType"/>
<!--
<check> response elements.
Chen, et al. Expires February 17,2021 [Page 32]
Internet-Draft EPP Identifier Mapping August 17,2020
-->
<complexType name="chkDataType">
<sequence>
<element name="cd" type="identifier:checkType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="checkType">
<sequence>
<element name="name" type="identifier:checkNameType"/>
<element name="reason" type="eppcom:reasonType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="checkNameType">
<simpleContent>
<extension base="eppcom:labelType">
<attribute name="avail" type="boolean" use="required"/>
</extension>
</simpleContent>
</complexType>
<complexType name="infDataType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="type" type="identifier:typeEnumType"/>
<element name="status" type="identifier:statusType"/>
<element name="contact" type="identifier:contactType"
maxOccurs="unbounded"/>
<element name="url" type="anyURI" maxOccurs="unbounded"/>
<element name="administratorList"
type="identifier:administratorListType" minOccurs="0"/>
<element name="siteList" type="identifier:siteListType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
End of schema.
-->
</schema>
END
5. 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
Chen, et al. Expires February 17,2021 [Page 33]
Internet-Draft EPP Identifier Mapping August 17,2020
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 identifiers 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 identifiers 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 identifier techniques.
6. Security Considerations
Authorization information as described in Section 3.2 is REQUIRED to
create an identifier object. 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.
7. 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 identifier namespace:
URI: urn:ietf:params:xml:ns:identifier-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 identifier XML schema:
Chen, et al. Expires February 17,2021 [Page 34]
Internet-Draft EPP Identifier Mapping August 17,2020
URI: urn:ietf:params:xml:schema:identifier-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: See the "Formal Syntax" section of this document.
8. Acknowledgments
This document is based on an identifier application of EPP.Thus, the
authors 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.
9. References
9.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>.
[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.
Chen, et al. Expires February 17,2021 [Page 35]
Internet-Draft EPP Identifier Mapping August 17,2020
9.2. Informative References
[RFC1558] T. Howes, "A String Representation of LDAP Search Filters",
RFC 1558, December 1993.
[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.
Chen, et al. Expires February 17,2021 [Page 36]
Internet-Draft EPP Identifier Mapping August 17,2020
Author's Address
Yuying Chen
CAICT
No.52 Huayuan North Road, Haidian District
Beijing, Beijing, 100191
China
Phone: +86 188 1008 2358
Email: chenyuying@caict.ac.cn
Jiagui Xie
CAICT
No.52 Huayuan North Road, Haidian District
Beijing, Beijing, 100191
China
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
Zhipeng Fan
CAICT
No.52 Huayuan North Road, Haidian District
Beijing, Beijing, 100191
China
Phone: +86 159 1112 3285
Email: fanzhipeng@caict.ac.cn
Chen, et al. Expires February 17,2021 [Page 37]
