EPP is a stateful XML protocol layered over TCP (see RFC 3734). While being protected using lower-layer security protocols, clients exchange identification, authentication, and other information, and engage in a series of client-initiated command-response exchanges.

Introduction

Introduction

EPP system
XML scheme
Version History

EPP System

All EPP commands are atomic (there is no partial success or partial failure) and designed so that they can be made idempotent (executing a command more than once has the same net effect on system state as successfully executing the command once). EPP provides four basic service elements: service discovery, commands, responses and an extension framework code that supports definition of managed objects and the relationship of protocol requests and responses related to those objects. EPP servers respond to client-initiated communication (which can be either a lower-layer connection request or an EPP service) by returning a greeting to a client. The server then responds to each EPP command with a coordinated response that describes the results of the command processing.

EPP commands fall into three categories: session management, queries and transform commands. Session management commands are used to establish and end persistent sessions with an EPP server. Query commands perform read-only object information retrieval operations. Transform commands perform read-write object management operations.

The server processes commands in the order they are received from a client. The protocol includes features that allow offline review of transform commands before the requested action is completed. In such situations, the response clearly notes that the command has been received, but the requested action is pending. The corresponding object then reflects processing of the pending action. The server will also notify the client when offline processing of the action has been completed. Object mappings describe standard formats for notices that describe completion of offline processing.

EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.

Extensible Provisioning Protocol (EPP) is based on the XML language. EPP describes a message format and performs various actions in the databases of domain registries, such as registration, renewal or a change of domain names.

The SYDORA system provides domain management using this EPP interface, i.e. an interface for automated communication based on EPP. This interface uses an RFC standard therefore it is especially vital to study the following, if possible:

Since the RFC standard is of a general character and as a rule, it is always adjusted to local applications, the SYDORA system also has its specifics. For more information please visit EPP commands.

XML scheme

Version-History

02/12/2016 – On-line version of the EPP documents

05/05/2017 – Upgrade to the new EPP version

09/05/2017 – New extension added Additional Contact Information

10/05/2017 – New section added Test Accounts

24/08/2017 – New version of XML schema added

01/09/2017 – Add EPP production address Production Operation

Basic EPP Management

The Basic EPP Management

Requirements
Operational Testing
Test Accounts
Production Operation

Requirements

The Study of Registry System EPP
The registry system provides domain management using an EPP interface, i.e. an interface for automated communication based on EPP. This interface uses an RFC standard; therefore, it is especially vital to study RFC 5730 and RFC 5734, if possible. Since the RFC standard is of a general character and as a rule, it is always adjusted to local applications, the registry system also has its specifics. The specifics can be found in the EPP documents of the registry system, available in a respective section of the SK-NIC website.

Implementation of a Client by a Registrar
A Registrar must properly implement its client using the EPP interface of the registry system. The EPP interface must be set pursuant to the EPP documents. It is up to the Registrar to perform the client implementation, following the needs of its systems.

Operational Testing

SK-NIC provides an Operational Testing and Evaluation (OT&E) environment to allow Registrars to develop and test their client applications. This system is identical to the production registry system but uses a separate database. Registrars are invited to use this system to test their client implementations, without fear of affecting the production registry system. Registrars can create multiple account credentials for use in the OT&E system via the Registrar Console.

Access to the OT&E EPP server is via TCP interface (secured by TLS) at epp.ote.sk-nic.sk, port 700, and is not restricted by IP address. There is also a version of the Registrar Console for the OT&E system at:
https://registrar-console.ote.sk-nic.sk/

An OT&E WHOIS service is also provided at whois.ote.sk-nic.sk, port 43.

Note

Registrars should test their knowledge of the following basic registrar activities:

  • Create, change data and change a Registrant of at least one Domain
  • Create and delete at least one extra Domain
  • Create at least one name server
  • Create and change data of at least one User (contact)
  • Create and change data of at least one extra User (contact)

Although SK-NIC will gradually check the success rate of various tests, however, successful completion of test is not a requirement for using EPP in the production operation.  It is strongly recommended that Registrars use fictitious data in a proper format and on a proper place so it is possible to detect possible incorrect filling of data fields. Once their login account into the production environment gets activated, all Registrars are granted immediate access to it.

Test Accounts

Every Registrar granted access to the Registrar Console has already granted their own test EPP account, where the EPP login (<clID>) is a Registrar’s ID and the password can be displayed or changed in the Registrar Console within Passwords section.

Production Operation

Access to the production EPP server is created via TCP connection (with TLS security) to the address epp.sk-nic.sk, using port 700. Registrar Console for production system is available at:
https://registrar-console.sk-nic.sk/

The Registrar has to enable its own IP addresses in Registrar Console: Settings -> Access list to receive full functionality of EPP within production operation.

Note

SK-NIC reserves the right to prohibit Registrars from using the EPP interface.

Basic EPP Information

Basic EPP Information

Supported Objects
Re-Registration of Purged Domains (“Drop Catching”)
XML Scheme Validation
Message Queue
Supported Commands

Supported Objects

Domains

It is possible to work with Domain Objects using standard commands, such as <create>, <info>, <update>, <delete>, <transfer>. In addition, it is also possible to add specific attributes listed below by means of the update command.

Adding and Removing of Specific Attributes

The following attributes may be added to or removed from Domain Objects by Registrars:

  • clientHold – a NS record will not be added to a Domain zone as long as this status is valid.
  • clientTransferProhibited – transfer requests for the Domain will be rejected automatically as long as this status is valid.
  • clientRenewProhibited – if this status is valid, all the authorized clients’ requests for the renewal of the Domain are rejected.
  • clientUpdateProhibited – if this status is valid, all the authorized clients’ transfer requests for the Domain are rejected (except cases where the request also contains the request of removal of such status from the Domain).
  • clientDeleteProhibited – if this status is valid, all the authorized clients’ requests for the removal of the Domain are rejected.
Users (Contacts)

The data about Contacts may be provided in ASCII coding or UTF-8 character encoding.

When creating EPP commands, Registrars has to provide all the data with correct diacritic marks.

It is necessary to bear in mind that the ID of Contact Objects does not distinguish between capital and small letters irrespective of whether it is a client or server ID. It means that it is not possible to create a Contact Object using abc-12345 identifier, if an object with ABC-12345 identifier already exists. If a request for the abc-12345 object is made, a reply containing the information on ABC-12345 is made.

A-Z, 0-9, _ and – are the only characters that can be used to create the ID of Contact.

It is convenient to create a system of identifiers which is not identical with other Registrars’ systems, e. g. a system based on the Registrar’s ID.

Execution of <info> Commands on Contact Objects

The EPP system will reject all <info> commands directed to contact objects for which you are not an Authorized Registrar unless you provide a valid authInfo code in the <contact: pw> element.

Name Server (host)

Registrars may change an IP address associated with a Name Server (Host) using the EPP command <host:update>.

The command also allows change of DNS name of a Name Server if these conditions are met:

  1. Registrars must not rename the Name Server (Host) which is subordinate to a Domain for which they are authorized. This concerns also “out-of-bailiwick” Name Servers.
  2. Registrars must not rename the Name Server in such a way that the Name Server becomes subordinate to a Domain of other sponsoring registrar.
  3. Registrars must not rename the Name Server in such a way that the Name Server becomes subordinate to a Domain which does not exist.
  4. Registrars may rename the Name Server which is not “out-of-bailiwick” anymore and which is not subordinate to any DNS zone of which SK-NIC is an authority. Registrars must keep in mind that in such case the information on the IP address of the Name Server like this will not be saved or published.

The changes in the names of DNS of the given Name Server will be applied in the NS Record of all the Domain Objects delegated to this Name Server. It means that it is possible that Domain Objects of other Authorized Registrars may be affected by renaming the Name Server this way: Therefore, Registrars should be very careful about how they use this option and they should consider adopting alternative solution (such as creation of new host object and transfer of the Domain).

Re-Registration of Purged Domains (“Drop Catching”)

“Drop Catching” is a process of re-registration of expired Domains shortly after they have been purged within the Domain life cycle.

Thanks to the competitive nature of a “Drop Catching” market, Registrars who offer the service like this have to often compete with other entities to acquire names of Domains by entering a huge volume of EPP commands.

In order to minimize impact of activities like that on operation and keep a shared registration system stable as well as to ensure the equal access for all Registrars, the following principles are applied.

  1. Every registrar account has number of concurrent connections to the EPP system limited to 20.
  2. If the EPP system accepts the domain command where the response code is 2302 (object exists), server waits to 1.000 milliseconds to pass before the actual response is send back (counted since the start if the command handling).
  3. Registrars who wish to carry out drop catching may use the information about the Domain to determine the approximate time when the Domain will be removed from the Database. The Registrar may then try to “catch” individual Domain while they are being removed.

In order to keep the registration system stable and ensure equal access for all Registrars, SK-NIC reserves the right to amend these principles at any time.

XML Scheme Validation

EPP validates all requests automatically based on the definition of XSD scheme located in a relevant part of this documentation (epp scheme). Upon acceptance of a non-validated request, an error message will be sent to the client as a reply.

Message Queue

EPP provides a message queue system to provide Registrars with notifications for exceptional events. Registrars can choose to enable or disable the use of the message queue via the account Settings page or the Registrar Console. The Registrar Console also provides access to the message queue.

Currently, SK-NIC supports the following EPP message:

Purging of a Domain with the status of “Pending Delete”. The example of this case is provided below.

Changing a Domain Status to pendingDelete

If the Domain is purged from the database, our system will search for the latest successful command in the EPP transaction log file for this Domain, typed by the actual authorized Registrar. If the relevant record is found in the log, this message will be added to the queue to confirm the Domain removal.

Example of the message is as follows:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   <response>
      <result code="1301">
         <msg>Command completed successfully; ack to dequeue</msg>
      </result>
      <msgQ count="5" id="12345">
         <qDate>2016-04-04T22:01:00.0Z</qDate>
         <msg>Pending action completed successfully.</msg>
      </msgQ>
      <resData>
         <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
            <domain:name paResult="1">example.sk</domain:name>
         <domain:paTRID>
               <clTRID>ABC-12345</clTRID>
               <svTRID>54321-XYZ</svTRID>
            </domain:paTRID>
            <domain:paDate>2016-04-04T22:00:00.0Z</domain:paDate>
			</domain:panData>
		</resData>
		<trID>
			<clTRID>BCD-23456</clTRID>
			<svTRID>65432-WXY</svTRID>
		</trID>
	</response>
</epp>

Note

Registrars may validate their commands in the Operational Testing and Evaluation Environment or they may use the EPP Validation Tool in the Registrar Console for this purpose.

Supported Commands

EPP Commands

EPP Commands

EPP Command: | <login> | <logout> | <hello> | <poll> | <check> | <create> | <delete> | <info> | <transfer> | <update> | <renew> |

EPP <login> Command

The <login> command is used to establish and validate a session with an EPP server. The command is identical with the RFC definition. A <login> command MUST be sent to a server before any other EPP command. Session with EPP server is terminated with a <logout> command. A <login> command consists of:

  • An <clID> element that contains Registrar‘s ID.
  • An <PW> element that contains Registrar’s password; The value of this element is case sensitive.
  • An optional <newPW> element that contains a new plain text to be assigned with subsequent sessions.
  • An <options> element that contains the following child elements:
    • An <version> element that identifies the protocol version to be used for the command or ongoing server session. Supported version is 1.0.
    • An <lang> element that defines the language version of text response to be used for the command or ongoing EPP server session.
  • A <svcs> element that contains:
    • one or more <objURI> elements that contain namespace URIs representing the objects to be managed during the session.

Supported objects are: domain, contact, Host.

  • an optional <svcExtension> element that contains one or more <extURI> elements that identify object extensions to be used during the session.
Example <login> command:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <login>
         <clID>ClientX</clID>
         <pw>foo-BAR2</pw>
         <newPW>bar-FOO2</newPW>
         <options>
           <version>1.0</version>
           <lang>en</lang>
         </options>
         <svcs>
            <objURI>urn:ietf:params:xml:ns:host-1.0</objURI>
            <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
            <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
           <svcExtension>
             <extURI>http://www.sk-nic.sk/xml/epp/sk-contact-ident-0.2</extURI>
           </svcExtension>
         </svcs>
       </login>
       <clTRID>ABC-12345</clTRID>
     </command>
   </epp>
Example <login> response:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

EPP <logout> Command

The <logout> command is identical with the RFC definition. The command <logout> is used to end a session with an EPP server. An EPP server will respond after receipt of this command and ends the session with client.

<logout> must be represented as an empty element with no child elements.

 

Example of <logout> command:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <logout/>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>
Example of <logout> response:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
  <response>
    <result code="1500">
      <msg>
        Command completed successfully; ending session
      </msg>
    </result>
    <trID>
      <svTRID>118073</svTRID>
    </trID>
  </response>
</epp>

EPP <hello> Command

The <hello> command is identical with the RFC definition. Command <hello> must be represented as an empty element with no child elements. EPP server reacts to <hello> command or successful EPP server session with client with <greeting> response. A <greeting> response consists of:

  • An <svID> element that containts the EPP server‘s name.
  • An <svDate> element that contains the server’s current date and time.
  • An <svcMenu> element that identifies the services supported by the EPP server:
    • An <version> element that identifies the protocol version supported by the EPP server. Currently supported version is 1.0. As there might be more versions supported in the future, this element might be multiplied.
    • One or more <lang> elements that contain the identifiers of the text response languages known by the server. Language value’s structure is defined according to the document [RFC 4646].
    • <objURI> elements that contain namespace URIs representing the objects that the server is capable of managing.
    • An optional <svcExtension> element
      • <extURI> elements that contain namespace URIs representing object extensions supported by the server.
Example of <hello> Command:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <hello/>
</epp>

An <greeting> answer is send in two cases – 1. after relation creation and 2. as a response to <hello> command.

Example of <greeting> response:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <greeting>
    <svID>Example EPP server epp.example.com</svID>
    <svDate>2000-06-08T22:00:00.0Z</svDate>
    <svcMenu>
      <version>1.0</version>
      <lang>en</lang>
      <lang>sk</lang>
      <objURI>urn:ietf:params:xml:ns:host-1.0</objURI>
      <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
      <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
      <svcExtension>
        <extURI>http://www.sk-nic.sk/xml/epp/sk-contact-ident-0.2</extURI>
      </svcExtension>
    </svcMenu>
   <dcp>
      <access><all/></access>
      <statement>
        <purpose><admin/><prov/></purpose>
         <recipient><ours/><public/></recipient>
        <retention><stated/></retention>
      </statement>
    </dcp>
  </greeting>
</epp>

EPP <poll> command

The EPP <poll> command is used to discover and retrieve service messages queued by a server.

Command <poll-op=“req”>

This command is used to retrieve the oldest queued message.

Example of <poll-op=“req”> command:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <poll op="req"/>
       <clTRID>ABC-12345</clTRID>
     </command>
   </epp>
Response example to this <poll-op=“req>:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <response>
       <result code="1301">
         <msg>Command completed successfully; ack to dequeue</msg>
       </result>
       <msgQ count="5" id="12345">
         <qDate>2000-06-08T22:00:00.0Z</qDate>
         <msg>Transfer requested.</msg>
       </msgQ>
       <resData>
         <obj:trnData
          xmlns:obj="urn:ietf:params:xml:ns:obj-1.0">
           <obj:name>example.com</obj:name>
           <obj:trStatus>pending</obj:trStatus>
           <obj:reID>ClientX</obj:reID>
           <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
           <obj:acID>ClientY</obj:acID>
           <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
           <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
         </obj:trnData>
       </resData>
       <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54321-XYZ</svTRID>
       </trID>
     </response>
</epp>

Command <poll-op=“ack”>

This command is used to confirm the receipt of the message and the message is removed from the queue afterwards.

Example of <poll-op=“ack”> command:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <poll op="ack" msgID="12345"/>
       <clTRID>ABC-12346</clTRID>
     </command>
</epp>
Response example to this <poll-op=“ack>:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <response>
       <result code="1000">
         <msg>Command completed successfully</msg>
       </result>
       <msgQ count="4" id="12345"/>
       <trID>
         <clTRID>ABC-12346</clTRID>
         <svTRID>54322-XYZ</svTRID>
      </trID>
     </response>
</epp>

EPP <check> command

The <check> command is identical with the RFC definition. Command <check> is used to determine if an object is available in the system.

<check> command for Domain:

The <check> command in this case is used to determine if the Domain is provided in the Registry, usually as an information if the Domain is available for registration. A <check> command must contain one or more <domain:name> elements in this case, containing fully qualified domain names to check (i.e. in the „name.sk“ structure). Domain as such doesn’t necessarily need to exist in the system, but it might still not be available for example due to blocking of the given string or due to the court decision.

Example of <check> for Domain:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <check>
      <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>test.sk</domain:name>
        <domain:name>next.sk</domain:name>
      </domain:check>
    </check>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

Description of response elements:

  • An <domain:cd> element contains response; individual element is provided for every Domain. It contains following child elements:
    • An <domain:name> element that identifies the queried Domain. This element contains “avail” attribute with value „1“ (true) or „0“ (false), where „1“ means that the Domain is free and is available for registration (it is not in the Registry) and „0“ means the Domain is not available for registration.
    • An <domain:reason> element that contains Domain status explanation why it can’t be provisioned. This element is created only in case of <domain:name> with „0“ “avail” value. Possible reasons of unavailability are:
      • In use – Domain is already registered.
      • Blocked – Domain name string is blocked, for example based on a court decision.
Response example to this <check>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <domain:chkData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:cd>
          <domain:name avail="1">next.sk</domain:name>
        </domain:cd>
        <domain:cd>
          <domain:name avail="0">test.sk</domain:name>
          <domain:reason>In use</domain:reason>
        </domain:cd>
      </domain:chkData>
    </resData>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

A <check> command for User (contact).

The <check> command in this case is used to determine if the User (contact) is provided in the Registry. It must contain one or more <contact:id> child elements with object User (contact) identifiers to be checked.

Example of <check> command for User (contact):
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <check>
      <contact:check xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>TEST-0001</contact:id>
        <contact:id>NEXT-0001</contact:id>
      </contact:check>
    </check>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

Description of response elements:

  • An <contact:cd> element contains response; individual element is provided for every User. It contains following child elements:
    • An <contact:id> element with ID of the queried User. This element contains “avail” attribute with value „1“ (true) or „0“ (false), where „1“ means that the User is not registered in the Registry and „0“ means that the User is registered.
    • An <contact:reason> element that contains User status explanation why it can’t be provisioned. This element is created only in case <contact:id> with „0“ “avail” value.
Response example to this <check>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <contact:chkData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:cd>
          <contact:id avail="1">NEXT-0001</contact:id>
        </contact:cd>
        <contact:cd>
          <contact:id avail="0">TEST-0001</contact:id>
          <contact:reason>In use</contact:reason>
        </contact:cd>
      </contact:chkData>
    </resData>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

A <check> command for nameserver (host).

  • An <host:name> element that contains names of nameserves to be checked.
Example of <check> command for nameserver (host):
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <check>
         <host:check
          xmlns:host="urn:ietf:params:xml:ns:host-1.0">
           <host:name>ns1.example.com</host:name>
           <host:name>ns2.example.com</host:name>
           <host:name>ns3.example.com</host:name>
         </host:check>
       </check>
       <clTRID>ABC-12345</clTRID>
     </command>
</epp>

Description of response elements:

  • An <host:cd> element contains response; individual element is provided for every nameserver (host). It contains following child elements:
    • An <host:name> element with the name of the queried nameserver (host). This element contains “avail” attribute with value „1“ (true) or „0“ (false), where „1“ means that the Host object is currently not registered in the Registry and „0“ means that the nameserver (host) is not registered and available.
    • An <contact:reason> element that contains nameserver (host) status explanation why it can’t be provisioned. This element is created only in case of <host:name> with „0“ “avail” value.
Response example to this <check>:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <response>
       <result code="1000">
         <msg>Command completed successfully</msg>
       </result>
       <resData>
         <host:chkData
          xmlns:host="urn:ietf:params:xml:ns:host-1.0">
           <host:cd>
             <host:name avail="1">ns1.example.com</host:name>
           </host:cd>
           <host:cd>
             <host:name avail="0">ns2.example2.com</host:name>
             <host:reason>In use</host:reason>
           </host:cd>
           <host:cd>
             <host:name avail="1">ns3.example3.com</host:name>
           </host:cd>
         </host:chkData>
       </resData>
       <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54322-XYZ</svTRID>
       </trID>
     </response>
</epp>

EPP <create> command

The <create> command allows creation of objects in the Registry.

A <create> command for Domain:

The <create> command allows creation i.e. registration of a new Domain. The <create> command consists of the following child elements:

  • An <domain:name> element that contains correct domain name string of the Domain to be created.
  • Voluntary <domain:period> element that sets created Domain‘s registration period. Available periods are 1 to 10 years. Default registration period is set to 1 year in case of non existence of this element .
  • An <domain:registrant> element that identifies the User that requested Domain registration (i,e. future Registrant).
  • An <domain:contact> element that identifies a contact to be associated with the Domain. It might be used multiple times.
  • An <domain:authInfo> element where authorisation password is set for the created Domain. This password might be asked for within some other actions related to this object.
  • Voluntary <domain:ns> element that contains names of the nameservers.
  • Voluntary <extension> element that contains mandatory <secDNS:create> child element with further voluntary <secDNS:maxSigLife> element and mandatory one or more <secDNS:dsData> elements. All four primary child elements of <secDNS:dsData> element – <secDNS:keyTag>, <secDNS:alg>, <secDNS:digestType> and <secDNS:digest> are to provided.

Note
If the domain is not going to be signed, the DNSSEC extension must be omitted. The schema does not permit empty values in the extension elements.

Note
<secDNS:maxSigLife> value is preserved, but it has no effect under SK-NIC’s setting.

Note
Subordinate key data elements <secDNS:keyData> to the <secDNS:dsData> might be provided, but as SK-NIC’s solution supports DS Data Interface, key data elements would be preserved but ignored.

Example of <create> command:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <create>
         <domain:create
          xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
           <domain:name>example.com</domain:name>
           <domain:period unit="y">2</domain:period>
           <domain:ns>
             <domain:hostObj>ns1.example.net</domain:hostObj>
             <domain:hostObj>ns2.example.net</domain:hostObj>
           </domain:ns>
           <domain:registrant>jd1234</domain:registrant>
           <domain:contact type="admin">sh8013</domain:contact>
           <domain:contact type="tech">sh8013</domain:contact>
           <domain:authInfo>
             <domain:pw>2fooBAR</domain:pw>
           </domain:authInfo>
         </domain:create>
       </create>
       <clTRID>ABC-12345</clTRID>
     </command>
</epp>
The same example with DNSSEC extension included:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <create>
         <domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
           <domain:name>example.com</domain:name>
           <domain:period unit="y">2</domain:period>
           <domain:ns>
             <domain:hostObj>ns1.example.net</domain:hostObj>
             <domain:hostObj>ns2.example.net</domain:hostObj>
           </domain:ns>
           <domain:registrant>jd1234</domain:registrant>
           <domain:contact type="admin">sh8013</domain:contact>
           <domain:contact type="tech">sh8013</domain:contact>
           <domain:authInfo>
             <domain:pw>2fooBAR</domain:pw>
           </domain:authInfo>
         </domain:create>
       </create>
       <extension>
         <secDNS:create xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
           <secDNS:maxSigLife>604800</secDNS:maxSigLife>
           <secDNS:dsData>
             <secDNS:keyTag>12345</secDNS:keyTag>
             <secDNS:alg>3</secDNS:alg>
             <secDNS:digestType>1</secDNS:digestType>
             <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
           </secDNS:dsData>
         </secDNS:create>
       </extension>
       <clTRID>ABC-12345</clTRID>
     </command>
</epp>

Description of the response elements:

  • An <domain:name> element with Domain to be paired with the response.
  • An <domain:crDate> element that contains confirmation date and time of the Domain registration (creation).
  • Voluntary <domain:exDate> element that contains date and time of the Domain expiration. SK-NIC’s registry system response always contains this date.
Response example to this <create>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <domain:creData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>test.sk</domain:name>
        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
        <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate>
      </domain:creData>
    </resData>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

A <create> command for User (contact):

The <create> command allows creation i.e. registration of an User (object contact creation). The <create> command consists of the following child elements that identify the created User:

  • An <contact:id> element that contains the User identifier.
  • An <contact:postalInfo> element that contains textual identification of the User and information about the address of User’s seat or residence (depending on the legal form). It contains following child elements:
    • An <contact: name> element that contains name and surname of the User. In case of legal person (“CORP” constant), company business name is provided.
    • Voluntary <contact:org> element that contains organization business name representing the User.
    • An <contact:addr> element that contains the information about the User’s address (address of residence of natural person and seat for legal person). It contains the following child elements:
      • An <contact:street> element that contains street name. The element might be used up to three times, voluntarily for the municipality part or other important parts of the address.
      • An <contact:city> element that contains city name.
      • Voluntary <contact:sp> element that contains region name, i.e. name of the province, county or lower-level state within federation type of country where such a structure is common. Slovak addresses do not use this element.
      • An <contact:pc> element that contains ZIP.
      • An <contact:cc> element that contains country code (based on ISO 3166-2).
  • Voluntary <contact:voice> element to provide primary phone number of the User. Phone number is provided with the country prefix, separated with dot character.
  • Voluntary <contact:fax> element to provide fax number of the User.
  • An <contact:email> element to provide primary e-mail address of the User.
  • An <contact:authInfo> element that sets authorisation password for the User to be created. This password might be required within other actions related to this object.
  • An optional <contact: disclose> element that is used to publish certain data that is not published by default. See the FAQ´s section for application examples.
  • An <extension> element to provide legal form of the User. Date of birth is entered for natural person (“PERS” constant) and official company business identifier is entered for legal person or self-employed enterpreneur (“CORP” constant). So called „ICO“ is provided for Slovak legal persons, equivalent from the relevant official registry is provided for foreign legal persons. Structure RRRR-MM-DD is used for date of birth (natural persons), for example 1987-01-01. Date of birth is not mandatory data, but it is highly recommended to be filled for easier User identification and mainly to prove the right to the Domain.

Note
It is expected that the date structure would be changed into Slovak form in the future.

Example of <create> command:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <contact:create xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>sh8013</contact:id>
        <contact:postalInfo type="int">
          <contact:name>John Doe</contact:name>
          <contact:org>Example Inc.</contact:org>
          <contact:addr>
            <contact:street>123 Example Dr.</contact:street>
            <contact:street>Suite 100</contact:street>
            <contact:city>Dulles</contact:city>
            <contact:sp>VA</contact:sp>
            <contact:pc>20166-6503</contact:pc>
            <contact:cc>US</contact:cc>
          </contact:addr>
        </contact:postalInfo>
        <contact:voice x="1234">+1.7035555555</contact:voice>
        <contact:fax>+1.7035555556</contact:fax>
        <contact:email></contact:email>
        <contact:authInfo>
          <contact:pw>2fooBAR</contact:pw>
        </contact:authInfo>
        <contact:disclose flag="0">
          <contact:voice />
          <contact:email />
        </contact:disclose>
      </contact:create>
    </create>
    <extension>
      <skContactIdent:create xmlns:skContactIdent="http://www.sk-nic.sk/xml/epp/sk-contact-ident-0.2">
        <skContactIdent:legalForm>CORP</skContactIdent:legalForm>
        <skContactIdent:identValue>
          <skContactIdent:corpIdent>1234567890</skContactIdent:corpIdent>
        </skContactIdent:identValue>
      </skContactIdent:create>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

Description of the response elements:

  • An <contact:id> element that contains relevant unique identifier of the User.
  • An <contact:crDate> element that contains confirmation date and time of the User registration (creation) in the Registry.
Response example to this <create>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <contact:creData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>sh8013</contact:id>
        <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>
      </contact:creData>
    </resData>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

A <create> command for nameserver (host):

The <create> command allows creation of a new nameserver (host). The <create> command must consist of the following child elements:

  • An <host:name> element that contains the name of the nameserver (host) to be created.
  • One or more <host:addr> that contain IP addresses aligned with the nameserver (host). More in RFC 5732 part 3.2.1.
Example of <create> command for nameserver:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <create>
         <host:create
          xmlns:host="urn:ietf:params:xml:ns:host-1.0">
           <host:name>ns1.example.com</host:name>
           <host:addr ip="v4">192.0.2.2</host:addr>
           <host:addr ip="v4">192.0.2.29</host:addr>
           <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
         </host:create>
       </create>
       <clTRID>ABC-12345</clTRID>
     </command>
</epp>
Response example to this <create>:

Description of the response elements:

  • An <host:name> element that contains name of the created nameserver (host).
  • An <host:crDate> element that contains date and time of the nameserver (host) creation.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <response>
       <result code="1000">
         <msg>Command completed successfully</msg>
       </result>
       <resData>
         <host:creData
          xmlns:host="urn:ietf:params:xml:ns:host-1.0">
           <host:name>ns1.example.com</host:name>
           <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
         </host:creData>
       </resData>
       <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54322-XYZ</svTRID>
       </trID>
     </response>
</epp>

EPP <delete> command

This command is used to remove an instance of an existing object, for example Domain, i.e. to end its registration period and discharge the relevant Domain Name Contract. The <delete> command must contain <domain:name> child element with Domain Name to be deleted identification.

It is not always possible to delete a Domain – some circumstance might prevent this action, for example if the Domain is blocked due to court decision.

Example of <delete> for Domain:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <delete>
      <domain:delete xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>test.sk</domain:name>
      </domain:delete>
    </delete>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>
Response example to this <delete>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   <response>
      <result code="1000">
         <msg>Command completed successfully</msg>
      </result>
      <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54321-XYZ</svTRID>
      </trID>
   </response>
</epp>

A <delete> command for the User (contact):

This command is used to delete the User from the Registry, i.e. end its record-keeping. The <delete> command must contain <contact:ID> child element with the correct allocated User ID of the User to be deleted.

Note
It is not possible to delete User associated with / allocated to another object!

Example of <delete> command for the User:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <delete>
      <contact:delete xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>TEST-0001</contact:id>
      </contact:delete>
    </delete>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>
Response example to this <delete>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   <response>
      <result code="1000">
         <msg>Command completed successfully</msg>
      </result>
      <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54321-XYZ</svTRID>
      </trID>
   </response>
</epp>

A <delete> command for nameserver (host):

This command is used to delete nameserver from the Registry, i.e. end its record-keeping. The <delete> command must contain <host:name> child element with name of the nameserver (host) to be deleted.

Note
It is not possible to delete nameserver (host) associated with / allocated to another object!

Example of <delete> for nameserver (host):
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <delete>
         <host:delete
          xmlns:host="urn:ietf:params:xml:ns:host-1.0">
           <host:name>ns1.example.com</host:name>
         </host:delete>
       </delete>
       <clTRID>ABC-12345</clTRID>
     </command>
</epp>
Response example to this <delete>:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <response>
       <result code="1000">
         <msg>Command completed successfully</msg>
       </result>
       <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54321-XYZ</svTRID>
       </trID>
     </response>
</epp>

EPP <info> Command

The <info> command is used to retrieve information associated with an existing object. The responses to this command might differ depending on the system client authorisation.

A <info> command for Domain:

The <info> command must contain <domain:info> and subsequent <domain:name> child element with the Domain name to be retrieved information about. The <info> command may also contain voluntary <domain:authInfo> element with authorisation password associated with the Domain.

Example <info> for Domain:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <info>
      <domain:info xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>test.sk</domain:name>
      </domain:info>
    </info>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

Description of the response elements:

  • An <domain:name> element that contains name of the Domain.
  • An <domain:roid> element that contains Repository Object Identifier that was assigned to the Domain when this object had been created.
  • Voluntary <domain:status> element that contains actual Domain status description.
  • Voluntary <domain:ns> element that contains name of the delegated nameservers (hosts) or their attributes associated with the Domain. More information is available in RFC 5731, section 1.1.
    • Voluntary <domain:host> child element that contains name of the subordinate nameserver (host).
  • An <domain:clID> element that contains identifier of the current Authorised Registrar of the Domain.
  • Voluntary <domain:crID> element that contains Registrar ID that originally registered (created) the Domain.
  • Voluntary <domain:crDate> element that contains date and time of the Domain current period registration (creation).
  • Voluntary <domain:upID> element that contains Registrar ID that last updated the Domain. This element is not provided in case the Domain has never been updated.
  • Voluntary <domain:upDate> element that contains date and time of the last Domain update. This element is not provided in case the Domain has never been updated.
  • Voluntary <domain:exDate> element that contains date and time of Domain expiration.
  • Voluntary <domain:trDate> element that contains date and time of the last successful transfer (change of Authorised Registrar of the Domain).
  • Voluntary <domain:authInfo> element that contains information if the Domain is protected by password.
  • Voluntary <secDNS:infData> child element contained under <extension> if the domain is DNSSEC protected, that can contain further
    • voluntary <secDNS:maxSigLife> child element and
    • one or more <secDNS:dsData> elements

Note
Voluntary element within response means that it will be provided in case it contains any value for the given element. Empty i.e. unfilled values are not provided. Example below contains also response for DNSSEC.

Response example to this <info>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
           <domain:name>example.com</domain:name>
           <domain:roid>EXAMPLE1-REP</domain:roid>
           <domain:status s="ok"/>
           <domain:registrant>jd1234</domain:registrant>
           <domain:contact type="admin">sh8013</domain:contact>
           <domain:contact type="tech">sh8013</domain:contact>
           <domain:ns>
             <domain:hostObj>ns1.example.com</domain:hostObj>
             <domain:hostObj>ns1.example.net</domain:hostObj>
           </domain:ns>
           <domain:host>ns1.example.com</domain:host>
           <domain:host>ns2.example.com</domain:host>
           <domain:clID>ClientX</domain:clID>
           <domain:crID>ClientY</domain:crID>
          <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
           <domain:upID>ClientX</domain:upID>
           <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
           <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
           <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
           <domain:authInfo>
             <domain:pw>2fooBAR</domain:pw>
           </domain:authInfo>
         </domain:infData>
    </resData>
    <extension>
         <secDNS:infData xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
           <secDNS:dsData>
             <secDNS:keyTag>12345</secDNS:keyTag>
             <secDNS:alg>3</secDNS:alg>
             <secDNS:digestType>1</secDNS:digestType>
             <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
           </secDNS:dsData>
         </secDNS:infData>
    </extension>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

A <info> command for User (contact):

The <info> command must contain <contact:info> child element with following subsiding child elements:

  • An <contact:ID> element that contains User identifier of the queried User.
  • Voluntary <contact:authInfo> element that contains authorisation password of the User (contact) object.
Example of <info> for the User:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <info>
         <contact:info
          xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
           <contact:id>sh8013</contact:id>
           <contact:authInfo>
             <contact:pw>2fooBAR</contact:pw>
           </contact:authInfo>
         </contact:info>
       </info>
       <clTRID>ABC-12345</clTRID>
     </command>
</epp>

Description of the response elements:

  • An <contact:id> element that contains the relevant User identifier.
  • An <contact:roid> element that contains Repository Object Identifier that was assigned to the User when this object had been created.
  • An <contact:status> element that provides details on the User status. This element is not supported in this system version.
  • An <contact:postalInfo> element that contains information about User address. It contains the following child elements:
    • An <contact:name> element including name and surname of the User. It may contain company business name or name of the person representing the company in case of legal person („CORP“ constant).
    • Voluntary <contact:org> element that contains company name that the User represents. It is filled in case of legal person and is not provided in case of natural person.
    • An <contact:addr> element that contains address information of the contact. This element contains the following child elements:
      • A <contact:street> element that contains street name. It may be used 3 times.
      • A <contact:city> element that contains city name.
      • Voluntary <contact:sp> element that contains region name (federation state, province etc.).
      • A <contact:pc> element that contains ZIP.
      • A <contact:cc> element that contains country code.
  • Voluntary <contact:voice> element that contains primary phone number of the User. Phone number is provided with the country prefix, separated with dot character.
  • Voluntary <contact:fax> element that contains fax number of the User.
  • An <contact:email> element to provide primary e-mail address of the User.
  • An <contact:clid> element that contains ID of the current Authorised registrar of the contact.
  • An <contact:crID> element that contains ID of the Registrar that originally registered (created) the User (contact).
  • An <contact:crDate> element that contains date and time of the User registration (creation).
  • Voluntary <contact:upID> element that contains ID of the Registrar that has made the last User update (data change).
  • Voluntary <contact:upDate> element that contains date and time of the last update (data change) of the User.
  • Voluntary < contact:trDate > element that contains date and time of the last successful transfer (change of Authorised Registrar of the Contact).
  • Voluntary < contact:authinfo > element that contains information if the User is protected by password.
  • Voluntary <contact:disclose> element that contains child elements to disclosed to third parties. See section FAQ´s.
Response example to this <info>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <contact:infData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>sh8013</contact:id>
        <contact:roid>SH8013-REP</contact:roid>
        <contact:ident legalForm="PO">1234567890</contact:ident>
        <contact:status s="linked"/>
        <contact:status s="clientDeleteProhibited"/>
        <contact:postalInfo>
          <contact:name>John Doe</contact:name>
          <contact:org>Example Inc.</contact:org>
          <contact:addr>
            <contact:street>123 Example Dr.</contact:street>
            <contact:street>Suite 100</contact:street>
            <contact:city>Dulles</contact:city>
            <contact:sp>VA</contact:sp>
            <contact:pc>20166-6503</contact:pc>
            <contact:cc>US</contact:cc>
          </contact:addr>
        </contact:postalInfo>
        <contact:voice>+421.7035555555</contact:voice>
        <contact:fax>+421.7035555556</contact:fax>
        <contact:email></contact:email>
        <contact:clID>ClientY</contact:clID>
        <contact:crID>ClientX</contact:crID>
        <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>
        <contact:upID>ClientX</contact:upID>
        <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
        <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate>
        <contact:authInfo>2fooBAR</contact:authInfo>
        <contact:disclose flag="0">
          <contact:voice/>
          <contact:email/>
        </contact:disclose>
      </contact:infData>
    </resData>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

A <info> command for nameserver (host):

The <info> command must contain <host:info> and subsequent <host:name> child element with the nameserver (host) to be retrieved information about.

Example of <info> for the nameserver (host):
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <info>
         <host:info
          xmlns:host="urn:ietf:params:xml:ns:host-1.0">
           <host:name>ns1.example.com</host:name>
         </host:info>
       </info>
       <clTRID>ABC-12345</clTRID>
     </command>
</epp>

Description of the response elements:

  • An <host:name> element that contains name of the queried nameserver (host).
  • An <host:roid> element that contains Repository Object Identifier that was assigned to the nameserver (host) when this object had been created.
  • An <host:status> element that contains actual nameserver (host) status description.
  • An <host:addr> element that contains IP addresses of the nameserver (host).
  • An <host:clID> element that contains ID of the current Registrar of the nameserver (host) object.
  • An <host:crID> element that contains ID of the Registrar that originally cretaed the object.
  • An <host:crDate> element that contains date and time of the nameserver (host) creation.
  • Voluntary <host:upID> element that contains ID of the Registrar that has made the last nameserver update
  • Voluntary <host:upDate> element that contains date and time of the last nameserver (host) update.
  • Voluntary <host:trDate> element that contains date and time of the transfer of the nameserver (host).
Response example to this <info>:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <response>
       <result code="1000">
         <msg>Command completed successfully</msg>
       </result>
       <resData>
         <host:infData
          xmlns:host="urn:ietf:params:xml:ns:host-1.0">
           <host:name>ns1.example.com</host:name>
           <host:roid>NS1_EXAMPLE1-REP</host:roid>
           <host:status s="linked"/>
           <host:status s="clientUpdateProhibited"/>
           <host:addr ip="v4">192.0.2.2</host:addr>
           <host:addr ip="v4">192.0.2.29</host:addr>
           <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
           <host:clID>ClientY</host:clID>
           <host:crID>ClientX</host:crID>
           <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
           <host:upID>ClientX</host:upID>
           <host:upDate>1999-12-03T09:00:00.0Z</host:upDate>
           <host:trDate>2000-04-08T09:00:00.0Z</host:trDate>
         </host:infData>
       </resData>
       <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54322-XYZ</svTRID>
       </trID>
     </response>
</epp>

EPP <transfer> Command

The <transfer> command is used to send request to change (transfer) Authorised registrar of an object. Current system version allows Domain transfer only.

Note
Every EPP <transfer> command must include “op” attribute that identifies the transfer operation to be done.

List of supported operations:
  • <transfer op=“request”>
  • <transfer op=“cancel”>
  • <transfer op=“approve”>
  • <transfer op=“reject”>

Authorised Registrar of the Domain aligned with the chosen Domain is changed within this operation. Authorisation password of the Domain has to be correctly provided within the request and the Domain can have neither clientTransferProhibited! nor serverTransferProhibited.

Domain transfer is executed instantly.

  • <transfer op=“cancel”> (Request cancellation)

Domain in the tranfer status „pending“ can have the transfer request cancelled by the Registrar that iniciated it.

  • <transfer op=“approve”> (Request approval)

Upon its own decision, the current Domain Registrar can approve the transfer request before the date/time of the transfer.

  • <transfer op=“reject”>

The current Domain Registrar can reject the Domain transfer request.

A <transfer> command for Domain

The <transfer> command must contain <domain:transfer> in this case with the following child elements:

  • A <domain:name> element that contains Domain name of Domain where Authorised registrar should be changed.
  • Voluntary <domain:period> element that sets the length of the chosen Domain registration period. Length should be from 1 to 10 years.
  • A <domain:authInfo> element that must contain correct Domain authorisation password.

Note
Don’t forget to change contacts aligned to the Domain after transfer otherwise it won’t be possible to make some actions related to the Domain.

Example of <transfer op=“request> for Domain:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <transfer op="request">
      <domain:transfer xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>test.sk</domain:name>
        <domain:period unit="y">1</domain:period>
        <domain:authInfo>
          <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
        </domain:authInfo>
      </domain:transfer>
    </transfer>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>
Response example to this <transfer>:
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1001">
      <msg>Command completed successfully; action pending</msg>
    </result>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

EPP <update> command

A <update> command for Domain:

The <update> allows to change i.e. update object data, Domain object in this case. The <update> command must contain <domain:update> child element with following subsiding child elements:

  • An <domain:name> element that contains name of the Domain whose data should be changed.
  • Voluntary <domain:add> element that contains data to be added to the Domain:
    • Voluntary <domain:ns> element that contains name of the delegated nameservers (hosts) or its attributes associated with the Domains. More information is available in RFC 5731, section 1.1.
    • An <domain:contact> element that identifies contact to be associated with the Domain. It might be used multiple times.
    • An <domain:status> element that contains status to be associated with the Domain.
  • Voluntary <domain:rem> element that contains data to be removed from the Domain:
    • Voluntary <domain:ns> element that contains contains name of the delegated nameservers (hosts) or its attributes associated with the Domains. More information is available in RFC 5731, section 1.1.
    • An <domain:contact> element that identifies contact to be removed. It might be used multiple times.
    • An <domain:status> element that contains status to be removed.
  • Voluntary <domain:chg> element that contains child elements with values that are to be changed for the given Domain:
    • An <domain:registrant> element that contains identifier of the new Domain Registrant. This is actually change from the old Registrant to a new one.
    • An <domain:authInfo> element that contains new authorisation information (password) associated with the Domain, replacing the old one after succcessful command.
    • Voluntary <extension> element that contains
      • Voluntary <secDNS:update> element with further
        • Voluntary <secDNS:rem> element that contains
  • – either voluntary <secDNS:all> element to remove all DS and key data if it contains boolean value true. A value of boolean false will do nothing.- or an <secDNS:dsData> element to remove a unique DS record by using all four elements – <secDNS:keyTag>, <secDNS:alg>, <secDNS:digestType> and <secDNS:digest>.
  • Voluntary <secDNS:add> element to add additional DNSSEC information to the existing one that contains at least one <secDNS:dsData> child element with all four subsidiary elements <secDNS:keyTag>, <secDNS:alg>, <secDNS:digestType> and <secDNS:digest>.
  • Voluntary <secDNS:chg> element to change existing DNSSEC information that contains voluntary <secDNS:maxSigLife> element that indicates a child’s preference for the number of seconds after signature generation when the parent’s signature on the DS information provided by the child will expire. Under SK-NIC’s setting this element can be changed, but it has no effect.

Note
If the domain is not signed, the DNSSEC extension must be omitted. The schema does not permit empty values in the extension elements.

Note

The XML schema forbids mixing <secDNS:all/> and <secDNS:dsData> elements.

Removing all DS information via <secDNS:rem> and <secDNS:all> can remove the ability of the parent to secure the delegation to the child zone.

Note
Subordinate key data elements <secDNS:keyData> to the <secDNS:dsData> might be provided, but as SK-NIC’s solution supports DS Data Interface, key data elements would be preserved but ignored.

Note
Specific settings such as “clientUpdateProhibited” can only be added to a domain using the <update> command.

The <update> command can be also used to set specific flags described in the Basic EPP Information – Adding and Removing of Specific Attributes. Example below contains also voluntary DNSSEC extension.

Example of <update> for Domain:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <update>
      <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>test.sk</domain:name>
        <domain:add>
             <domain:ns>
              <domain:hostObj>ns2.example.com</domain:hostObj>
             </domain:ns>
             <domain:contact type="tech">mak21</domain:contact>
             <domain:status s="clientHold"
              lang="en">Payment overdue.</domain:status>
           </domain:add>
           <domain:rem>
             <domain:ns>
               <domain:hostObj>ns1.example.com</domain:hostObj>
             </domain:ns>
             <domain:contact type="tech">sh8013</domain:contact>
             <domain:status s="clientUpdateProhibited"/>
           </domain:rem>
           <domain:chg>
             <domain:registrant>sh8013</domain:registrant>
             <domain:authInfo>
               <domain:pw>2BARfoo</domain:pw>
             </domain:authInfo>
           </domain:chg>
      </domain:update>
    </update>
    <extension>
         <secDNS:update xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
           <secDNS:rem>
             <secDNS:dsData>
               <secDNS:keyTag>12345</secDNS:keyTag>
               <secDNS:alg>3</secDNS:alg>
               <secDNS:digestType>1</secDNS:digestType>
               <secDNS:digest>38EC35D5B3A34B33C9B</secDNS:digest>
             </secDNS:dsData>
           </secDNS:rem>
           <secDNS:add>
             <secDNS:dsData>
               <secDNS:keyTag>12346</secDNS:keyTag>
               <secDNS:alg>3</secDNS:alg>
               <secDNS:digestType>1</secDNS:digestType>
               <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
             </secDNS:dsData>
           </secDNS:add>
           <secDNS:chg>
             <secDNS:maxSigLife>605900</secDNS:maxSigLife>
           </secDNS:chg>
         </secDNS:update>
       </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>
Response example to this <update>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   <response>
      <result code="1000">
         <msg>Command completed successfully</msg>
      </result>
      <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54321-XYZ</svTRID>
      </trID>
   </response>
</epp>

A <update> command for User (contact):

The command must contain <contact:update> in this case with the following child elements:

  • An <contact:id> element that contains the relevant User identifier, data of which are to be changed.
  • An <contact:add> element that contains data to be added to the User:
    • An <contact:status> element that contains status to be associated with the User. This element is not supported within the current system version.
  • An <contact:rem> element that contains data to be removed from the User object:
    • An <contact:status> element that contains status to be removed. This element is not supported within the current system version.
  • An <contact:chg> element that contains child elements with values that are to replace those existing within the given User object:
    • An <contact:postalInfo> element that contains information about User address, while this element contains following child elements:
      • An <contact:name> element with new User name.
      • Voluntary <contact:org> element with new name of the legal person under which the User belongs. This element is not to be filled for natural persons.
        • An <contact:addr> element that contains information about the contact address. The elements contains another level of the following child elements:
          • An <contact:street> element with new street name.
          • An <contact:city> element with new city name.
          • Voluntary <contact:sp> element with new name of the region (for example state in the federative type of the country or province name).
          • An <contact:pc> element with new postal number (ZIP).
          • An <contact:cc> element with new country code.
  • Voluntary <contact:voice> element with new primary phone number of the User.
  • Voluntary <contact:fax> element with new fax number of the User.
  • Voluntary <contact:email> element with new primary e-mail address of the User.
  • Voluntary <contact:authInfo> element with new authorisation password for the User.
  • Voluntary <contact:disclose> element with new data for publication to third parties.
Example of <update> command for the User:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <update>
         <contact:update
          xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
           <contact:id>sh8013</contact:id>
           <contact:add>
             <contact:status s="clientDeleteProhibited"/>
           </contact:add>
           <contact:chg>
             <contact:postalInfo type="int">
               <contact:org/>
               <contact:addr>
                 <contact:street>124 Example Dr.</contact:street>
                 <contact:street>Suite 200</contact:street>
                 <contact:city>Dulles</contact:city>
                 <contact:sp>VA</contact:sp>
                 <contact:pc>20166-6503</contact:pc>
                 <contact:cc>US</contact:cc>
               </contact:addr>
             </contact:postalInfo>
             <contact:voice>+1.7034444444</contact:voice>
             <contact:fax/>
             <contact:authInfo>
               <contact:pw>2fooBAR</contact:pw>
             </contact:authInfo>
             <contact:disclose flag="1">
               <contact:voice/>
               <contact:email/>
             </contact:disclose>
           </contact:chg>
         </contact:update>
       </update>
       <clTRID>ABC-12345</clTRID>
     </command>
   </epp>
Response example to this <update>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   <response>
      <result code="1000">
         <msg>Command completed successfully</msg>
      </result>
      <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54321-XYZ</svTRID>
      </trID>
   </response>
</epp>

An <update> command for nameserver (host):

The command must contain <host:update> in this case with the following child elements:

  • An <host:name> element that contains name of the nameserver (host), data of which are to be changed.
  • An <host:add> element that contains data to added to the nameserver (host):
    • An <host:status> element that contains status to be associated with the nameserver (host).
    • An <host:addr> element that contains one or more IP addresses to be added to the nameserver (host).
  • An <host:rem> element that contains data to be removed from the nameserver (host):
    • An <host:status> element that contains status to be removed from the nameserver (host).
    • An <host:addr> element that contains one or more IP addresses to be removed from the nameserver (host).
  • An <host:chg> element that contains child elements with values that are to replace those existing within the given nameserver (host):
    • An <host:name> element that contains new name that should replace the existing one for the given nameserver (host).
Example of <update> command for nameserver (host):
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
     <command>
       <update>
         <host:update
          xmlns:host="urn:ietf:params:xml:ns:host-1.0">
           <host:name>ns1.example.com</host:name>
           <host:add>
             <host:addr ip="v4">192.0.2.22</host:addr>
             <host:status s="clientUpdateProhibited"/>
           </host:add>
           <host:rem>
             <host:addr ip="v6">1080:0:0:0:8:800:200417A</host:addr>
           </host:rem>
           <host:chg>
             <host:name>ns2.example.com</host:name>
           </host:chg>
         </host:update>
       </update>
       <clTRID>ABC-12345</clTRID>
     </command>
</epp>

EPP <renew> command

An <renew> command for Domain:

The <renew> command allows renewal of the Domain registration period. The <renew> must contain <domain:renew> child element and that one subsequent child elements:

  • An <domain:name> element with the name of the Domain to be renewed.
  • An <domain:curExpDate> element with the current Domain expiration date. This value ensures that repeated <renew> commands will not create multiple unexpected successful renewals.
  • Voluntary <domian:period> element that contains length of the period the Domain should be renewed for. It might range from 1 to 10 years. In case this element will not have any value, default renewal value would be 1 year.
Example of <renew> command:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <renew>
      <domain:renew xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>test.sk</domain:name>
        <domain:curExpDate>2000-04-03</domain:curExpDate>
        <domain:period unit="y">5</domain:period>
      </domain:renew>
    </renew>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>
Response example to <renew>:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <domain:renData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>test.sk</domain:name>
        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
      </domain:renData>
    </resData>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

Additional Information

Additional Information

Session Limits and Transaction Volumes
Effect on Pipelining
Session Timeouts
Transaction Logging and Reporting
Return Codes and Messages

Session Limits and Transaction Volumes

During normal operations, Registrars may maintain up to 20 concurrent sessions to the EPP system. Command throughput is not throttled, meaning that the server will respond to commands immediately (once the command has been processed and the response has been prepared).

As an exception to the above, every domain <create> command resulting in a 2302 “object exists” error after the first one will be subject to a 2 seconds response delay. This policy serves to mitigate the operational impact of “dropcatching” activity on the registry system.

Note
These limits may be subject to gradual revision which shall be communicated.

Effect on Pipelining

Registrars can obtain a modest enhancement on performance by means of pipelining (see RFC 5734, Section 3). During critical service periods, the restrictions described above shall be in force. Due to this way of command handling, commands that are pipelined by a client will be buffered in the client’s queue of sent commands, and will be processed by the server (in the order of their receipt) within conditions described above.

This means that if the maximum throughput shall be 5 commands per second, 200 <create> commands send by Registrar in a single batch will result in the minimum time 200 / 5 = 40 seconds required to execute all 200 commands.

Note
Registrars should avoid pipelining too many commands to not cause session idle timeout limit (described below). If this occurs, connection will be dropped and any unprocessed commands will be discarded.

Session Timeouts

The system will terminate an idle session if no command has been received within 300 seconds. Registrars may use the <hello> command to maintain connection longer. Note that it is recommended to avoid reaching the limit (see above).

Transaction Logging and Reporting

All „transform“ commands are logged. Transform commands are: <create>, <renew>, <update>, <delete> and <transfer>. The system logs the time and date when the command was received by the Registrar that submitted it, the request and its code record, the resulting code and message. All commands, whether successful or not, are written into a log file.

Registrars have access to the log file of their account via the Registrar Console. The log viewer permits filtering by command, object type, object ID (Domain, host name, contact ID), resulting code and timestamp.

Query commands (<check>, <info>, <poll op=“req“>) and session commands (<login>, <logout> and <hello>) are not logged due to the large volume of such queries (particularly <check> queries).

Return Codes and Messages

General Return Codes

FAQ

FAQ

How and where to add a new shipping address for Contact via EPP?
I am not able to login into EPP. What should I do?
Examples of data hiding (disclose) for Contacts via EPP

How and where to add a new shipping address for Contact via EPP?

If the Contact has a delivery address different than his primary address, it is nessesary to create a new Contact via <create> command. This newly created Contact assign you to the Domain via the extension Additional contact information, in which you indicate type=“delivery adress” and as a value you enter a newly created Contact ID.

Extension example:
<extension>
       <auxcontact:create
         xmlns:auxcontact="urn:ietf:params:xml:ns:auxcontact-0.1">
         <auxcontact:contact type="delivery adress">
            exemple</auxcontact:contact>
       </auxcontact:create>
</extension>

I am not able to login into EPP. What should I do?

For a Registrar to use EPP, it must allow its IP addresses in the Registrar Console: Settings -> Access list.

Examples of data hiding (disclose) for Contacts via EPP

System accepts only flag 0 value within disclose, value 1 is not handled.

Data hiding
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <update>
      <contact:update xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>sh8013</contact:id>
        <contact:chg>
          <contact:disclose flag="0">
            <contact:voice />
            <contact:fax />
            <contact:email />
          </contact:disclose>
        </contact:chg>
      </contact:update>
    </update>
    <clTRID>FtLz1RUA2uwL</clTRID>
  </command>
</epp>
Data visibility
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <update>
      <contact:update xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>PETE-0017</contact:id>
        <contact:chg>
          <contact:disclose flag="0" />
        </contact:chg>
      </contact:update>
    </update>
    <clTRID>xdMhrawHXzrI</clTRID>
  </command>
</epp>

Extensions

Extensions

EPP system of SK-NIC supports several extensions. Their list is provided below.

Command to receive info on Domain
Command to restore Domain
Command related to DNSSEC
Command for person identification
Additional contact information

Command to receive info on Domain

If the domain is in status “PendingDelete: Redemption Grace Period“, EPP response code to <info> command is extended with the special description of this status.

Response example is provided below.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   <response>
      <result code="1000">
         <msg>Command completed successfully</msg>
      </result>
      <resData>
         <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
            <domain:name>example.sk</domain:name>
         </domain:infData>
      </resData>
      <extension>
         <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0">
            <rgp:rgpStatus s="redemptionPeriod" />
         </rgp:infData>
      </extension>
		<trID>
			<clTRID>ABC-12345</clTRID>
			<svTRID>54322-XYZ</svTRID>
		</trID>
	</response>
</epp>

Command to restore Domain

If the domain is in status “PendingDelete: Redemption Grace Period“, it might be restored with extended command <update> besides the typical renewal <renew>.

An example is provided below.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
         <command>
      <update>
         <domain:update	xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
            <domain:name>example.sk</domain:name>
            <domain:chg />
         </domain:update>
      </update>
      <extension>
         <rgp:update xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0">
            <rgp:restore op="request" />
         </rgp:update>
      </extension>
      <clTRID>ABC-12345</clTRID>
   </command>
</epp>

SK-NIC actually doesn’t require from Registrars to send “restore message“ as a part of the restore.

The extension on DNSSEC is being supported, following RFC 5910 and RFC 4034.

This extension adds additional elements to the EPP domain name mapping.

 

Delegation Signer (DS) information is published by a DNS server to indicate that a child zone is digitally signed and that the parent zone recognizes the indicated key as a valid zone key for the child zone.

 

A DS resource record (RR) contains four fields: a key tag field, a key algorithm number octet, an octet identifying a digest algorithm, and a digest field.

 

Public key information provided by a client maps to the DNSKEY RR presentation field formats described in RFC 4034 section 2.2. A DNSKEY RR contains four fields: flags, a protocol octet, an algorithm number octet, and a public key.

Maximum signature lifetime (maxSigLife) is an OPTIONAL child preference for the number of seconds after signature generation when the parent’s signature on the DS information provided by the child will expire. The maxSigLife value applies to the RRSIG resource record (RR) over the DS RRset.

 

SK-NIC’s server supports DS Data Interface.

Note
Individual usages within EPP commands are described under the given commands.

<extension>
   <secDNS:create xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
      <secDNS:maxSigLife>604800</secDNS:maxSigLife>
      <secDNS:dsData>
         <secDNS:keyTag>12345</secDNS:keyTag>
         <secDNS:alg>3</secDNS:alg>
         <secDNS:digestType>1</secDNS:digestType>
         <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
      </secDNS:dsData>
   </secDNS:create>
</extension>

Command for person identification

This extension purpose is to discern legal type of the person, mainly due to personal data protection requirements. Date of birth is provided for natural person (“PERS” constant), while company identification number is provided for legal person or self-employed entrepreneur (“CORP” constant). IČO is used for Slovak legal persons, foreign legal persons should have business number from the relevant official register. Date of birth for natural persons is provided in the YYYY-MM-DD structure, for example 1987-01-01. Date of birth is not a mandatory data, however, to better identify the user and even more claim its right to the Domain we strongly recommend to fill this data.

Note
It is expected that the date structure should be changed to the one use in Slovak environment in the future.

Extension example: Corporation
<extension>
      <skContactIdent:create
        xmlns:skContactIdent="http://www.sk-nic.sk/xml/epp/sk-contact-ident-0.2">
      <skContactIdent:legalForm>CORP</skContactIdent:legalForm>
      <skContactIdent:identValue>
        <skContactIdent:corpIdent>1234567890</skContactIdent:corpIdent>
      </skContactIdent:identValue>
      </skContactIdent:create>
</extension>
Extension example: Natural person
<extension>
      <skContactIdent:create
        xmlns:skContactIdent="http://www.sk-nic.sk/xml/epp/sk-contact-ident-0.2">
      <skContactIdent:legalForm>PERS</skContactIdent:legalForm>
      </skContactIdent:create>
</extension>

More information in EPP commands <create>

Additional contact information

This extension provides additional contact information about an object. Its main purpose is to add functional delivery address fulfilling requirements according to the Terms and Conditions for contacts where this is missing. The whole documentation on this extension is available at epp-auxcontact-extension.

Annexes

Annexes

RFC documents
Other documents

RFC documents

Other Documents