Back

25 Extensible Provisioning Protocol (EPP)

gTLDFull Legal NameE-mail suffixDetail
.durbanUniForum SA (NPC) trading as ZA Central Registrydundas.co.zaView
THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE FULL ANSWER TO THIS QUESTION IS ATTACHED AS PDF FILES dotDurban-q25.pdf and dotDurban-q25-rfc.pdf, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.

1 Synopsis

This chapter provides details on the ZA Central Registry Shared Registry
System Extensible Provisioning Protocol EPP functionality as will be used
by the dotDurban TLD.


2 Overview

The functionality of the ZA Central Registry Shared Registry System allows
registrars to interface using the EPP protocol and commands as defined in
the following RFCs and as referenced in this document:

RFC 3735:- Guidelines for Extending the EPP.

RFC 5730:- EPP Description.

RFC 5731:- EPP Domain Name Mapping.

RFC 5732:- EPP Host Mapping.

RFC 5733:- EPP Contact Mapping.

RFC 5734:- EPP TCP Transport.

RFC 5910:- EPP DNSSEC.

The ZA Central Registry Shared Registry System also conforms to the
above-mentioned RFCs.
The ZA Central Registry does not provide support for Domain Registry
Grace Period Mapping as per RFC 3915.
The ZA Central Registry will not be supporting International Domain Names
at startup.


3 Registrar Interface

The dotDurban implementation listens for incoming TCP connection re-
quests. Once a client has issued an EPP 〈login〉 command on the listening
port, the server responds, creating the required session and sending back an
EPP 〈greeting〉 to the client.
To end a session, a client may close the connection by issuing EPP 〈logout〉
command or an active close call.

The dotDurban implementation automatically closes a session once the ses-
sion has idled for 24 hours.
A total of 2 concurrent sessions per client are allowed.
A Registrar can only establish a TCP connection to the server if they have
been technically accredited, provided the ZA Central Registry with their
public key and the public key has been successfully installed.
Exchanging of messages between client and server conforms to the require-
ments outlined in RFC 5734, and follows the general client-server message
exchange as outlined in Figure 1 of RFC 5734 Section 3.
Pipelining commands is possible. The server supports command pipelining
to a maximum limit of the connection buffer of 16384 bytes.
The dotDurban implementation returns a message from the server to the
client for every command performed. If a message is lost due to connection
failure, the result code can only be retrieved if the client issues the same
command using the same client transaction identifier 〈clTRID〉 .
The dotDurban implementation uses SSL⁄TLS as well as IP based Access
Control Lists. A session is started on login only if an SSL handshake is
established and the client IP Address is listed on the Access Control List.
Further security measures include authentication through use of usernames
and passwords. A session is terminated upon logout. A session is valid for
24 hours.
The dotDurban handling and interpretation of the EPP Data Units con-
forms to RFC 5734 Section 4, whereby the format of any EPP data unit
will contain the 32-bit header describing the total length of the data unit,
and the EPP XML Instance.
Length and calculation of data units conform with requirements outlined in
RFC 5734 .
Changes in the implementation can be made and will have to be decided by
the dotDurban Policy Oversight Committee .


4 Extensible Provisioning Protocol (EPP)

This section describes the capability of the ZA Central Registry Shared
Registry System EPP and compliance with RFC 5730


4.1 Protocol Description

EPP is an XML based protocol used for provisioning domains and their asso-
ciated objects. The dotDurban EPP implementation supports all commands

as defined in RFC 5730.


4.2 Protocol Commands

A command is any action performed on an object. Commands are grouped
into session, query and object transformation commands as follows in the
list below:

Protocol:-
* login
* logout
Query:-
* Check
* Info
* Poll
* Transfer
Transform:-
* Create
* Delete
* Renew
* Transfer
* Update


4.3 EPP 〈login〉 Protocol Command

The dotDurban implementation of the EPP 〈login〉 command conforms to
the requirements outlined in RFC 5730 Section 2.9.1.1.


4.4 EPP 〈logout〉 Protocol Command

The dotDurban implementation of the EPP 〈logout〉 command conforms
to the requirements outlined in RFC 5730 Section 2.9.1.2 .


4.5 EPP 〈poll〉 Protocol Command

The dotDurban implementation of the EPP 〈poll〉 command conforms to
the requirements outlined in RFC 5730 Section 2.9.2.3 .

4.6 Command Response

For each EPP command that is issued by the client to the server, a corre-
sponding response will be returned to the client by the server.
Every response will contain a result code. The result code indicates com-
mand success or failure. The dotDurban implementation conforms to the
theory of result codes outlined in RFC 5321 Section 4.2.1 and uses a fourth
digit in its response codes.


5 EPP Domain Name Mapping

5.1 Overview

The following section provides details on how the ZA Central Registry
Shared Registry System maps its domain functionality. Any changes to
the EPP Domain Name Mapping command set will be determined by the
dotDurban Policy Oversight Committee .


5.2 Relationship of Domain Objects and Host Objects

All created domain name objects require a minimum of 2 unique subordinate
or delegated host objects.


5.3 Object Attributes

Domain and Host Names:- Only domain names conforming to standard
ASCII will be used. Internationalized Domain Names (IDN)s must be
provided in A-Label format.

Contact and Client Identifiers:- Client and contact identifiers will be
represented through a clID element to create an association with a
domain object.

Status Values:- The dotDurban implementation supports server and client
status interaction outlined in RFC 5731.

Dates and Times:- All dates and times conform to RFC 5731 and are
represented using UTC.

Validity Periods:- The dotDurban implementation supports validity pe-
riods in months and years, as well as a combination of both.

Authorisation Information:- The dotDurban implementation supports
domain name object authorisation through use of passwords as defined
in RFC 5731. Passwords are stored in one-way hash format.


5.4 EPP 〈check〉 Command

The dotDurban implementation of the EPP 〈check〉 command conforms to
the requirements outlined in RFC 5731 . The Domain 〈check〉 command
will be limited to 100 checks per command.


5.5 EPP 〈info〉 Command

The dotDurban implementation of the EPP 〈info〉 command conforms to
the requirements outlined in RFC 5731 Section 3.1.2. The 〈info〉 command
response will be restricted based on the requester credentials. Expiry dates
and other information will not be presented to unauthorized sources.


5.6 EPP 〈transfer〉 Command

The dotDurban implementation of the EPP 〈transfer〉 command conforms
to the requirements outlined in RFC 5731.
The dotDurban implementation supports the following EPP 〈transfer〉
operations which conform to RFC 5730 :

ʺqueryʺ:- Allows a client to identify the current status of a transfer request
on a domain name object.

ʺrequestʺ:- Allows a client to request a transfer of a domain object from
one sponsor to another.

ʺcancelʺ:- Allows a client to cancel their transfer request for a domain as
long as the domain has not yet been transferred.

ʺapproveʺ:- Allows the current domain sponsor to approve a transfer re-
quest for the requested domain.

ʺrejectʺ:- Allows the current domain sponsor the reject a transfer request
for the requested domain.

The dotDurban implementation incorporates an e-mail voting system whereby
a registrant is allowed to vote on the transfer of a domain. An EPP Poll
message will be queued for the current sponsor for transfer vote notification.

5.7 EPP 〈create〉 Command

The dotDurban implementation of the EPP 〈create〉 command restricts
the use of the 〈period〉 element where the registry defines the registration
period of a domain object.


5.8 EPP 〈delete〉 Command

The dotDurban implementation of the EPP 〈delete〉 command conforms
to the requirements outlined in RFC 5731 Section 3.2.2 . The dotDurban
implementation denotes that any domain that undergoes a 〈delete〉 com-
mand is checked to conform to subordinate host dependencies outlined in
RFC 5731 . A deletion request on a domain object will be prohibited if the
subordinate host objects are referenced by other domains belonging to the
same registrar.


5.9 EPP 〈renew〉 Command

The dotDurban implementation of the EPP 〈renew〉 command restricts
the use of the 〈domain:period〉 element. The domain object can only be
renewed to a maximum of one period.


5.10 EPP 〈update〉 Command

The dotDurban implementation of the EPP 〈update〉 command conforms to
the requirements outlined in RFC 5731 . The dotDurban implementation
utilises the 〈domain:contact〉 element to set ʺtechʺ, ʺbillingʺ, ʺadminʺ
contacts to domain name objects.


6 EPP Host Mapping

The following section provides details on how the ZA Central Registry
Shared Registry System maps its host functionality. The dotDurban imple-
mentation restricts the host creation and usage to the individual registrar.
In other words each registrar controls and maintains their own set of hosts
even if the names are duplicated with other registrars. Subordinate host
glue publication is strictly controlled to prevent nameserver masquerading.

6.1 Relationship of Domain Objects and Host Objects

All created domain name objects require a minimum of 2 unique subordinate
or delegated host objects.


6.2 Object Attributes

Host Names:- Only host names conforming to standard ASCII will be
used.

Status Values:- The dotDurban implementation supports server and client
status interaction outlined in RFC 5732.

Dates and Times:- All dates and times conform to RFC 5732 and are
represented using UTC.

Glue:- The dotDurban implementation supports IPv4 and IPv6 addresses,
conforming to the requirements outlined in RFC 0791 and RFC 4291
respectively.


6.3 EPP 〈check〉 Command

The dotDurban implementation of the EPP 〈check〉 command conforms to
the requirements outlined in RFC 5732 .


6.4 EPP 〈info〉 Command

The dotDurban implementation of the EPP 〈info〉 command conforms to
the requirements outlined in RFC 5732 .


6.5 EPP 〈create〉 Command

The dotDurban implementation of the EPP 〈create〉 command conforms
to the requirements outlined in RFC 5732. The use of the Host create
command might be restricted in lieu of the Domain Host handling during
Domain update and creation. The eventual Host create usage will be deter-
mined by the dotDurban Policy Oversight Committee .


6.6 EPP 〈delete〉 Command

The dotDurban Implementation of the EPP 〈delete〉 command conforms
to the requirements outlined in RFC 5732.

The dotDurban implementation denotes that any host that undergoes a
〈delete〉 command is checked for dependencies outlined in RFC 5731 .


6.7 EPP 〈update〉 Command

The dotDurban implementation of the EPP 〈update〉 command conforms
to the requirements outlined in RFC 5732.
The dotDurbanimplementation dictates that the changing of a host object
information is performed through the domain object mapping using the
domain 〈update〉 command.


7 EPP Contact Mapping

7.1 Overview

The following section provides details on how the ZA Central Registry
Shared Registry System maps its contact functionality.
Any changes to the EPP Contact Mapping command set will be determined
by the dotDurban Policy Oversight Committee . In the dotDurban imple-
mentation the Registrar objects are stored as standard EPP Contact objects,
thus allowing a registrar to adjust contact information such as passwords or
support addresses.


7.2 Object Attributes

Contact and Client Identifiers:- Client and contact identifiers will be
represented through a clID element to create an association with a
domain object.

Status Values:- The dotDurban implementation supports server and client
statuses outlined in RFC 5733. Status combination interactions con-
form to RFC 5733 .

Internationalized Postal Info:- The dotDurban implementation supports
postal information represented as a subset of UTF-8 encoding in 7-bit
ASCII. All required and optional elements for a contact object are
supported by the dotDurban implementation.

Localized Postal Info:- The dotDurban implementation also supports postal
information represented in UTF-8 encoding. All required and optional
elements for a contact object are supported by the dotDurban imple-
mentation.

Telephone Numbers:- The dotDurban implementation conforms to RFC 5733
by ensuring that all telephone numbers begin with a plus (ʺ+ʺ) sign
followed by a country code as defined in ITU.E164.2005, followed by a
dot (ʺ.ʺ), followed by a sequence of digits representing the telephone
number.

E-mail Addresses:- The dotDurban implementation conforms to the re-
quirements for e-mail addresses as defined in RFC 5322.

Dates and Times:- All dates and times conform to RFC 5733. The dot-
Durban implementation supports time zone representation in UTC
format.

Authorisation Information:- The dotDurban implementation supports
contact object authorisation through use of passwords, conforming to
outlined requirements in RFC 5733. Passwords are stored in one-way
hash format.

Disclosure of Contact Elements and Attributes:- The dotDurban im-
plementation supports disclosure of contact attributes and conforms
to RFC 5730, by announcing its data collection policies. The dot-
Durban implementation supports the disclosure elements outlined in
RFC 5733.


7.3 EPP 〈check〉 Command

The dotDurban implementation of the EPP 〈check〉 command conforms to
the requirements outlined in RFC 5733 .


7.4 EPP 〈info〉 Command

The dotDurban implementation of the EPP 〈info〉 command conforms to
the requirements outlined in RFC 5733. The disclosure of Contact informa-
tion will obey the disclose options as provided for the Contact object.


7.5 EPP 〈transfer〉 Command

The dotDurban implementation of the EPP 〈transfer〉 query command
conforms to the requirements outlined in RFC 5733.

7.6 EPP 〈create〉 Command

The dotDurban implementation of the EPP 〈create〉 command conforms
to the requirements outlined in RFC 5733 .
The dotDurban implementation supports the creation of a contact object
with both 〈contact:postalInfo〉 types of ʺlocʺ and ʺintʺ, conforming to
the requirements outlined in RFC 5733 Section 3.2.1 .


7.7 EPP 〈delete〉 Command

Implementation of the EPP 〈delete〉 command conforms to the require-
ments outlined in RFC 5733 Section 3.2.2.


Current policy states that a contact object cannot be deleted if in any way
it is associated with another object. If a contact object is still associated
with a domain object, the contact object is not deleted until the association
between contact and domain objects is removed.



7.8 EPP 〈update〉 Command

The dotDurban implementation of the EPP 〈update〉 command conforms
to the requirements outlined in RFC 5733 .
The dotDurban implementation supports the updating of a contact object
with both 〈contact:postalInfo〉 types of ʺlocʺ and ʺintʺ, conforming to
the requirements outlined in RFC 5733 Section 3.2.5 .



8 EPP Technical Plan

The Technical Layout will include the following:

* On-site Scalable Master Server with the following configuration:

Message Server:- The Message Server is responsible for handling
session management, access control, user authentication EPP
schema validation and Poll commands.
Registry Engine:- The Registry Engine is responsible for all object
level query and transform commands.
Database:- The primary Registry Engine database.

* Scalable Standby Co-located Server with the following configuration:

Message Server:- A secondary Message Server used in the event
that the Master Server fails.
Registry Engine:- A secondary registry Engine used in the event
that the Master Server fails.
Standby Database:- A secondary database that is used in the event
that the primary database on the Master Server fails.


* Off-site Remote Standby Server with the following configuration:

The Remote Off-Site Server configuration is a mirror of the
Master site.

From the Technical Layout above, the EPP Technical Plan is as follows:
The initial startup of the EPP System involves starting the Master server
as well as a Standby server. The Standby server acts as a failover measure
in the event that the Master server fails.
EPP traffic is received via the External Network Bus, flows to the Mes-
sage Server. The Message Server handles all access control, SSL session
management, authentication and EPP schema validation in accordance to
RFC 5731 to 5733 and RFC 5910. The Registry Engine handles authenti-
cation of Registrars as well as processes all EPP commands in accordance
with RFC 5730.
The Standby Server acts as a failover server in event that the Master Server
fails. The Standby server is in a constant waiting state and is monitored
for availability in the event that is needs to be used. In the event that
the Master Server is overloaded, the Standby Server may be used for load
balancing.
The Remote Standby System is an off-site server that is a complete dupli-
cation of the Master Server and the Standby Server. In the event that the
Master Server and Standby Server fail, the Remote System will act as a
failover and perform exactly as the Master and Standby Servers.
The Remote Off-Site Server will be located at the Johannesburg Internet
Exchange (JINX). Both the primary site (hosting the Master Server and
Standby Co-Located Server) and the backup site (hosting the Remote Off-
Site Server) are highly redundant, state of the art data centers with multiple
power supplies, on-site backup facilities, and offer protection from natural
disasters.
Scalability for the EPP System covers hardware scalability related to system
utilization. Additional servers and required hardware will be added for
the Master Server as well as the Standby Co-Located Server as resource
utilization nears 50%. Any scalability changes made to the Master Server
and Secondary Co-Located server will also be duplicated to the Remote
Off-Site Server.


9 DNSSEC

The dotDurban implementation supports the DNSSEC and conforms to
RFC 5910. The ZA Central Registry will be operating as a thick registry.
A thick registry reflects on DNSSEC in the following way:

Only DNSKEYS will be supported. The Registry will generate the corre-
sponding DS record.

The provided DS record is used for validation purposes only.

Removal of DS records will not be supported on the client side.

Removal of DNSKEYS will remove the associated DS record.

Any changes to the DNSSEC EPP Command Mapping will be determined
by the dotDurban Policy Oversight Committee .


10 EPP Resourcing

The following section provides a high level description of the related in-
frastructure, human and system resources as provided by the ZA Central
Registry and as will be utilised and expanded on for the dotDurban TLD.


10.1 SRS Human Resource

The ZA Central Registry has a compliment of 6 RE administrators, devel-
opers, testers and support staff responsible for the development and day to
day operational requirements including the following roles

System Testing:- Responsibility covers regression testing for all new re-
leases, as well as providing Registrar documentation and notices re-
garding any issues that may crop up from time to time.

System Administration:- Responsibility covers administration of the RE
including installation, configuration, and operating system installation
and configuration.

System Monitoring:- Responsibility covers monitoring of the hardware
dedicated to the RE, RE uptime, RE performance, security and abuse
monitoring, and general operating system health.

Backups:- Responsibility covers the backup requirements of the RE ma-
chines including total system backup and log backups.

Development and Maintenance:- Responsibility covers the development
and maintenance of the RE system including registry policy updates as
may be required from time to time as registry policy changes dictate,
SRS performance monitoring, reporting, statistics gathering, etc.


10.2 Registrar Technical Support

The ZA Central Registry uses its human resources to provide technical sup-
port to Registrars beyond the day to day operational requirements, includ-
ing:

Registry Online Portal:- Support covers the development and mainte-
nance of the online Registry portal, updating EPP related frequently
asked questions and the EPP Command wiki pages.

Registrar Technical Assistance:- The Registry portal incorporates an
online contact mechanism where a Registrar can electronically ask
a question and acquire technical support relating to their enquiry.
Enquiries are tracked through a ticketing system, offering a platform
for effectively monitoring and tracking Registrar enquiries.

Accreditation Support:- The ZA Central Registry offers online capabil-
ity for Registrars to follow a policy aligned process for acquiring ac-
creditation. The accreditation process is performed in 6 steps as listed
below:

1. Providing Registrar contact information
2. Providing Company Registration Document
3. Providing contact information for a primary contact
4. Providing additional information including Registrar logo
5. Reviewing status of integration with the EPP system
6. Uploading of SSL Certificate and acquiring live system credentials

Support relating to accreditation comes in the form of answering ac-
creditation process related queries, assigning test account credentials
to newly applied Registrars, monitoring accreditation progress and
providing live account credentials for accredited Registrars.

Key Management Support covers the safe acquisition of SSL Certificates
from accredited Registrars. Accredited Registrars can safely request
to change their current in-use key.


1 Abstract



This document describes an Extensible Provisioning Protocol (EPP) exten-
sion mapping for the provisioning and management of Domain Name exten-
sions for domain objects stored in a shared central repository. Specified in
XML, the mapping extends the EPP domain name mapping to provide ad-
ditional features required for the control of the DNServices Registry Domain
Objects.


Contents

1 Abstract 1

2 Introduction 2

3 Conventions Used in This Document 2

4 Object Attributes 2
4.1 Auto Renew . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

5 EPP Command Mapping 3

6 EPP Query Commands 3
6.1 EPP 〈check〉 Command . . . . . . . . . . . . . . . . . . . . . 3
6.2 EPP 〈info〉 Command . . . . . . . . . . . . . . . . . . . . . 3
6.3 EPP 〈transfer〉 Command . . . . . . . . . . . . . . . . . . . 4

7 EPP Transform Commands 4
7.1 EPP 〈create〉 Command . . . . . . . . . . . . . . . . . . . . 4
7.2 EPP 〈delete〉 Command . . . . . . . . . . . . . . . . . . . . 6
7.3 EPP 〈renew〉 Command . . . . . . . . . . . . . . . . . . . . . 6
7.4 EPP 〈transfer〉 Command . . . . . . . . . . . . . . . . . . . 6
7.5 EPP 〈update〉 Command . . . . . . . . . . . . . . . . . . . . 6

8 Formal Syntax 9

2 Introduction

This extension provides additional functionality to the Domain object as
described in RFC 5731. The additional functionality is listed below:

1. Auto Renew

2. Cancel Pending Action


3 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 BCP
14, RFC 2119.
In examples, ʺC:ʺ represents lines sent by a protocol client, and ʺS:ʺ rep-
resents lines returned by a protocol server. ʺ⁄⁄⁄⁄ʺ is used to note element
values that have been shortened to better fit page boundaries. Indentation
and white space in examples is provided only to illustrate element relation-
ships and is not a mandatory feature of this protocol.
XML is case sensitive. Unless stated otherwise, XML specifications and ex-
amples provided in this document MUST be interpreted in the character
case presented in order to develop a conforming implementation.
gtldd is used as an abbreviation for http:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-
1-0.


4 Object Attributes

This extension adds an Auto Renew attribute to a domain name object.


4.1 Auto Renew

The auto renew flag is a boolean flag used to control the renew functionality
around a domain upon expiry. If the flag is set to TRUE then the domain
will be automatically renewed in the Registry assuming:

1. There are sufficient funds

2. There are subordinate host dependencies on the domain

5 EPP Command Mapping

6 EPP Query Commands

6.1 EPP 〈check〉 Command

This extension does not add any elements to the EPP 〈check〉 command
or 〈check〉 response described in the EPP domain mapping RFC 5731.


6.2 EPP 〈info〉 Command

This extension does not add any elements to the EPP 〈info〉 command
described in the EPP domain mapping RFC 5731. However, additional ele-
ments are defined for the 〈info〉 response.
When an 〈info〉 command has been processed successfully, the EPP 〈resData〉
element MUST contain child elements as described in the EPP domain map-
ping RFC 5731. In addition, the EPP 〈extension〉 element MAY contain
a child 〈gtldd:infData〉 element that identifies the extension namespace
if the domain object has data associated with this extension and based on
server policy. The 〈gtldd:infData〉 element contains the following child
elements:

- An OPTIONAL 〈gtldd:autoenew〉 element that indicates the domain
object preference for automatic renewal

Example 〈info〉 Response for Auto Renew:



S:〈epp:epp xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
S: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
S: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ〉
S: 〈epp:response〉
S: 〈epp:result code=ʺ1000ʺ〉
S: 〈epp:msg〉Domain Info Command completed successfully〈⁄epp:msg〉
S: 〈⁄epp:result〉
S: 〈epp:resData〉
S: 〈domain:infData〉
S: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
S: 〈domain:roid〉DOM_2W-COZA〈⁄domain:roid〉
S: 〈domain:status s=ʺokʺ〉Domain Creation〈⁄domain:status〉
S: 〈domain:registrant〉testCont〈⁄domain:registrant〉
S: 〈domain:ns〉

S: 〈domain:hostAttr〉
S: 〈domain:hostName〉ns1.otherdomain.gtld〈⁄domain:hostName〉
S: 〈⁄domain:hostAttr〉
S: 〈domain:hostAttr〉
S: 〈domain:hostName〉ns2.otherdomain.gtld〈⁄domain:hostName〉
S: 〈⁄domain:hostAttr〉
S: 〈⁄domain:ns〉
S: 〈domain:clID〉testrar1〈⁄domain:clID〉
S: 〈domain:crID〉testrar1〈⁄domain:crID〉
S: 〈domain:crDate〉2011-02-23T14:43:12Z〈⁄domain:crDate〉
S: 〈domain:upID〉testrar1〈⁄domain:upID〉
S: 〈domain:upDate〉2011-02-23T14:46:18Z〈⁄domain:upDate〉
S: 〈domain:exDate〉2013-02-22T14:43:12Z〈⁄domain:exDate〉
S: 〈⁄domain:infData〉
S: 〈⁄epp:resData〉
S: 〈epp:extension〉
S: 〈gtldd:infData〉
S: 〈gtldd:autorenew〉false〈⁄gtldd:autorenew〉
S: 〈⁄gtldd:infData〉
S: 〈⁄epp:extension〉
S: 〈epp:trID〉
S: 〈epp:clTRID〉CLTRID-12984723857-97L2〈⁄epp:clTRID〉
S: 〈epp:svTRID〉DNS-EPP-12E52FC3CEB-A80EF〈⁄epp:svTRID〉
S: 〈⁄epp:trID〉
S: 〈⁄epp:response〉
S:〈⁄epp:epp〉


6.3 EPP 〈transfer〉 Command

This extension does not add any elements to the EPP 〈transfer〉 command
or 〈transfer〉 response described in the EPP domain mapping RFC 5731.


7 EPP Transform Commands

7.1 EPP 〈create〉 Command

This extension defines additional elements for the EPP 〈create〉 command
described in the EPP domain mapping RFC 5731. The additional auto re-
new elements are defined for the EPP 〈create〉 response as follows.
The EPP 〈create〉 command provides a transform operation that allows a
client to create a domain object. In addition to the EPP command elements

described in the EPP domain mapping RFC 5731, the command MAY con-
tain an 〈extension〉 element, and the 〈extension〉 element MAY contain
a child 〈gtldd:create〉 element that identifies the extension namespace if
the client wants to associate data defined in this extension to the domain
object.
The 〈gtldd:create〉 element contains the following child elements:

- An OPTIONAL 〈gtldd:autorenew〉 element that indicates a childʹs
preference to automatically renew this domain object upon expiration.

Example 〈create〉 Command for autorenew false:

C:〈epp:epp xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
C: xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
C: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
C: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
C: 〈epp:command〉
C: 〈epp:create〉
C: 〈domain:create
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsdʺ〉
C: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
C: 〈domain:ns〉
C: 〈domain:hostAttr〉
C: 〈domain:hostName〉ns1.exampledomain.gtld〈⁄domain:hostName〉
C: 〈domain:hostAddr ip=ʺv4ʺ〉160.124.24.57〈⁄domain:hostAddr〉
C: 〈⁄domain:hostAttr〉
C: 〈domain:hostAttr〉
C: 〈domain:hostName〉ns2.exampledomain.gtld〈⁄domain:hostName〉
C: 〈domain:hostAddr ip=ʺv4ʺ〉160.124.24.58〈⁄domain:hostAddr〉
C: 〈⁄domain:hostAttr〉
C: 〈⁄domain:ns〉
C: 〈domain:registrant〉rant1〈⁄domain:registrant〉
C: 〈domain:authInfo〉
C: 〈domain:pw〉coza〈⁄domain:pw〉
C: 〈⁄domain:authInfo〉
C: 〈⁄domain:create〉
C: 〈⁄epp:create〉
C: 〈epp:extension〉
C: 〈gtldd:create〉
C: 〈gtldd:autorenew〉false〈⁄gtldd:autorenew〉
C: 〈⁄gtldd:create〉
C: 〈⁄epp:extension〉
C: 〈⁄epp:command〉
C:〈⁄epp:epp〉

When a 〈create〉 command has been processed successfully, the EPP re-
sponse is as described in the EPP domain mapping RFC 5731 with the
extension element as follows:

S: 〈epp:extension〉
S: 〈gtldd:gtldData〉
S: 〈gtldd:detail result=ʺsuccessʺ〉
S: AutoRenew ʹFalseʹ successful
S: 〈⁄gtldd:detail〉
S: 〈⁄gtldd:gtldData〉
S: 〈⁄epp:extension〉


7.2 EPP 〈delete〉 Command

This extension does not add any elements to the EPP 〈delete〉 command
or 〈delete〉 response described in the EPP domain mapping RFC 5731.


7.3 EPP 〈renew〉 Command

Although this extension does not add any elements to the EPP 〈renew〉 com-
mand or 〈renew〉 response described in the EPP domain mapping RFC 5731
it does extend the Registryʹs handling of the domain object upon expiry.


7.4 EPP 〈transfer〉 Command

This extension does not add any elements to the EPP 〈transfer〉 command
or 〈transfer〉 response described in the EPP domain mapping RFC 5731.


7.5 EPP 〈update〉 Command

This extension defines additional elements for the EPP 〈update〉 command
described in the EPP domain mapping RFC 5731. The additional elements
and attributes are defined for the EPP 〈update〉 response as follows.
The EPP 〈update〉 command provides a transform operation that allows a
client to modify the attributes of a domain object. In addition to the EPP
command elements described in the EPP domain mapping, the command
MAY contain an 〈extension〉 element, and the 〈extension〉 element MAY

contain a child 〈gtldd:update〉 element that identifies the extension names-
pace if the client wants to update the domain object with data defined in
this extension. The 〈gtldd:update〉 element MAY contain a 〈gtldd:chg〉
element. The 〈gtldd:chg〉 element contains a 〈gtldd:autorenew〉 element
to adjust the automatic renewal status of a domain object.
The 〈gtldd:update〉 element also contains an OPTIONAL ʺcancelPendin-
gActionʺ attribute that a client can use to ask the server operator to cancel
a predefined action as provided by the Registry software. This attribute ac-
cepts XML token values meaning standard text without leading or trailing
whitespace.
The 〈gtldd:update〉 element contains the following child elements:

- An OPTIONAL 〈gtldd:chg〉 element that contains a 〈gtldd:autorenew〉
element that is used to adjust the auto renew flag on the domain ob-
ject.

- An OPTIONAL cancelPendingAction attribute that contains the
predefined action name as provided by the server.

Example 〈update〉 Command for autorenew false:

C:〈epp:epp xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
C: xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
C: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
C: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
C: 〈epp:command〉
C: 〈epp:update〉
C: 〈domain:update
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsdʺ〉
C: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
C: 〈⁄domain:update〉
C: 〈⁄epp:update〉
C: 〈epp:extension〉
C: 〈gtldd:update〉
C: 〈gtldd:chg〉
C: 〈gtldd:autorenew〉false〈⁄gtldd:autorenew〉
C: 〈⁄gtldd:chg〉
C: 〈⁄gtldd:update〉
C: 〈⁄epp:extension〉
C: 〈⁄epp:command〉
C:〈⁄epp:epp〉

When the 〈update〉 command has been processed successfully, the EPP
response is as described in the EPP domain mapping RFC 5731 with the
extension element as follows:

S:〈epp:epp xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
S: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ〉
S: 〈epp:response〉
S: 〈epp:result code=ʺ1001ʺ〉
S: 〈epp:msg〉Domain action ʹPendingUpdateʹ pending〈⁄epp:msg〉
S: 〈⁄epp:result〉
S: 〈epp:extension〉
S: 〈gtldd:gtldData〉
S: 〈gtldd:detail result=ʺsuccessʺ〉
S: AutoRenew ʹFalseʹ successful
S: 〈⁄gtldd:detail〉
S: 〈⁄gtldd:gtldData〉
S: 〈⁄epp:extension〉
S: 〈epp:trID〉
S: 〈epp:clTRID〉CLTRID-12984717630-F490〈⁄epp:clTRID〉
S: 〈epp:svTRID〉DNS-EPP-12E52F2BC78-8AC51〈⁄epp:svTRID〉
S: 〈⁄epp:trID〉
S: 〈⁄epp:response〉
S: 〈⁄epp:epp〉

If a domain object enters a deletion process through expiry or command
then the action MAY be cancelled.
Example 〈update〉 Command for cancelling a pending action:

C:〈epp:epp xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
C: xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
C: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
C: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
C: 〈epp:command〉
C: 〈epp:update〉
C: 〈domain:update
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsdʺ〉
C: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
C: 〈⁄domain:update〉
C: 〈⁄epp:update〉
C: 〈epp:extension〉
C: 〈gtldd:update cancelPendingAction=ʺPendingDeletionʺ⁄〉
C: 〈⁄epp:extension〉
C: 〈⁄epp:command〉
C:〈⁄epp:epp〉

When the 〈update〉 command has been processed successfully, the EPP
response is as described in the EPP domain mapping RFC 5731. However
the action that was specified MUST be cancelled and any status effects on
that domain object removed. If the action is not pending or does not exist
then an appropriate message is returned to the client.


8 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.

BEGIN
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈schema targetNamespace=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0 domain command extension ⁄⁄⁄⁄
schema for gTLD required extensions 〈⁄documentation〉
〈⁄annotation〉

〈element name=ʺcreateʺ type=ʺgtldd:createTypeʺ⁄〉
〈element name=ʺupdateʺ type=ʺgtldd:updateTypeʺ⁄〉
〈element name=ʺinfDataʺ type=ʺgtldd:infoResponseTypeʺ⁄〉
〈element name=ʺgtldDataʺ type=ʺgtldd:gtldDataTypeʺ⁄〉

〈complexType name=ʺchgTypeʺ〉
〈sequence〉
〈element name=ʺautorenewʺ type=ʺgtldd:autoRenewTypeʺ minOccurs=ʺ0ʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈complexType name=ʺupdateTypeʺ〉
〈sequence〉
〈element name=ʺchgʺ type=ʺgtldd:chgTypeʺ minOccurs=ʺ0ʺ⁄〉
〈⁄sequence〉
〈attribute name=ʺcancelPendingActionʺ type=ʺstringʺ use=ʺoptionalʺ⁄〉
〈⁄complexType〉

〈complexType name=ʺcreateTypeʺ〉
〈sequence〉
〈element name=ʺautorenewʺ type=ʺgtldd:autoRenewTypeʺ minOccurs=ʺ0ʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈complexType name=ʺinfoResponseTypeʺ〉
〈sequence〉
〈element name=ʺautorenewʺ type=ʺgtldd:autoRenewTypeʺ minOccurs=ʺ0ʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉
〈complexType name=ʺgtldDataTypeʺ〉
〈sequence〉
〈element name=ʺdetailʺ〉
〈complexType〉
〈simpleContent〉
〈extension base=ʺstringʺ〉
〈attribute name=ʺresultʺ type=ʺgtldd:resultTypeʺ use=ʺrequiredʺ⁄〉
〈⁄extension〉
〈⁄simpleContent〉
〈⁄complexType〉
〈⁄element〉
〈⁄sequence〉
〈⁄complexType〉

〈simpleType name=ʺresultTypeʺ〉
〈restriction base=ʺNMTOKENʺ〉
〈enumeration value=ʺsuccessʺ⁄〉
〈enumeration value=ʺfailureʺ⁄〉
〈⁄restriction〉
〈⁄simpleType〉

〈simpleType name=ʺautoRenewTypeʺ〉
〈restriction base=ʺbooleanʺ〉
〈⁄restriction〉
〈⁄simpleType〉

〈⁄schema〉
END

gTLDFull Legal NameE-mail suffixDetail
.capetownUniForum SA (NPC) trading as ZA Central Registrydundas.co.zaView
THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE FULL ANSWER TO THIS QUESTION IS ATTACHED AS PDF FILES dotCapetown-q25.pdf and dotCapetown-q25-rfc.pdf, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.

1 Synopsis

This chapter provides details on the ZA Central Registry Shared Registry
System Extensible Provisioning Protocol EPP functionality as will be used
by the dotCapeTown TLD.


2 Overview

The functionality of the ZA Central Registry Shared Registry System allows
registrars to interface using the EPP protocol and commands as defined in
the following RFCs and as referenced in this document:

RFC 3735:- Guidelines for Extending the EPP.

RFC 5730:- EPP Description.

RFC 5731:- EPP Domain Name Mapping.

RFC 5732:- EPP Host Mapping.

RFC 5733:- EPP Contact Mapping.

RFC 5734:- EPP TCP Transport.

RFC 5910:- EPP DNSSEC.

The ZA Central Registry Shared Registry System also conforms to the
above-mentioned RFCs.
The ZA Central Registry does not provide support for Domain Registry
Grace Period Mapping as per RFC 3915.
The ZA Central Registry will not be supporting International Domain Names
at startup.


3 Registrar Interface

The dotCapeTown implementation listens for incoming TCP connection re-
quests. Once a client has issued an EPP 〈login〉 command on the listening
port, the server responds, creating the required session and sending back an
EPP 〈greeting〉 to the client.
To end a session, a client may close the connection by issuing EPP 〈logout〉
command or an active close call.

The dotCapeTown implementation automatically closes a session once the
session has idled for 24 hours.
A total of 2 concurrent sessions per client are allowed.
A Registrar can only establish a TCP connection to the server if they have
been technically accredited, provided the ZA Central Registry with their
public key and the public key has been successfully installed.
Exchanging of messages between client and server conforms to the require-
ments outlined in RFC 5734, and follows the general client-server message
exchange as outlined in Figure 1 of RFC 5734 Section 3.
Pipelining commands is possible. The server supports command pipelining
to a maximum limit of the connection buffer of 16384 bytes.
The dotCapeTown implementation returns a message from the server to the
client for every command performed. If a message is lost due to connection
failure, the result code can only be retrieved if the client issues the same
command using the same client transaction identifier 〈clTRID〉 .
The dotCapeTown implementation uses SSL⁄TLS as well as IP based Access
Control Lists. A session is started on login only if an SSL handshake is
established and the client IP Address is listed on the Access Control List.
Further security measures include authentication through use of usernames
and passwords. A session is terminated upon logout. A session is valid for
24 hours.
The dotCapeTown handling and interpretation of the EPP Data Units con-
forms to RFC 5734 Section 4, whereby the format of any EPP data unit will
contain the 32-bit header describing the total length of the data unit, and
the EPP XML Instance.
Length and calculation of data units conform with requirements outlined in
RFC 5734 .
Changes in the implementation can be made and will have to be decided by
the dotCapeTown Policy Oversight Committee .


4 Extensible Provisioning Protocol (EPP)

This section describes the capability of the ZA Central Registry Shared
Registry System EPP and compliance with RFC 5730


4.1 Protocol Description

EPP is an XML based protocol used for provisioning domains and their
associated objects. The dotCapeTown EPP implementation supports all

commands as defined in RFC 5730.


4.2 Protocol Commands

A command is any action performed on an object. Commands are grouped
into session, query and object transformation commands as follows in the
list below:

Protocol:-
* login
* logout
Query:-
* Check
* Info
* Poll
* Transfer
Transform:-
* Create
* Delete
* Renew
* Transfer
* Update


4.3 EPP 〈login〉 Protocol Command

The dotCapeTown implementation of the EPP 〈login〉 command conforms
to the requirements outlined in RFC 5730 Section 2.9.1.1.


4.4 EPP 〈logout〉 Protocol Command

The dotCapeTown implementation of the EPP 〈logout〉 command con-
forms to the requirements outlined in RFC 5730 Section 2.9.1.2 .


4.5 EPP 〈poll〉 Protocol Command

The dotCapeTown implementation of the EPP 〈poll〉 command conforms
to the requirements outlined in RFC 5730 Section 2.9.2.3 .

4.6 Command Response

For each EPP command that is issued by the client to the server, a corre-
sponding response will be returned to the client by the server.
Every response will contain a result code. The result code indicates com-
mand success or failure. The dotCapeTown implementation conforms to the
theory of result codes outlined in RFC 5321 Section 4.2.1 and uses a fourth
digit in its response codes.


5 EPP Domain Name Mapping

5.1 Overview

The following section provides details on how the ZA Central Registry
Shared Registry System maps its domain functionality. Any changes to
the EPP Domain Name Mapping command set will be determined by the
dotCapeTown Policy Oversight Committee .


5.2 Relationship of Domain Objects and Host Objects

All created domain name objects require a minimum of 2 unique subordinate
or delegated host objects.


5.3 Object Attributes

Domain and Host Names:- Only domain names conforming to standard
ASCII will be used. Internationalized Domain Names (IDN)s must be
provided in A-Label format.

Contact and Client Identifiers:- Client and contact identifiers will be
represented through a clID element to create an association with a
domain object.

Status Values:- The dotCapeTown implementation supports server and
client status interaction outlined in RFC 5731.

Dates and Times:- All dates and times conform to RFC 5731 and are
represented using UTC.

Validity Periods:- The dotCapeTown implementation supports validity
periods in months and years, as well as a combination of both.

Authorisation Information:- The dotCapeTown implementation supports
domain name object authorisation through use of passwords as defined
in RFC 5731. Passwords are stored in one-way hash format.


5.4 EPP 〈check〉 Command

The dotCapeTown implementation of the EPP 〈check〉 command conforms
to the requirements outlined in RFC 5731 . The Domain 〈check〉 command
will be limited to 100 checks per command.


5.5 EPP 〈info〉 Command

The dotCapeTown implementation of the EPP 〈info〉 command conforms
to the requirements outlined in RFC 5731 Section 3.1.2. The 〈info〉 com-
mand response will be restricted based on the requester credentials. Expiry
dates and other information will not be presented to unauthorized sources.


5.6 EPP 〈transfer〉 Command

The dotCapeTown implementation of the EPP 〈transfer〉 command con-
forms to the requirements outlined in RFC 5731.
The dotCapeTown implementation supports the following EPP 〈transfer〉
operations which conform to RFC 5730 :

ʺqueryʺ:- Allows a client to identify the current status of a transfer request
on a domain name object.

ʺrequestʺ:- Allows a client to request a transfer of a domain object from
one sponsor to another.

ʺcancelʺ:- Allows a client to cancel their transfer request for a domain as
long as the domain has not yet been transferred.

ʺapproveʺ:- Allows the current domain sponsor to approve a transfer re-
quest for the requested domain.

ʺrejectʺ:- Allows the current domain sponsor the reject a transfer request
for the requested domain.

The dotCapeTown implementation incorporates an e-mail voting system
whereby a registrant is allowed to vote on the transfer of a domain. An
EPP Poll message will be queued for the current sponsor for transfer vote
notification.

5.7 EPP 〈create〉 Command

The dotCapeTown implementation of the EPP 〈create〉 command restricts
the use of the 〈period〉 element where the registry defines the registration
period of a domain object.


5.8 EPP 〈delete〉 Command

The dotCapeTown implementation of the EPP 〈delete〉 command con-
forms to the requirements outlined in RFC 5731 Section 3.2.2 . The dot-
CapeTown implementation denotes that any domain that undergoes a 〈delete〉
command is checked to conform to subordinate host dependencies outlined
in RFC 5731 . A deletion request on a domain object will be prohibited if
the subordinate host objects are referenced by other domains belonging to
the same registrar.


5.9 EPP 〈renew〉 Command

The dotCapeTown implementation of the EPP 〈renew〉 command restricts
the use of the 〈domain:period〉 element. The domain object can only be
renewed to a maximum of one period.


5.10 EPP 〈update〉 Command

The dotCapeTown implementation of the EPP 〈update〉 command con-
forms to the requirements outlined in RFC 5731 . The dotCapeTown imple-
mentation utilises the 〈domain:contact〉 element to set ʺtechʺ, ʺbillingʺ,
ʺadminʺ contacts to domain name objects.


6 EPP Host Mapping

The following section provides details on how the ZA Central Registry
Shared Registry System maps its host functionality. The dotCapeTown im-
plementation restricts the host creation and usage to the individual registrar.
In other words each registrar controls and maintains their own set of hosts
even if the names are duplicated with other registrars. Subordinate host
glue publication is strictly controlled to prevent nameserver masquerading.

6.1 Relationship of Domain Objects and Host Objects

All created domain name objects require a minimum of 2 unique subordinate
or delegated host objects.


6.2 Object Attributes

Host Names:- Only host names conforming to standard ASCII will be
used.

Status Values:- The dotCapeTown implementation supports server and
client status interaction outlined in RFC 5732.

Dates and Times:- All dates and times conform to RFC 5732 and are
represented using UTC.

Glue:- The dotCapeTown implementation supports IPv4 and IPv6 ad-
dresses, conforming to the requirements outlined in RFC 0791 and
RFC 4291 respectively.


6.3 EPP 〈check〉 Command

The dotCapeTown implementation of the EPP 〈check〉 command conforms
to the requirements outlined in RFC 5732 .


6.4 EPP 〈info〉 Command

The dotCapeTown implementation of the EPP 〈info〉 command conforms
to the requirements outlined in RFC 5732 .


6.5 EPP 〈create〉 Command

The dotCapeTown implementation of the EPP 〈create〉 command con-
forms to the requirements outlined in RFC 5732. The use of the Host create
command might be restricted in lieu of the Domain Host handling during
Domain update and creation. The eventual Host create usage will be deter-
mined by the dotCapeTown Policy Oversight Committee .


6.6 EPP 〈delete〉 Command

The dotCapeTown Implementation of the EPP 〈delete〉 command con-
forms to the requirements outlined in RFC 5732.

The dotCapeTown implementation denotes that any host that undergoes a
〈delete〉 command is checked for dependencies outlined in RFC 5731 .


6.7 EPP 〈update〉 Command

The dotCapeTown implementation of the EPP 〈update〉 command con-
forms to the requirements outlined in RFC 5732.
The dotCapeTownimplementation dictates that the changing of a host ob-
ject information is performed through the domain object mapping using the
domain 〈update〉 command.


7 EPP Contact Mapping

7.1 Overview

The following section provides details on how the ZA Central Registry
Shared Registry System maps its contact functionality.
Any changes to the EPP Contact Mapping command set will be determined
by the dotCapeTown Policy Oversight Committee . In the dotCapeTown
implementation the Registrar objects are stored as standard EPP Contact
objects, thus allowing a registrar to adjust contact information such as pass-
words or support addresses.


7.2 Object Attributes

Contact and Client Identifiers:- Client and contact identifiers will be
represented through a clID element to create an association with a
domain object.

Status Values:- The dotCapeTown implementation supports server and
client statuses outlined in RFC 5733. Status combination interactions
conform to RFC 5733 .

Internationalized Postal Info:- The dotCapeTown implementation sup-
ports postal information represented as a subset of UTF-8 encoding in
7-bit ASCII. All required and optional elements for a contact object
are supported by the dotCapeTown implementation.

Localized Postal Info:- The dotCapeTown implementation also supports
postal information represented in UTF-8 encoding. All required and
optional elements for a contact object are supported by the dotCapeTown
implementation.

Telephone Numbers:- The dotCapeTown implementation conforms to RFC 5733
by ensuring that all telephone numbers begin with a plus (ʺ+ʺ) sign
followed by a country code as defined in ITU.E164.2005, followed by a
dot (ʺ.ʺ), followed by a sequence of digits representing the telephone
number.

E-mail Addresses:- The dotCapeTown implementation conforms to the
requirements for e-mail addresses as defined in RFC 5322.

Dates and Times:- All dates and times conform to RFC 5733. The dot-
CapeTown implementation supports time zone representation in UTC
format.

Authorisation Information:- The dotCapeTown implementation supports
contact object authorisation through use of passwords, conforming to
outlined requirements in RFC 5733. Passwords are stored in one-way
hash format.

Disclosure of Contact Elements and Attributes:- The dotCapeTown
implementation supports disclosure of contact attributes and conforms
to RFC 5730, by announcing its data collection policies. The dot-
CapeTown implementation supports the disclosure elements outlined
in RFC 5733.


7.3 EPP 〈check〉 Command

The dotCapeTown implementation of the EPP 〈check〉 command conforms
to the requirements outlined in RFC 5733 .


7.4 EPP 〈info〉 Command

The dotCapeTown implementation of the EPP 〈info〉 command conforms
to the requirements outlined in RFC 5733. The disclosure of Contact infor-
mation will obey the disclose options as provided for the Contact object.


7.5 EPP 〈transfer〉 Command

The dotCapeTown implementation of the EPP 〈transfer〉 query command
conforms to the requirements outlined in RFC 5733.

7.6 EPP 〈create〉 Command

The dotCapeTown implementation of the EPP 〈create〉 command con-
forms to the requirements outlined in RFC 5733 .
The dotCapeTown implementation supports the creation of a contact object
with both 〈contact:postalInfo〉 types of ʺlocʺ and ʺintʺ, conforming to
the requirements outlined in RFC 5733 Section 3.2.1 .


7.7 EPP 〈delete〉 Command

Implementation of the EPP 〈delete〉 command conforms to the require-
ments outlined in RFC 5733 Section 3.2.2.


Current policy states that a contact object cannot be deleted if in any way
it is associated with another object. If a contact object is still associated
with a domain object, the contact object is not deleted until the association
between contact and domain objects is removed.



7.8 EPP 〈update〉 Command

The dotCapeTown implementation of the EPP 〈update〉 command con-
forms to the requirements outlined in RFC 5733 .
The dotCapeTown implementation supports the updating of a contact ob-
ject with both 〈contact:postalInfo〉 types of ʺlocʺ and ʺintʺ, conforming
to the requirements outlined in RFC 5733 Section 3.2.5 .



8 EPP Technical Plan

The Technical Layout will include the following:

* On-site Scalable Master Server with the following configuration:

Message Server:- The Message Server is responsible for handling
session management, access control, user authentication EPP
schema validation and Poll commands.
Registry Engine:- The Registry Engine is responsible for all object
level query and transform commands.
Database:- The primary Registry Engine database.

* Scalable Standby Co-located Server with the following configuration:

Message Server:- A secondary Message Server used in the event
that the Master Server fails.
Registry Engine:- A secondary registry Engine used in the event
that the Master Server fails.
Standby Database:- A secondary database that is used in the event
that the primary database on the Master Server fails.


* Off-site Remote Standby Server with the following configuration:

The Remote Off-Site Server configuration is a mirror of the
Master site.

From the Technical Layout above, the EPP Technical Plan is as follows:
The initial startup of the EPP System involves starting the Master server
as well as a Standby server. The Standby server acts as a failover measure
in the event that the Master server fails.
EPP traffic is received via the External Network Bus, flows to the Mes-
sage Server. The Message Server handles all access control, SSL session
management, authentication and EPP schema validation in accordance to
RFC 5731 to 5733 and RFC 5910. The Registry Engine handles authenti-
cation of Registrars as well as processes all EPP commands in accordance
with RFC 5730.
The Standby Server acts as a failover server in event that the Master Server
fails. The Standby server is in a constant waiting state and is monitored
for availability in the event that is needs to be used. In the event that
the Master Server is overloaded, the Standby Server may be used for load
balancing.
The Remote Standby System is an off-site server that is a complete dupli-
cation of the Master Server and the Standby Server. In the event that the
Master Server and Standby Server fail, the Remote System will act as a
failover and perform exactly as the Master and Standby Servers.
The Remote Off-Site Server will be located at the Johannesburg Internet
Exchange (JINX). Both the primary site (hosting the Master Server and
Standby Co-Located Server) and the backup site (hosting the Remote Off-
Site Server) are highly redundant, state of the art data centers with multiple
power supplies, on-site backup facilities, and offer protection from natural
disasters.
Scalability for the EPP System covers hardware scalability related to system
utilization. Additional servers and required hardware will be added for
the Master Server as well as the Standby Co-Located Server as resource
utilization nears 50%. Any scalability changes made to the Master Server
and Secondary Co-Located server will also be duplicated to the Remote
Off-Site Server.


9 DNSSEC

The dotCapeTown implementation supports the DNSSEC and conforms to
RFC 5910. The ZA Central Registry will be operating as a thick registry.
A thick registry reflects on DNSSEC in the following way:

Only DNSKEYS will be supported. The Registry will generate the corre-
sponding DS record.

The provided DS record is used for validation purposes only.

Removal of DS records will not be supported on the client side.

Removal of DNSKEYS will remove the associated DS record.

Any changes to the DNSSEC EPP Command Mapping will be determined
by the dotCapeTown Policy Oversight Committee .


10 EPP Resourcing

The following section provides a high level description of the related in-
frastructure, human and system resources as provided by the ZA Central
Registry and as will be utilised and expanded on for the dotCapeTown TLD.


10.1 SRS Human Resource

The ZA Central Registry has a compliment of 6 RE administrators, devel-
opers, testers and support staff responsible for the development and day to
day operational requirements including the following roles

System Testing:- Responsibility covers regression testing for all new re-
leases, as well as providing Registrar documentation and notices re-
garding any issues that may crop up from time to time.

System Administration:- Responsibility covers administration of the RE
including installation, configuration, and operating system installation
and configuration.

System Monitoring:- Responsibility covers monitoring of the hardware
dedicated to the RE, RE uptime, RE performance, security and abuse
monitoring, and general operating system health.

Backups:- Responsibility covers the backup requirements of the RE ma-
chines including total system backup and log backups.

Development and Maintenance:- Responsibility covers the development
and maintenance of the RE system including registry policy updates as
may be required from time to time as registry policy changes dictate,
SRS performance monitoring, reporting, statistics gathering, etc.


10.2 Registrar Technical Support

The ZA Central Registry uses its human resources to provide technical sup-
port to Registrars beyond the day to day operational requirements, includ-
ing:

Registry Online Portal:- Support covers the development and mainte-
nance of the online Registry portal, updating EPP related frequently
asked questions and the EPP Command wiki pages.

Registrar Technical Assistance:- The Registry portal incorporates an
online contact mechanism where a Registrar can electronically ask
a question and acquire technical support relating to their enquiry.
Enquiries are tracked through a ticketing system, offering a platform
for effectively monitoring and tracking Registrar enquiries.

Accreditation Support:- The ZA Central Registry offers online capabil-
ity for Registrars to follow a policy aligned process for acquiring ac-
creditation. The accreditation process is performed in 6 steps as listed
below:

1. Providing Registrar contact information
2. Providing Company Registration Document
3. Providing contact information for a primary contact
4. Providing additional information including Registrar logo
5. Reviewing status of integration with the EPP system
6. Uploading of SSL Certificate and acquiring live system credentials

Support relating to accreditation comes in the form of answering ac-
creditation process related queries, assigning test account credentials
to newly applied Registrars, monitoring accreditation progress and
providing live account credentials for accredited Registrars.

Key Management Support covers the safe acquisition of SSL Certificates
from accredited Registrars. Accredited Registrars can safely request
to change their current in-use key.


1 Abstract



This document describes an Extensible Provisioning Protocol (EPP) exten-
sion mapping for the provisioning and management of Domain Name exten-
sions for domain objects stored in a shared central repository. Specified in
XML, the mapping extends the EPP domain name mapping to provide ad-
ditional features required for the control of the DNServices Registry Domain
Objects.


Contents

1 Abstract 1

2 Introduction 2

3 Conventions Used in This Document 2

4 Object Attributes 2
4.1 Auto Renew . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

5 EPP Command Mapping 3

6 EPP Query Commands 3
6.1 EPP 〈check〉 Command . . . . . . . . . . . . . . . . . . . . . 3
6.2 EPP 〈info〉 Command . . . . . . . . . . . . . . . . . . . . . 3
6.3 EPP 〈transfer〉 Command . . . . . . . . . . . . . . . . . . . 4

7 EPP Transform Commands 4
7.1 EPP 〈create〉 Command . . . . . . . . . . . . . . . . . . . . 4
7.2 EPP 〈delete〉 Command . . . . . . . . . . . . . . . . . . . . 6
7.3 EPP 〈renew〉 Command . . . . . . . . . . . . . . . . . . . . . 6
7.4 EPP 〈transfer〉 Command . . . . . . . . . . . . . . . . . . . 6
7.5 EPP 〈update〉 Command . . . . . . . . . . . . . . . . . . . . 6

8 Formal Syntax 9

2 Introduction

This extension provides additional functionality to the Domain object as
described in RFC 5731. The additional functionality is listed below:

1. Auto Renew

2. Cancel Pending Action


3 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 BCP
14, RFC 2119.
In examples, ʺC:ʺ represents lines sent by a protocol client, and ʺS:ʺ rep-
resents lines returned by a protocol server. ʺ⁄⁄⁄⁄ʺ is used to note element
values that have been shortened to better fit page boundaries. Indentation
and white space in examples is provided only to illustrate element relation-
ships and is not a mandatory feature of this protocol.
XML is case sensitive. Unless stated otherwise, XML specifications and ex-
amples provided in this document MUST be interpreted in the character
case presented in order to develop a conforming implementation.
gtldd is used as an abbreviation for http:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-
1-0.


4 Object Attributes

This extension adds an Auto Renew attribute to a domain name object.


4.1 Auto Renew

The auto renew flag is a boolean flag used to control the renew functionality
around a domain upon expiry. If the flag is set to TRUE then the domain
will be automatically renewed in the Registry assuming:

1. There are sufficient funds

2. There are subordinate host dependencies on the domain

5 EPP Command Mapping

6 EPP Query Commands

6.1 EPP 〈check〉 Command

This extension does not add any elements to the EPP 〈check〉 command
or 〈check〉 response described in the EPP domain mapping RFC 5731.


6.2 EPP 〈info〉 Command

This extension does not add any elements to the EPP 〈info〉 command
described in the EPP domain mapping RFC 5731. However, additional ele-
ments are defined for the 〈info〉 response.
When an 〈info〉 command has been processed successfully, the EPP 〈resData〉
element MUST contain child elements as described in the EPP domain map-
ping RFC 5731. In addition, the EPP 〈extension〉 element MAY contain
a child 〈gtldd:infData〉 element that identifies the extension namespace
if the domain object has data associated with this extension and based on
server policy. The 〈gtldd:infData〉 element contains the following child
elements:

- An OPTIONAL 〈gtldd:autoenew〉 element that indicates the domain
object preference for automatic renewal

Example 〈info〉 Response for Auto Renew:



S:〈epp:epp xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
S: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
S: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ〉
S: 〈epp:response〉
S: 〈epp:result code=ʺ1000ʺ〉
S: 〈epp:msg〉Domain Info Command completed successfully〈⁄epp:msg〉
S: 〈⁄epp:result〉
S: 〈epp:resData〉
S: 〈domain:infData〉
S: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
S: 〈domain:roid〉DOM_2W-COZA〈⁄domain:roid〉
S: 〈domain:status s=ʺokʺ〉Domain Creation〈⁄domain:status〉
S: 〈domain:registrant〉testCont〈⁄domain:registrant〉
S: 〈domain:ns〉

S: 〈domain:hostAttr〉
S: 〈domain:hostName〉ns1.otherdomain.gtld〈⁄domain:hostName〉
S: 〈⁄domain:hostAttr〉
S: 〈domain:hostAttr〉
S: 〈domain:hostName〉ns2.otherdomain.gtld〈⁄domain:hostName〉
S: 〈⁄domain:hostAttr〉
S: 〈⁄domain:ns〉
S: 〈domain:clID〉testrar1〈⁄domain:clID〉
S: 〈domain:crID〉testrar1〈⁄domain:crID〉
S: 〈domain:crDate〉2011-02-23T14:43:12Z〈⁄domain:crDate〉
S: 〈domain:upID〉testrar1〈⁄domain:upID〉
S: 〈domain:upDate〉2011-02-23T14:46:18Z〈⁄domain:upDate〉
S: 〈domain:exDate〉2013-02-22T14:43:12Z〈⁄domain:exDate〉
S: 〈⁄domain:infData〉
S: 〈⁄epp:resData〉
S: 〈epp:extension〉
S: 〈gtldd:infData〉
S: 〈gtldd:autorenew〉false〈⁄gtldd:autorenew〉
S: 〈⁄gtldd:infData〉
S: 〈⁄epp:extension〉
S: 〈epp:trID〉
S: 〈epp:clTRID〉CLTRID-12984723857-97L2〈⁄epp:clTRID〉
S: 〈epp:svTRID〉DNS-EPP-12E52FC3CEB-A80EF〈⁄epp:svTRID〉
S: 〈⁄epp:trID〉
S: 〈⁄epp:response〉
S:〈⁄epp:epp〉


6.3 EPP 〈transfer〉 Command

This extension does not add any elements to the EPP 〈transfer〉 command
or 〈transfer〉 response described in the EPP domain mapping RFC 5731.


7 EPP Transform Commands

7.1 EPP 〈create〉 Command

This extension defines additional elements for the EPP 〈create〉 command
described in the EPP domain mapping RFC 5731. The additional auto re-
new elements are defined for the EPP 〈create〉 response as follows.
The EPP 〈create〉 command provides a transform operation that allows a
client to create a domain object. In addition to the EPP command elements

described in the EPP domain mapping RFC 5731, the command MAY con-
tain an 〈extension〉 element, and the 〈extension〉 element MAY contain
a child 〈gtldd:create〉 element that identifies the extension namespace if
the client wants to associate data defined in this extension to the domain
object.
The 〈gtldd:create〉 element contains the following child elements:

- An OPTIONAL 〈gtldd:autorenew〉 element that indicates a childʹs
preference to automatically renew this domain object upon expiration.

Example 〈create〉 Command for autorenew false:

C:〈epp:epp xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
C: xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
C: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
C: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
C: 〈epp:command〉
C: 〈epp:create〉
C: 〈domain:create
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsdʺ〉
C: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
C: 〈domain:ns〉
C: 〈domain:hostAttr〉
C: 〈domain:hostName〉ns1.exampledomain.gtld〈⁄domain:hostName〉
C: 〈domain:hostAddr ip=ʺv4ʺ〉160.124.24.57〈⁄domain:hostAddr〉
C: 〈⁄domain:hostAttr〉
C: 〈domain:hostAttr〉
C: 〈domain:hostName〉ns2.exampledomain.gtld〈⁄domain:hostName〉
C: 〈domain:hostAddr ip=ʺv4ʺ〉160.124.24.58〈⁄domain:hostAddr〉
C: 〈⁄domain:hostAttr〉
C: 〈⁄domain:ns〉
C: 〈domain:registrant〉rant1〈⁄domain:registrant〉
C: 〈domain:authInfo〉
C: 〈domain:pw〉coza〈⁄domain:pw〉
C: 〈⁄domain:authInfo〉
C: 〈⁄domain:create〉
C: 〈⁄epp:create〉
C: 〈epp:extension〉
C: 〈gtldd:create〉
C: 〈gtldd:autorenew〉false〈⁄gtldd:autorenew〉
C: 〈⁄gtldd:create〉
C: 〈⁄epp:extension〉
C: 〈⁄epp:command〉
C:〈⁄epp:epp〉

When a 〈create〉 command has been processed successfully, the EPP re-
sponse is as described in the EPP domain mapping RFC 5731 with the
extension element as follows:

S: 〈epp:extension〉
S: 〈gtldd:gtldData〉
S: 〈gtldd:detail result=ʺsuccessʺ〉
S: AutoRenew ʹFalseʹ successful
S: 〈⁄gtldd:detail〉
S: 〈⁄gtldd:gtldData〉
S: 〈⁄epp:extension〉


7.2 EPP 〈delete〉 Command

This extension does not add any elements to the EPP 〈delete〉 command
or 〈delete〉 response described in the EPP domain mapping RFC 5731.


7.3 EPP 〈renew〉 Command

Although this extension does not add any elements to the EPP 〈renew〉 com-
mand or 〈renew〉 response described in the EPP domain mapping RFC 5731
it does extend the Registryʹs handling of the domain object upon expiry.


7.4 EPP 〈transfer〉 Command

This extension does not add any elements to the EPP 〈transfer〉 command
or 〈transfer〉 response described in the EPP domain mapping RFC 5731.


7.5 EPP 〈update〉 Command

This extension defines additional elements for the EPP 〈update〉 command
described in the EPP domain mapping RFC 5731. The additional elements
and attributes are defined for the EPP 〈update〉 response as follows.
The EPP 〈update〉 command provides a transform operation that allows a
client to modify the attributes of a domain object. In addition to the EPP
command elements described in the EPP domain mapping, the command
MAY contain an 〈extension〉 element, and the 〈extension〉 element MAY

contain a child 〈gtldd:update〉 element that identifies the extension names-
pace if the client wants to update the domain object with data defined in
this extension. The 〈gtldd:update〉 element MAY contain a 〈gtldd:chg〉
element. The 〈gtldd:chg〉 element contains a 〈gtldd:autorenew〉 element
to adjust the automatic renewal status of a domain object.
The 〈gtldd:update〉 element also contains an OPTIONAL ʺcancelPendin-
gActionʺ attribute that a client can use to ask the server operator to cancel
a predefined action as provided by the Registry software. This attribute ac-
cepts XML token values meaning standard text without leading or trailing
whitespace.
The 〈gtldd:update〉 element contains the following child elements:

- An OPTIONAL 〈gtldd:chg〉 element that contains a 〈gtldd:autorenew〉
element that is used to adjust the auto renew flag on the domain ob-
ject.

- An OPTIONAL cancelPendingAction attribute that contains the
predefined action name as provided by the server.

Example 〈update〉 Command for autorenew false:

C:〈epp:epp xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
C: xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
C: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
C: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
C: 〈epp:command〉
C: 〈epp:update〉
C: 〈domain:update
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsdʺ〉
C: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
C: 〈⁄domain:update〉
C: 〈⁄epp:update〉
C: 〈epp:extension〉
C: 〈gtldd:update〉
C: 〈gtldd:chg〉
C: 〈gtldd:autorenew〉false〈⁄gtldd:autorenew〉
C: 〈⁄gtldd:chg〉
C: 〈⁄gtldd:update〉
C: 〈⁄epp:extension〉
C: 〈⁄epp:command〉
C:〈⁄epp:epp〉

When the 〈update〉 command has been processed successfully, the EPP
response is as described in the EPP domain mapping RFC 5731 with the
extension element as follows:

S:〈epp:epp xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
S: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ〉
S: 〈epp:response〉
S: 〈epp:result code=ʺ1001ʺ〉
S: 〈epp:msg〉Domain action ʹPendingUpdateʹ pending〈⁄epp:msg〉
S: 〈⁄epp:result〉
S: 〈epp:extension〉
S: 〈gtldd:gtldData〉
S: 〈gtldd:detail result=ʺsuccessʺ〉
S: AutoRenew ʹFalseʹ successful
S: 〈⁄gtldd:detail〉
S: 〈⁄gtldd:gtldData〉
S: 〈⁄epp:extension〉
S: 〈epp:trID〉
S: 〈epp:clTRID〉CLTRID-12984717630-F490〈⁄epp:clTRID〉
S: 〈epp:svTRID〉DNS-EPP-12E52F2BC78-8AC51〈⁄epp:svTRID〉
S: 〈⁄epp:trID〉
S: 〈⁄epp:response〉
S: 〈⁄epp:epp〉

If a domain object enters a deletion process through expiry or command
then the action MAY be cancelled.
Example 〈update〉 Command for cancelling a pending action:

C:〈epp:epp xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
C: xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
C: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
C: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
C: 〈epp:command〉
C: 〈epp:update〉
C: 〈domain:update
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsdʺ〉
C: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
C: 〈⁄domain:update〉
C: 〈⁄epp:update〉
C: 〈epp:extension〉
C: 〈gtldd:update cancelPendingAction=ʺPendingDeletionʺ⁄〉
C: 〈⁄epp:extension〉
C: 〈⁄epp:command〉
C:〈⁄epp:epp〉

When the 〈update〉 command has been processed successfully, the EPP
response is as described in the EPP domain mapping RFC 5731. However
the action that was specified MUST be cancelled and any status effects on
that domain object removed. If the action is not pending or does not exist
then an appropriate message is returned to the client.


8 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.

BEGIN
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈schema targetNamespace=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0 domain command extension ⁄⁄⁄⁄
schema for gTLD required extensions 〈⁄documentation〉
〈⁄annotation〉

〈element name=ʺcreateʺ type=ʺgtldd:createTypeʺ⁄〉
〈element name=ʺupdateʺ type=ʺgtldd:updateTypeʺ⁄〉
〈element name=ʺinfDataʺ type=ʺgtldd:infoResponseTypeʺ⁄〉
〈element name=ʺgtldDataʺ type=ʺgtldd:gtldDataTypeʺ⁄〉

〈complexType name=ʺchgTypeʺ〉
〈sequence〉
〈element name=ʺautorenewʺ type=ʺgtldd:autoRenewTypeʺ minOccurs=ʺ0ʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈complexType name=ʺupdateTypeʺ〉
〈sequence〉
〈element name=ʺchgʺ type=ʺgtldd:chgTypeʺ minOccurs=ʺ0ʺ⁄〉
〈⁄sequence〉
〈attribute name=ʺcancelPendingActionʺ type=ʺstringʺ use=ʺoptionalʺ⁄〉
〈⁄complexType〉

〈complexType name=ʺcreateTypeʺ〉
〈sequence〉
〈element name=ʺautorenewʺ type=ʺgtldd:autoRenewTypeʺ minOccurs=ʺ0ʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈complexType name=ʺinfoResponseTypeʺ〉
〈sequence〉
〈element name=ʺautorenewʺ type=ʺgtldd:autoRenewTypeʺ minOccurs=ʺ0ʺ⁄〉
〈⁄sequence〉
〈⁄complexType〉
〈complexType name=ʺgtldDataTypeʺ〉
〈sequence〉
〈element name=ʺdetailʺ〉
〈complexType〉
〈simpleContent〉
〈extension base=ʺstringʺ〉
〈attribute name=ʺresultʺ type=ʺgtldd:resultTypeʺ use=ʺrequiredʺ⁄〉
〈⁄extension〉
〈⁄simpleContent〉
〈⁄complexType〉
〈⁄element〉
〈⁄sequence〉
〈⁄complexType〉

〈simpleType name=ʺresultTypeʺ〉
〈restriction base=ʺNMTOKENʺ〉
〈enumeration value=ʺsuccessʺ⁄〉
〈enumeration value=ʺfailureʺ⁄〉
〈⁄restriction〉
〈⁄simpleType〉

〈simpleType name=ʺautoRenewTypeʺ〉
〈restriction base=ʺbooleanʺ〉
〈⁄restriction〉
〈⁄simpleType〉

〈⁄schema〉
END