Back

25 Extensible Provisioning Protocol (EPP)

gTLDFull Legal NameE-mail suffixDetail
.barcelonaMunicipi de Barcelonajosoc.catView
Q25 - Extensible Provisioning Protocol (EPP)


1. Experience

The EPP interface for registrars of the .barcelona Registry is based on COREʹs EPP implementation, which has been used for several registries.

Since 2006, CORE handles the backend registry operation for puntCAT (responsible for the .cat top-level domain). Right from the start, COREʹs .cat Shared Registration System (SRS) offered an EPP frontend fully compliant with RFCs 3730-3734 (updated to compliance with 5730-5734 in the meantime), using various EPP extensions to cope with puntCATʹs special requirements. The SRS also fully supports the provisioning of DNSSEC data in accordance with RFC 5910; for backward compatibility, the previous DNSSEC EPP extension (RFC 4310) is also supported.

In addition, based on the same technology, CORE Internet Council of Registrars is currently in the process of taking over back-end operations for a country code top-level domain managing between 200,000 and 500,000 domain names. The details of this cooperation cannot be disclosed at the time of writing. While this registryʹs DNS services have already been transitioned to CORE at this point, the migration of SRS and Whois operations are currently being finalised.

CORE Internet Council of Registrars provides the unified CORE Registration System for its members since 1997. This system grants access to a multitude of top-level domain registries, currently including .com, .net, .org, .info, .biz, .name (with support for domain name and e-mail forwarding addresses), .us, .asia, .cn, .tw, .eu, .mobi, .aero, .me, .tel, .coop, .ch and .li domains, via a single entry point. CORE members can access all supported registries using a single, unified protocol. The CORE Registration System maps the commands issued by the user to the corresponding EPP commands, sends them to the appropriate registry server and translates back the received results. Members do not need to cope with problems regarding registry communication (like different flavours of EPP, SSL⁄TLS certificate handling or Punycode conversion for internationalised domain names) themselves.

Since the CORE Registration System acts as a client regarding all the supported registries, its implementation also allowed CORE Internet Council of Registrars to gain considerable experience concerning all client side aspects of (different versions of) EPP. In particular, client-side EPP support had already started with the introduction of EPP by Afilias and Neulevel. On the server side, EPP has been in use since starting the operation of the puntCAT registry some five years ago. At the heart of the EPP implementation lies the so-called Unikit, COREʹs EPP toolkit implementation. The Unikit includes code for the client side and for the server side. In the context of the .barcelona Registry, the server-side part of the Unikit will be used.

In the person of Klaus Malorny, CORE also actively participated in the IETF Provisioning Registry Protocol (provreg) working group and contributed to some RFCs (see Acknowledgements in RFCs 5730-5733 and RFC 5910).

The software implementing the actual shared registry system, including its EPP interface, was entirely built by CORE, involving an international team of developers from several member companies — thus demonstrating the software development skills at COREʹs disposal.


2. Standards Compliance

The EPP interface of the .barcelona Registry, provided by the CORE Registration System, is fully compliant with RFCs 5730-5734. These define mappings for the provisioning and management of Internet domain names, Internet host names and individual or organisational social information identifiers (ʺcontactsʺ) stored in a shared central repository.

Apart from these standards, the .barcelona Registry also supports the proposed standard for DNSSEC (RFC 5910). This is an EPP extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository.

The proposed standard for an EPP extension for ʺgrace periodʺ policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN) is fully supported also (RFC 3915). Such grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed.

Furthermore, a few proprietary EPP extensions are used by the .barcelona Registry to allow registrars to provide trademark information during the Sunrise phase, auction information during Sunrise and Landrush phases as well as language information. Documentation consistent with RFC 3735 for these proprietary EPP extensions can be found below.

All incoming requests will be validated against the schema definitions in the relevant RFCs and the ones of the proprietary EPP extensions, if applicable. This adds to security and stability, as invalid requests are dismissed early on. The EPP implementation of the .barcelona Registry is compatible with existing toolkits that produce valid EPP requests.

Pending, asynchronous operations are fully supported by the registry implementation. The SRS returns an EPP result code of 1000 if a command has succeeded synchronously, i.e. immediately. In contrast, a result code of 1001 is returned if a command was accepted but requires asynchronous processing before it can be completed.


3. Stability

A stable EPP interface is very important for smooth operation of a shared registry system. To ensure this, the CORE Registration System contains a multi-threaded, asynchronous communication implementation allowing a high number of concurrent EPP connections.

The incoming requests are filtered by their IP addresses via firewall rules in order to disallow access from unauthorised sites. This increases not only the security of the system, but also its stability, since the load on the EPP servers is reduced.


4. Equal opportunity

EPP access limitations for registrars are enforced by the CORE Registration System, allowing a certain number of concurrent connections only. This further enhances the stability of the system and is an important ingredient for equal opportunity as well. Registrars cannot effectively hinder their competitors from connecting by simply opening a great many connections themselves.

For the sake of equal opportunity, the .barcelona Registry also avoids first-come, first-served (FCFS) policies where possible. This is why the general availability (GA) phase is the only one using this principle. All popular domain names will probably have been registered already when GA starts (during previously conducted launch phases not using FCFS), so FCFS during GA does not contradict the idea of equal opportunity.


5. Proprietary Extensions

CORE Internet Council of Registrars has already shown its ability to design, specify and implement proprietary EPP extensions in the context of the puntCAT registry. There, extensions exist for the specification of promotion codes, sponsor e-mail addresses, application objects (used during the Sunrise phase) and poll messages to notify registrars about application outcomes, for example. In the following, the proprietary EPP extensions planned to be used for .barcelona are described.


5.1 Extension for Trademark Information during Launch Phases

The CORE Registration System used to operate the .barcelona Registry provides a proprietary EPP extension for submitting special data needed during launch phases.


5.1.1 Introduction

This part of this answer describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730. This mapping is an extension of the domain name mapping described in RFC 5731. It is specified using the Extensible Markup Language (XML) and XML Schema notation.

This extension serves the purpose of supplying and querying information for special phases, usually at the beginning of registry operation. A typical use case is a ʺSunriseʺ phase during which trademark holders have a prerogative to register a domain name related to their trademark. In particular, this extension allows the provisioning of trademark information and the querying of the current status of a domain name application.

In addition, the extension allows the specification of additional information about the application, such as the intended use for the domain name, a URL demonstrating prior use of similar names in other TLDs etc.; the registryʹs Sunrise policy determines whether and how this information is utilised.

An extension to the ʺpollʺ command is not included. Registrars are notified of application results via the poll message mechanism already included in EPP.

This extension has been developed along the lines of the Internet draft by Tan and Brown (see http:⁄⁄tools.ietf.org⁄html⁄draft-tan-epp-launchphase-01). Even though that document is currently only a draft, it serves the purpose needed for the .barcelona Registry and is clearly a step forward regarding the standardisation of launch phase handling in EPP. Since this draft does not supply a schema definition at the moment, the CORE Registration System implements its own, which can be found in attachment Q25-Ext-LP.pdf, Section 1. Once the draft was augmented by a concrete schema definition, the CORE Registration System will be adapted to utilise it, retaining the custom XML namespace identifier. Once the draft becomes an RFC, a transition will be conducted to adopt the standard.


5.1.2 Object Attributes

This extension for launch phases adds additional elements to the EPP domain name mapping. Only new element descriptions are documented here.

Since registries usually allow multiple applications for a particular domain name during launch phases, an application object is used internally. Such an object has a unique ID that is returned upon creation and is used to refer to this application in further requests. Within this extension, an ʺlp:applicationIDʺ element is used to specify this ID.


5.1.2.1 Phase

The ʺlp:phaseʺ element can be used to distinguish multiple simultaneous launch phases. Its content is a server-defined identifier corresponding to a particular launch phase.


5.1.2.2 Application Status

The ʺlp:statusʺ element is used to communicate extended status(es) of the application object, beyond what is specified in the object mapping to which this application object belongs.

The following status values are defined: ʺpendingʺ, the initial state of a newly-created application object; ʺvalidatedʺ, the application meets relevant registry rules; ʺinvalidʺ, the application does not validate according to registry rules; ʺallocatedʺ, the object corresponding to the application has been provisioned (one of two possible end states of an application object); ʺrejectedʺ, the object was not provisioned (the other possible end state).


5.1.2.3 Claim Data

An application may have one or more ʺlp:claimʺ elements. An ʺlp:claimʺ element describes the applicantʹs prior right to the domain name.

The ʺlp:claimʺ element has the boolean ʺpreValidatedʺ attribute, which indicates whether a third party validation agency has already validated the claim. When this attribute has a true value, the ʺlp:pvrcʺ element must always be present.

Several child elements of the ʺlp:claimʺ element are defined. ʺlp:pvrcʺ, the Pre-Validation Result Code, is a string issued by a third-party validation agent. ʺlp:claimIssuerʺ contains the ID of a contact object (as described in RFC 5733) identifying the contact information of the authority which issued the right (for example, a trademark office or company registration bureau). ʺlp:claimNameʺ identifies the text string in which the applicant is claiming a prior right. ʺlp:claimNumberʺ contains the registration number of the right (i.e. trademark number or company registration number). ʺlp:claimTypeʺ indicates the type of claim being made (e.g. trademark, symbol, combined mark, company name). ʺlp:claimEntitlementʺ indicates the applicantʹs entitlement to the claim (i.e. owner or licensee). ʺlp:claimRegDateʺ contains the date of registration of the claim. ʺlp:claimExDateʺ contains the date of expiration of the claim. ʺlp:claimCountryʺ indicates the country in which the claim is valid. ʺlp:claimRegionʺ indicates the name of a city, state, province or other geographic region in which the claim is valid. This may be a two-character code from World Intellectual Property Organisation (WIPO) standard ST.3.


5.1.2.4 Additional Application Information

An application may carry a ʺlp:applicationInfoʺ element. If present, it contains additional information (beyond the claim) about the application, such as the domain nameʹs intended use.


5.1.3 EPP Command Mapping

This section deals with the specific command mappings for the .barcelona Registry EPP extension for launch phases.


5.1.3.1 EPP Query Commands

There are four EPP commands to retrieve object information: ʺcheckʺ to find out whether an object is known to the server, ʺinfoʺ to ask for detailed information associated with an object, ʺpollʺ to discover and retrieve queued service messages for individual clients and ʺtransferʺ to get transfer status information for an object.


5.1.3.1.1 EPP ʺcheckʺ Command

This extension does not add any elements to the EPP ʺcheckʺ command or to the ʺcheckʺ response described in the EPP domain mapping (s. RFC 5731).


5.1.3.1.2 EPP ʺinfoʺ Command

This extension adds elements to the EPP ʺinfoʺ command and response described in the EPP domain mapping for launch phase processing.

The EPP ʺextensionʺ element of the ʺinfoʺ command contains a child ʺlp:infoʺ element to indicate that an application object should be queried. It identifies the registry launch phase namespace and the location of the registry launch phase schema. The ʺlp:infoʺ element contains the following child elements: ʺlp:applicationIDʺ, the application identifier for which the client wishes to query, and ʺlp:phaseʺ (optional), the phase the application is associated with.

When such an ʺinfoʺ command has been processed successfully, the EPP ʺextensionʺ element in the response contains a child ʺlp:infDataʺ element that identifies the registry launch phase namespace and the location of the registry launch phase schema. The ʺlp:infDataʺ element contains the following child elements. ʺlp:applicationIDʺ contains the application identifier of the returned application. ʺlp:phaseʺ (optional) contains the phase the application is associated with. ʺlp:statusʺ (optional) contains the status of the application. One or more ʺlp:claimʺ elements (optional) give the submitted data establishing the applicantʹs prior right to the domain name.

If any ʺlp:claimʺ element is present, each of them may contain the following child elements. ʺpvrcʺ gives the Pre-Validation Result Code. ʺclaimIssuerʺ contains the ID of a contact object representing the issuing authority. ʺclaimNameʺ contains the textual representation of the right. ʺclaimNumberʺ contains the registration number. ʺclaimTypeʺ contains the type of claim being made. ʺclaimEntitlementʺ contains the entitlement. ʺclaimRegDateʺ contains the registration date. ʺclaimExDateʺ contains the expiry date.

If additional information about the application was specified when the application was created, an ʺapplicationInfoʺ element will be present containing that information.

Examples of an ʺinfoʺ command and corresponding response can be found in attachment Q25-Ext-LP.pdf, Section 2.1. EPP ʺinfoʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.1.3.1.3 EPP ʺpollʺ Command

This extension does not add any elements to the EPP ʺpollʺ command or to the ʺpollʺ response described in the EPP domain mapping (s. RFC 5731).


5.1.3.1.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.1.3.2 EPP Transform Commands

There are five EPP commands to transform objects: ʺcreateʺ to create an instance of an object, ʺdeleteʺ to delete an instance of an object, ʺrenewʺ to extend the validity period of an object, ʺtransferʺ to manage object sponsorship changes and ʺupdateʺ to change information associated with an object.


5.1.3.2.1 EPP ʺcreateʺ Command

This extension adds elements to the EPP ʺcreateʺ command and response described in the EPP domain mapping for launch phase processing.

The EPP ʺextensionʺ element of the ʺcreateʺ command contains a child ʺlp:createʺ element to indicate that an application object for a launch phase should be created. It identifies the registry launch phase namespace and the location of the registry launch phase schema. The ʺlp:createʺ element contains the following child elements: ʺlp:phaseʺ (optional), the phase the application should be associated with, zero or more ʺlp:claimʺ elements to substantiate the prior rights of the applicant, and an optional ʺlp:applicationInfoʺ element providing additional information about the application, such as the intended use of the domain name.

When such a ʺcreateʺ command has been processed successfully, the EPP ʺextensionʺ element in the response contains a child ʺlp:creDataʺ element that identifies the registry launch phase namespace and the location of the registry launch phase schema. The ʺlp:creDataʺ element contains a child ʺlp:applicationIDʺ element, which informs the registrar about the application ID the server has assigned.

Examples of a ʺcreateʺ command and corresponding response can be found in attachment Q25-Ext-LP.pdf, Section 2.2. EPP ʺcreateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.1.3.2.2 EPP ʺdeleteʺ Command

This extension defines additional elements to extend the EPP ʺdeleteʺ command described in the EPP domain mapping for launch phase processing. No additional elements are defined for the ʺdeleteʺ response.

Clients may withdraw an application if permitted by registry policy. To do so, clients submit an EPP ʺdeleteʺ command along with an ʺlp:deleteʺ element to indicate the application object to be deleted. The ʺlp:deleteʺ element contains the following child elements: ʺlp:applicationIDʺ, the identifier of the application to be deleted, and ʺlp:phaseʺ (optional), the phase the application is associated with.

An example of a ʺdeleteʺ command can be found in attachment Q25-Ext-LP.pdf, Section 2.3. EPP ʺdeleteʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text.

The CORE Registration System supports the withdrawal of an application using this extension to the ʺdeleteʺ command. Note, however, that support for the withdrawal of an application depends on the .barcelona Registry Sunrise policy, which is described elsewhere.


5.1.3.2.3 EPP ʺrenewʺ Command

This extension does not add any elements to the EPP ʺrenewʺ command or to the ʺrenewʺ response described in the EPP domain mapping (s. RFC 5731).


5.1.3.2.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.1.3.2.5 EPP ʺupdateʺ Command

This extension defines additional elements to extend the EPP ʺupdateʺ command described in the EPP domain mapping for launch phase processing. No additional elements are defined for the ʺupdateʺ response.

Clients may modify an application if permitted by registry policy. To do so, clients submit an EPP ʺupdateʺ command along with an ʺlp:updateʺ element to indicate the application object to be modified. The ʺlp:updateʺ element contains the following child elements: ʺlp:applicationIDʺ, the identifier of the application to be modified, and ʺlp:phaseʺ (optional), the phase the application is associated with.

An example of an ʺupdateʺ command can be found in attachment Q25-Ext-LP.pdf, Section 2.4. EPP ʺupdateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text.

The CORE Registration System supports the modification of an application using this extension to the ʺupdateʺ command. Note, however, that support for the modification of an application depends on the .barcelona Registry Sunrise policy, which is described elsewhere.


5.1.4 Formal Syntax

The formal syntax of this EPP extension is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The schema definition is listed in attachment Q25-Ext-LP.pdf, Section 1. Schema Definition (Formal Syntax), since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.2 Extension for Auction Information

The CORE Registration System used to operate the .barcelona Registry provides a proprietary EPP extension for submitting special data needed for auctions as they occur after launch phases (e.g. Sunrise and Landrush).


5.2.1 Introduction

This part of this answer desribes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730. This mapping is an extension of the domain name mapping described in RFC 5731. It is specified using the Extensible Markup Language (XML) and XML Schema notation.

This extension serves the purpose of supplying and querying information for special phases, usually at the beginning of registry operation. A typical use case is a ʺSunriseʺ phase during which trademark holders have a prerogative to register a domain name related to their trademark.

Registries usually allow multiple applications for a particular domain name during launch phases. This extension helps to resolve such situations by means of an auction in an automated way. This is not a normal auction, however, insofar as every application has a ʺbidʺ associated with it. Bids cannot be modified after the phase the application belongs to has ended. Among all valid applications for a given domain name, the one with the highest bid wins the auction.


5.2.2 Object Attributes

This extension for auctions adds additional elements to the EPP domain name mapping. Only new element descriptions are documented here.

This extension allows the provisioning of auction information in the form of bids. A bid can be made when applying for a domain name. In case there is more than one valid application, an auction mechanism is used as a tie-breaker. The highest bid submitted for the domain name in question will win the auction.


5.2.2.1 Bid

The ʺauction:bidʺ element is used to set and inform about a bid for a domain name. Its content is the amount of money the applicant is willing to pay for the domain name in case of an auction. The currency is given in the required currency attribute, specified by the corresponding ISO 4217 currency code.

Note that the amount is given as a non-negative number. This allows to submit a bid of zero in case the applicant is not interested in an auction at all.


5.2.3 EPP Command Mapping

This section deals with the specific command mappings for the .barcelona Registry EPP extension for auctions.


5.2.3.1 EPP Query Commands

There are four EPP commands to retrieve object information: ʺcheckʺ to find out whether an object is known to the server, ʺinfoʺ to ask for detailed information associated with an object, ʺpollʺ to discover and retrieve queued service messages for individual clients and ʺtransferʺ to get transfer status information for an object.


5.2.3.1.1 EPP ʺcheckʺ Command

This extension does not add any elements to the EPP ʺcheckʺ command or to the ʺcheckʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.1.2 EPP ʺinfoʺ Command

This extension does not add any elements to the EPP ʺinfoʺ command described in the EPP domain mapping. Additional elements are defined for the ʺinfoʺ response.

When an ʺinfoʺ command has been processed successfully, the EPP ʺextensionʺ element in the response, if present, contains a child ʺauction:infDataʺ element that identifies the registry auction namespace and the location of the registry auction schema. The ʺauction:infDataʺ element contains an ʺauction:bidʺ element, which informs about the amount and currency of the currently set bid as described above.

An example of an ʺinfoʺ response can be found in attachment Q25-Ext-Auction.pdf, Section 2.1. EPP ʺinfoʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example simply retrieves the current bid for the given domain name.


5.2.3.1.3 EPP ʺpollʺ Command

This extension does not add any elements to the EPP ʺpollʺ command or to the ʺpollʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.1.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2 EPP Transform Commands

There are five EPP commands to transform objects: ʺcreateʺ to create an instance of an object, ʺdeleteʺ to delete an instance of an object, ʺrenewʺ to extend the validity period of an object, ʺtransferʺ to manage object sponsorship changes and ʺupdateʺ to change information associated with an object.


5.2.3.2.1 EPP ʺcreateʺ Command

This extension defines additional elements to extend the EPP ʺcreateʺ command described in the EPP domain mapping for auction processing. No additional elements are defined for the ʺcreateʺ response.

The EPP ʺextensionʺ element of the ʺcreateʺ command contains a child ʺauction:createʺ element to indicate that auction information should be submitted. It identifies the registry auction namespace and the location of the registry auction schema. The ʺauction:createʺ element must contain an ʺauction:bidʺ element, which specifies the amount and currency as described above.

An example of a ʺcreateʺ command can be found in attachment Q25-Ext-Auction.pdf, Section 2.2. EPP ʺcreateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example sets the bid when applying for the given domain name to the specified amount.


5.2.3.2.2 EPP ʺdeleteʺ Command

This extension does not add any elements to the EPP ʺdeleteʺ command or to the ʺdeleteʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2.3 EPP ʺrenewʺ Command

This extension does not add any elements to the EPP ʺrenewʺ command or to the ʺrenewʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2.5 EPP ʺupdateʺ Command

This extension defines additional elements to extend the EPP ʺupdateʺ command described in the EPP domain mapping for auction processing. No additional elements are defined for the ʺupdateʺ response.

The EPP ʺextensionʺ element of the ʺupdateʺ command contains a child ʺauction:updateʺ element to indicate that auction information should be updated. It identifies the registry auction namespace and the location of the registry auction schema. The ʺauction:updateʺ element must contain an ʺauction:bidʺ element, which specifies the new amount and currency as described above.

Whether all modifications of bids are allowed, only certain ones (e.g. only increases) or none at all depends on the .barcelona Registry auction policy, which is described elsewhere.

An example of an ʺupdateʺ command can be found in attachment Q25-Ext-Auction.pdf, Section 2.3. EPP ʺupdateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example modifies the bid for the given domain name.


5.2.4 Formal Syntax

The formal syntax of this EPP extension is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The schema definition is listed in attachment Q25-Ext-Auction.pdf, Section 1. Schema Definition (Formal Syntax), since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.3 Extension for Language Information

The CORE Registration System used to operate the .barcelona Registry provides a proprietary EPP extension for internationalised domain names (IDNs).


5.3.1 Introduction

This part of this answer desribes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730. This mapping is an extension of the domain name mapping described in RFC 5731. It is specified using the Extensible Markup Language (XML) and XML Schema notation.

This extension serves the purpose of supplying and querying information for internationalised domain names. In particular, the language or script used and domain name variants are addressed.


5.3.2 Object Attributes

This extension for IDNs adds additional elements to the EPP domain name mapping. Only new element descriptions are documented here.


5.3.2.1 Languages and Scripts

This extension allows the specification of either a language tag or a script tag when registering a domain name. The language or script defines the characters allowed for use in the domain name as specified in the IDN tables (see Question 44, Support for Registering IDN Domains). It is not allowed to specify more than one language or more than one script.

For the time being, the .barcelona Registry expects the value of a language tag element to be a an ISO 639-1 language code referring to a supported language. The value of a script tag is expected to be an ISO 15924 script code referring to a supported script.


5.3.2.2 Variants

This extension allows to specify a number of variants of the domain name to be registered together with the supplied domain name. The variants are expected to be submitted in normalised form (see also Q44, Support for Registering IDN domains). The number of variants that can be specified is limited to at most 10.


5.3.3 EPP Command Mapping

This section deals with the specific command mappings for the .barcelona Registry EPP extension for IDNs.


5.3.3.1 EPP Query Commands

There are four EPP commands to retrieve object information: ʺcheckʺ to find out whether an object is known to the server, ʺinfoʺ to ask for detailed information associated with an object, ʺpollʺ to discover and retrieve queued service messages for individual clients and ʺtransferʺ to get transfer status information for an object.


5.3.3.1.1 EPP ʺcheckʺ Command

This extension defines additional elements to extend the EPP ʺcheckʺ command described in the EPP domain mapping for IDN processing. No additional elements are defined for the ʺcheckʺ response.

The EPP ʺcheckʺ command is used to determine if an object can be provisioned within a repository. This IDN extension modifies base check processing to support language and script tags.

The EPP ʺextensionʺ element, if present, contains a child ʺidn:checkʺ element that identifies the registry IDN namespace and the location of the registry IDN schema. If at least one of the checked domains is an IDN, the ʺidn:checkʺ element must contain either an ʺidn:langʺ element or an ʺidn:scriptʺ element. The ʺidn:langʺ element contains the language whose characters may be used in the checked domain names; the ʺidn:scriptʺ element contains the script whose characters may be used in the checked domain names. The language or script specification applies to all domain names specified in the command. The results of the check (i.e., the domains namesʹ availability for provisioning) are governed by the validity of the names with respect to the specified language or script.

Examples of ʺcheckʺ commands can be found in attachment Q25-Ext-IDN.pdf, Section 2.1. EPP ʺcheckʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. Two examples are included, one with a language tag (Section 2.1.1), one with a script tag (Section 2.1.2).


5.3.3.1.2 EPP ʺinfoʺ Command

This extension does not add any elements to the EPP ʺinfoʺ command described in the EPP domain mapping. Additional elements are defined for the ʺinfoʺ response.

When an ʺinfoʺ command has been processed successfully, the EPP ʺextensionʺ element in the response, if present, contains a child ʺidn:infDataʺ element that identifies the registry IDN namespace and the location of the registry IDN schema. The ʺidn:infDataʺ element contains either an ʺidn:langʺ element or an ʺidn:scriptʺ element. The ʺidn:langʺ element contains the language that is set for the domain name object; the ʺidn:scriptʺ element contains the script that is set for the domain name object.

The ʺidn:infDataʺ element also contains an ʺidn:variantsʺ element, which in turn contains a (possibly empty) sequence of ʺidn:nameVariantʺ elements. The ʺidn:nameVariantʺ elements represent the variants that are registered together with the actual domain name.

Examples of ʺinfoʺ responses can be found in attachment Q25-Ext-IDN.pdf, Section 2.2. EPP ʺinfoʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. Three examples are included, one with a language tag only (Section 2.2.1), one with a script tag only (Section 2.2.2) and one with a language tag and variants (Section 2.2.3).


5.3.3.1.3 EPP ʺpollʺ Command

This extension does not add any elements to the EPP ʺpollʺ command or to the ʺpollʺ response described in the EPP domain mapping (s. RFC 5731).


5.3.3.1.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2 EPP Transform Commands

There are five EPP commands to transform objects: ʺcreateʺ to create an instance of an object, ʺdeleteʺ to delete an instance of an object, ʺrenewʺ to extend the validity period of an object, ʺtransferʺ to manage object sponsorship changes and ʺupdateʺ to change information associated with an object.


5.3.3.2.1 EPP ʺcreateʺ Command

This extension defines additional elements to extend the EPP ʺcreateʺ command described in the EPP domain mapping for IDN processing. No additional elements are defined for the ʺcreateʺ response.

The EPP ʺcreateʺ command provides a transform operation that allows a client to create an instance of a domain object. This IDN extension modifies base create processing to support language tags, script tags and domain name variants.

The EPP ʺextensionʺ element, if present, contains a child ʺidn:createʺ element that identifies the registry IDN namespace and the location of the registry IDN schema. The ʺidn:createʺ element must contain either an ʺidn:langʺ element or an ʺidn:scriptʺ element. The ʺidn:langʺ element contains the language whose characters may be used in the domain name; the ʺidn:scriptʺ element contains the script whose characters may be used in the domain name.

The ʺidn:createʺ element must also contain an ʺidn:variantsʺ element, which in turn contains a (possibly empty) sequence of ʺidn:nameVariantʺ elements. The ʺidn:nameVariantʺ elements represent the variants that are to be registered together with the actual domain name.

Note that the .barcelona Registry restricts the number of domain name variants given in the ʺidn:variantsʺ element to at most 10. Submitting an empty ʺidn:variantsʺ element is allowed; this will not register any domain name variants.

Examples of ʺcreateʺ commands can be found in attachment Q25-Ext-IDN.pdf, Section 2.3. EPP ʺcreateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. Three examples are included, one with a language tag only (Section 2.3.1), one with a script tag only (Section 2.3.2) and one with language tags and variants (Section 2.3.3).


5.3.3.2.2 EPP ʺdeleteʺ Command

This extension does not add any elements to the EPP ʺdeleteʺ command or to the ʺdeleteʺ response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2.3 EPP ʺrenewʺ Command

This extension does not add any elements to the EPP ʺrenewʺ command or to the ʺrenewʺ response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2.5 EPP ʺupdateʺ Command

This extension defines additional elements to extend the EPP ʺupdateʺ command described in the EPP domain mapping for IDN processing. No additional elements are defined for the ʺupdateʺ response.

The EPP ʺupdateʺ command provides a transform operation that allows a client to change the state of a domain object. This IDN extension modifies base update processing to support domain name variants.

The EPP ʺextensionʺ element, if present, must contain a child ʺidn:updateʺ element that identifies the registry IDN namespace and the location of the registry IDN schema. The ʺidn:updateʺ element may contain an ʺidn:addʺ element and an ʺidn:remʺ element. Each of these contain a (possibly empty) sequence of ʺidn:nameVariantʺ elements. Similar to the ʺupdateʺ commandʹs elements ʺdomain:addʺ and ʺdomain:remʺ, these are used to specify the domain name variants that are to be added to and removed from the domain object, respectively. If the EPP ʺextensionʺ element is missing in the ʺupdateʺ command, no change to the domain name variants will be made.

Note that the .barcelona Registry restricts the number of domain name variants given in the ʺidn:addʺ and ʺidn:remʺ elements to at most 10.

An example of an ʺupdateʺ command can be found in attachment Q25-Ext-IDN.pdf, Section 2.4. EPP ʺupdateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example adds some variants to be associated with the given domain name while removing existing ones at the same time (Section 2.4.1).


5.3.4 Formal Syntax

The formal syntax of this EPP extension is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The schema definition is listed in attachment Q25-Ext-IDN.pdf, Section 1. Schema Definition (Formal Syntax), since the TLD Application System (TAS) is not well suited to pre-formatted text.


6. Resourcing plans


6.1 Initial Work

No resources are necessary for the initial implementation, since the CORE Registration System (including the EPP extensions) has already been implemented.


6.2 Ongoing Work

For registrar support regarding the EPP extensions, the following resource allocations are estimated:

First Level Support: 4 man hours per month.

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.
gTLDFull Legal NameE-mail suffixDetail
.radioEuropean Broadcasting Union (EBU)ebu.chView
Q25 - Extensible Provisioning Protocol (EPP)


1. Experience

The EPP interface for registrars of the .radio registry is based on COREʹs EPP implementation, which has been used for several registries.

Since 2006, CORE handles the backend registry operation for puntCAT (responsible for the .cat top-level domain). Right from the start, COREʹs .cat Shared Registration System (SRS) offered an EPP frontend fully compliant with RFCs 3730-3734 (updated to compliance with 5730-5734 in the meantime), using various EPP extensions to cope with puntCATʹs special requirements. The SRS also fully supports the provisioning of DNSSEC data in accordance with RFC 5910; for backward compatibility, the previous DNSSEC EPP extension (RFC 4310) is also supported.

In addition, based on the same technology, CORE Internet Council of Registrars is currently in the process of taking over back-end operations for a country code top-level domain managing between 200,000 and 500,000 domain names. The details of this cooperation cannot be disclosed at the time of writing. While this registryʹs DNS services have already been transitioned to CORE at this point, the migration of SRS and Whois operations are currently being finalised.

CORE Internet Council of Registrars provides the unified CORE Registration System for its members since 1997. This system grants access to a multitude of top-level domain registries, currently including .com, .net, .org, .info, .biz, .name (with support for domain name and e-mail forwarding addresses), .us, .asia, .cn, .tw, .eu, .mobi, .aero, .me, .tel, .coop, .ch and .li domains, via a single entry point. CORE members can access all supported registries using a single, unified protocol. The CORE Registration System maps the commands issued by the user to the corresponding EPP commands, sends them to the appropriate registry server and translates back the received results. Members do not need to cope with problems regarding registry communication (like different flavours of EPP, SSL⁄TLS certificate handling or Punycode conversion for internationalised domain names) themselves.

Since the CORE Registration System acts as a client regarding all the supported registries, its implementation also allowed CORE Internet Council of Registrars to gain considerable experience concerning all client side aspects of (different versions of) EPP. In particular, client-side EPP support had already started with the introduction of EPP by Afilias and Neulevel. On the server side, EPP has been in use since starting the operation of the puntCAT registry some five years ago. At the heart of the EPP implementation lies the so-called Unikit, COREʹs EPP toolkit implementation. The Unikit includes code for the client side and for the server side. In the context of the .radio registry, the server-side part of the Unikit will be used.

In the person of Klaus Malorny, CORE also actively participated in the IETF Provisioning Registry Protocol (provreg) working group and contributed to some RFCs (see Acknowledgements in RFCs 5730-5733 and RFC 5910).

The software implementing the actual shared registry system, including its EPP interface, was entirely built by CORE, involving an international team of developers from several member companies — thus demonstrating the software development skills at COREʹs disposal.


2. Standards Compliance

The EPP interface of the .radio registry, provided by the CORE Registration System, is fully compliant with RFCs 5730-5734. These define mappings for the provisioning and management of Internet domain names, Internet host names and individual or organisational social information identifiers (ʺcontactsʺ) stored in a shared central repository.

Apart from these standards, the .radio registry also supports the proposed standard for DNSSEC (RFC 5910). This is an EPP extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository.

The proposed standard for an EPP extension for ʺgrace periodʺ policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN) is fully supported also (RFC 3915). Such grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed.

Furthermore, a few proprietary EPP extensions are used by the .radio registry to allow registrars to provide trademark information during the Sunrise phase, auction information during Sunrise and Landrush phases as well as language information. Documentation consistent with RFC 3735 for these proprietary EPP extensions can be found below.

All incoming requests will be validated against the schema definitions in the relevant RFCs and the ones of the proprietary EPP extensions, if applicable. This adds to security and stability, as invalid requests are dismissed early on. The EPP implementation of the .radio registry is compatible with existing toolkits that produce valid EPP requests.

Pending, asynchronous operations are fully supported by the registry implementation. The SRS returns an EPP result code of 1000 if a command has succeeded synchronously, i.e. immediately. In contrast, a result code of 1001 is returned if a command was accepted but requires asynchronous processing before it can be completed.


3. Stability

A stable EPP interface is very important for smooth operation of a shared registry system. To ensure this, the CORE Registration System contains a multi-threaded, asynchronous communication implementation allowing a high number of concurrent EPP connections.

The incoming requests are filtered by their IP addresses via firewall rules in order to disallow access from unauthorised sites. This increases not only the security of the system, but also its stability, since the load on the EPP servers is reduced.


4. Equal opportunity

EPP access limitations for registrars are enforced by the CORE Registration System, allowing a certain number of concurrent connections only. This further enhances the stability of the system and is an important ingredient for equal opportunity as well. Registrars cannot effectively hinder their competitors from connecting by simply opening a great many connections themselves.

For the sake of equal opportunity, the .radio registry also avoids first-come, first-served (FCFS) policies where possible. This is why the general availability (GA) phase is the only one using this principle. All popular domain names will probably have been registered already when GA starts (during previously conducted launch phases not using FCFS), so FCFS during GA does not contradict the idea of equal opportunity.


5. Proprietary Extensions

CORE Internet Council of Registrars has already shown its ability to design, specify and implement proprietary EPP extensions in the context of the puntCAT registry. There, extensions exist for the specification of promotion codes, sponsor e-mail addresses, application objects (used during the Sunrise phase) and poll messages to notify registrars about application outcomes, for example. In the following, the proprietary EPP extensions planned to be used for .radio are described.


5.1 Extension for Trademark Information during Launch Phases

The CORE Registration System used to operate the .radio registry provides a proprietary EPP extension for submitting special data needed during launch phases.


5.1.1 Introduction

This part of this answer describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730. This mapping is an extension of the domain name mapping described in RFC 5731. It is specified using the Extensible Markup Language (XML) and XML Schema notation.

This extension serves the purpose of supplying and querying information for special phases, usually at the beginning of registry operation. A typical use case is a ʺSunriseʺ phase during which trademark holders have a prerogative to register a domain name related to their trademark. In particular, this extension allows the provisioning of trademark information and the querying of the current status of a domain name application.

In addition, the extension allows the specification of additional information about the application, such as the intended use for the domain name, a URL demonstrating prior use of similar names in other TLDs etc.; the registryʹs Sunrise policy determines whether and how this information is utilised.

An extension to the ʺpollʺ command is not included. Registrars are notified of application results via the poll message mechanism already included in EPP.

This extension has been developed along the lines of the Internet draft by Tan and Brown (see http:⁄⁄tools.ietf.org⁄html⁄draft-tan-epp-launchphase-01). Even though that document is currently only a draft, it serves the purpose needed for the .radio registry and is clearly a step forward regarding the standardisation of launch phase handling in EPP. Since this draft does not supply a schema definition at the moment, the CORE Registration System implements its own, which can be found in attachment Q25-Ext-LP.pdf, Section 1. Once the draft was augmented by a concrete schema definition, the CORE Registration System will be adapted to utilise it, retaining the custom XML namespace identifier. Once the draft becomes an RFC, a transition will be conducted to adopt the standard.


5.1.2 Object Attributes

This extension for launch phases adds additional elements to the EPP domain name mapping. Only new element descriptions are documented here.

Since registries usually allow multiple applications for a particular domain name during launch phases, an application object is used internally. Such an object has a unique ID that is returned upon creation and is used to refer to this application in further requests. Within this extension, an ʺlp:applicationIDʺ element is used to specify this ID.


5.1.2.1 Phase

The ʺlp:phaseʺ element can be used to distinguish multiple simultaneous launch phases. Its content is a server-defined identifier corresponding to a particular launch phase.


5.1.2.2 Application Status

The ʺlp:statusʺ element is used to communicate extended status(es) of the application object, beyond what is specified in the object mapping to which this application object belongs.

The following status values are defined: ʺpendingʺ, the initial state of a newly-created application object; ʺvalidatedʺ, the application meets relevant registry rules; ʺinvalidʺ, the application does not validate according to registry rules; ʺallocatedʺ, the object corresponding to the application has been provisioned (one of two possible end states of an application object); ʺrejectedʺ, the object was not provisioned (the other possible end state).


5.1.2.3 Claim Data

An application may have one or more ʺlp:claimʺ elements. An ʺlp:claimʺ element describes the applicantʹs prior right to the domain name.

The ʺlp:claimʺ element has the boolean ʺpreValidatedʺ attribute, which indicates whether a third party validation agency has already validated the claim. When this attribute has a true value, the ʺlp:pvrcʺ element must always be present.

Several child elements of the ʺlp:claimʺ element are defined. ʺlp:pvrcʺ, the Pre-Validation Result Code, is a string issued by a third-party validation agent. ʺlp:claimIssuerʺ contains the ID of a contact object (as described in RFC 5733) identifying the contact information of the authority which issued the right (for example, a trademark office or company registration bureau). ʺlp:claimNameʺ identifies the text string in which the applicant is claiming a prior right. ʺlp:claimNumberʺ contains the registration number of the right (i.e. trademark number or company registration number). ʺlp:claimTypeʺ indicates the type of claim being made (e.g. trademark, symbol, combined mark, company name). ʺlp:claimEntitlementʺ indicates the applicantʹs entitlement to the claim (i.e. owner or licensee). ʺlp:claimRegDateʺ contains the date of registration of the claim. ʺlp:claimExDateʺ contains the date of expiration of the claim. ʺlp:claimCountryʺ indicates the country in which the claim is valid. ʺlp:claimRegionʺ indicates the name of a city, state, province or other geographic region in which the claim is valid. This may be a two-character code from World Intellectual Property Organisation (WIPO) standard ST.3.


5.1.2.4 Additional Application Information

An application may carry a ʺlp:applicationInfoʺ element. If present, it contains additional information (beyond the claim) about the application, such as the domain nameʹs intended use.


5.1.3 EPP Command Mapping

This section deals with the specific command mappings for the .radio registry EPP extension for launch phases.


5.1.3.1 EPP Query Commands

There are four EPP commands to retrieve object information: ʺcheckʺ to find out whether an object is known to the server, ʺinfoʺ to ask for detailed information associated with an object, ʺpollʺ to discover and retrieve queued service messages for individual clients and ʺtransferʺ to get transfer status information for an object.


5.1.3.1.1 EPP ʺcheckʺ Command

This extension does not add any elements to the EPP ʺcheckʺ command or to the ʺcheckʺ response described in the EPP domain mapping (s. RFC 5731).


5.1.3.1.2 EPP ʺinfoʺ Command

This extension adds elements to the EPP ʺinfoʺ command and response described in the EPP domain mapping for launch phase processing.

The EPP ʺextensionʺ element of the ʺinfoʺ command contains a child ʺlp:infoʺ element to indicate that an application object should be queried. It identifies the registry launch phase namespace and the location of the registry launch phase schema. The ʺlp:infoʺ element contains the following child elements: ʺlp:applicationIDʺ, the application identifier for which the client wishes to query, and ʺlp:phaseʺ (optional), the phase the application is associated with.

When such an ʺinfoʺ command has been processed successfully, the EPP ʺextensionʺ element in the response contains a child ʺlp:infDataʺ element that identifies the registry launch phase namespace and the location of the registry launch phase schema. The ʺlp:infDataʺ element contains the following child elements. ʺlp:applicationIDʺ contains the application identifier of the returned application. ʺlp:phaseʺ (optional) contains the phase the application is associated with. ʺlp:statusʺ (optional) contains the status of the application. One or more ʺlp:claimʺ elements (optional) give the submitted data establishing the applicantʹs prior right to the domain name.

If any ʺlp:claimʺ element is present, each of them may contain the following child elements. ʺpvrcʺ gives the Pre-Validation Result Code. ʺclaimIssuerʺ contains the ID of a contact object representing the issuing authority. ʺclaimNameʺ contains the textual representation of the right. ʺclaimNumberʺ contains the registration number. ʺclaimTypeʺ contains the type of claim being made. ʺclaimEntitlementʺ contains the entitlement. ʺclaimRegDateʺ contains the registration date. ʺclaimExDateʺ contains the expiry date.

If additional information about the application was specified when the application was created, an ʺapplicationInfoʺ element will be present containing that information.

Examples of an ʺinfoʺ command and corresponding response can be found in attachment Q25-Ext-LP.pdf, Section 2.1. EPP ʺinfoʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.1.3.1.3 EPP ʺpollʺ Command

This extension does not add any elements to the EPP ʺpollʺ command or to the ʺpollʺ response described in the EPP domain mapping (s. RFC 5731).


5.1.3.1.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.1.3.2 EPP Transform Commands

There are five EPP commands to transform objects: ʺcreateʺ to create an instance of an object, ʺdeleteʺ to delete an instance of an object, ʺrenewʺ to extend the validity period of an object, ʺtransferʺ to manage object sponsorship changes and ʺupdateʺ to change information associated with an object.


5.1.3.2.1 EPP ʺcreateʺ Command

This extension adds elements to the EPP ʺcreateʺ command and response described in the EPP domain mapping for launch phase processing.

The EPP ʺextensionʺ element of the ʺcreateʺ command contains a child ʺlp:createʺ element to indicate that an application object for a launch phase should be created. It identifies the registry launch phase namespace and the location of the registry launch phase schema. The ʺlp:createʺ element contains the following child elements: ʺlp:phaseʺ (optional), the phase the application should be associated with, zero or more ʺlp:claimʺ elements to substantiate the prior rights of the applicant, and an optional ʺlp:applicationInfoʺ element providing additional information about the application, such as the intended use of the domain name.

When such a ʺcreateʺ command has been processed successfully, the EPP ʺextensionʺ element in the response contains a child ʺlp:creDataʺ element that identifies the registry launch phase namespace and the location of the registry launch phase schema. The ʺlp:creDataʺ element contains a child ʺlp:applicationIDʺ element, which informs the registrar about the application ID the server has assigned.

Examples of a ʺcreateʺ command and corresponding response can be found in attachment Q25-Ext-LP.pdf, Section 2.2. EPP ʺcreateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.1.3.2.2 EPP ʺdeleteʺ Command

This extension defines additional elements to extend the EPP ʺdeleteʺ command described in the EPP domain mapping for launch phase processing. No additional elements are defined for the ʺdeleteʺ response.

Clients may withdraw an application if permitted by registry policy. To do so, clients submit an EPP ʺdeleteʺ command along with an ʺlp:deleteʺ element to indicate the application object to be deleted. The ʺlp:deleteʺ element contains the following child elements: ʺlp:applicationIDʺ, the identifier of the application to be deleted, and ʺlp:phaseʺ (optional), the phase the application is associated with.

An example of a ʺdeleteʺ command can be found in attachment Q25-Ext-LP.pdf, Section 2.3. EPP ʺdeleteʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text.

The CORE Registration System supports the withdrawal of an application using this extension to the ʺdeleteʺ command. Note, however, that support for the withdrawal of an application depends on the .radio registry Sunrise policy, which is described elsewhere.


5.1.3.2.3 EPP ʺrenewʺ Command

This extension does not add any elements to the EPP ʺrenewʺ command or to the ʺrenewʺ response described in the EPP domain mapping (s. RFC 5731).


5.1.3.2.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.1.3.2.5 EPP ʺupdateʺ Command

This extension defines additional elements to extend the EPP ʺupdateʺ command described in the EPP domain mapping for launch phase processing. No additional elements are defined for the ʺupdateʺ response.

Clients may modify an application if permitted by registry policy. To do so, clients submit an EPP ʺupdateʺ command along with an ʺlp:updateʺ element to indicate the application object to be modified. The ʺlp:updateʺ element contains the following child elements: ʺlp:applicationIDʺ, the identifier of the application to be modified, and ʺlp:phaseʺ (optional), the phase the application is associated with.

An example of an ʺupdateʺ command can be found in attachment Q25-Ext-LP.pdf, Section 2.4. EPP ʺupdateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text.

The CORE Registration System supports the modification of an application using this extension to the ʺupdateʺ command. Note, however, that support for the modification of an application depends on the .radio registry Sunrise policy, which is described elsewhere.


5.1.4 Formal Syntax

The formal syntax of this EPP extension is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The schema definition is listed in attachment Q25-Ext-LP.pdf, Section 1. Schema Definition (Formal Syntax), since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.2 Extension for Auction Information

The CORE Registration System used to operate the .radio registry provides a proprietary EPP extension for submitting special data needed for auctions as they occur after launch phases (e.g. Sunrise and Landrush).


5.2.1 Introduction

This part of this answer desribes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730. This mapping is an extension of the domain name mapping described in RFC 5731. It is specified using the Extensible Markup Language (XML) and XML Schema notation.

This extension serves the purpose of supplying and querying information for special phases, usually at the beginning of registry operation. A typical use case is a ʺSunriseʺ phase during which trademark holders have a prerogative to register a domain name related to their trademark.

Registries usually allow multiple applications for a particular domain name during launch phases. This extension helps to resolve such situations by means of an auction in an automated way. This is not a normal auction, however, insofar as every application has a ʺbidʺ associated with it. Bids cannot be modified after the phase the application belongs to has ended. Among all valid applications for a given domain name, the one with the highest bid wins the auction.


5.2.2 Object Attributes

This extension for auctions adds additional elements to the EPP domain name mapping. Only new element descriptions are documented here.

This extension allows the provisioning of auction information in the form of bids. A bid can be made when applying for a domain name. In case there is more than one valid application, an auction mechanism is used as a tie-breaker. The highest bid submitted for the domain name in question will win the auction.


5.2.2.1 Bid

The ʺauction:bidʺ element is used to set and inform about a bid for a domain name. Its content is the amount of money the applicant is willing to pay for the domain name in case of an auction. The currency is given in the required currency attribute, specified by the corresponding ISO 4217 currency code.

Note that the amount is given as a non-negative number. This allows to submit a bid of zero in case the applicant is not interested in an auction at all.


5.2.3 EPP Command Mapping

This section deals with the specific command mappings for the .radio registry EPP extension for auctions.


5.2.3.1 EPP Query Commands

There are four EPP commands to retrieve object information: ʺcheckʺ to find out whether an object is known to the server, ʺinfoʺ to ask for detailed information associated with an object, ʺpollʺ to discover and retrieve queued service messages for individual clients and ʺtransferʺ to get transfer status information for an object.


5.2.3.1.1 EPP ʺcheckʺ Command

This extension does not add any elements to the EPP ʺcheckʺ command or to the ʺcheckʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.1.2 EPP ʺinfoʺ Command

This extension does not add any elements to the EPP ʺinfoʺ command described in the EPP domain mapping. Additional elements are defined for the ʺinfoʺ response.

When an ʺinfoʺ command has been processed successfully, the EPP ʺextensionʺ element in the response, if present, contains a child ʺauction:infDataʺ element that identifies the registry auction namespace and the location of the registry auction schema. The ʺauction:infDataʺ element contains an ʺauction:bidʺ element, which informs about the amount and currency of the currently set bid as described above.

An example of an ʺinfoʺ response can be found in attachment Q25-Ext-Auction.pdf, Section 2.1. EPP ʺinfoʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example simply retrieves the current bid for the given domain name.


5.2.3.1.3 EPP ʺpollʺ Command

This extension does not add any elements to the EPP ʺpollʺ command or to the ʺpollʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.1.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2 EPP Transform Commands

There are five EPP commands to transform objects: ʺcreateʺ to create an instance of an object, ʺdeleteʺ to delete an instance of an object, ʺrenewʺ to extend the validity period of an object, ʺtransferʺ to manage object sponsorship changes and ʺupdateʺ to change information associated with an object.


5.2.3.2.1 EPP ʺcreateʺ Command

This extension defines additional elements to extend the EPP ʺcreateʺ command described in the EPP domain mapping for auction processing. No additional elements are defined for the ʺcreateʺ response.

The EPP ʺextensionʺ element of the ʺcreateʺ command contains a child ʺauction:createʺ element to indicate that auction information should be submitted. It identifies the registry auction namespace and the location of the registry auction schema. The ʺauction:createʺ element must contain an ʺauction:bidʺ element, which specifies the amount and currency as described above.

An example of a ʺcreateʺ command can be found in attachment Q25-Ext-Auction.pdf, Section 2.2. EPP ʺcreateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example sets the bid when applying for the given domain name to the specified amount.


5.2.3.2.2 EPP ʺdeleteʺ Command

This extension does not add any elements to the EPP ʺdeleteʺ command or to the ʺdeleteʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2.3 EPP ʺrenewʺ Command

This extension does not add any elements to the EPP ʺrenewʺ command or to the ʺrenewʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2.5 EPP ʺupdateʺ Command

This extension defines additional elements to extend the EPP ʺupdateʺ command described in the EPP domain mapping for auction processing. No additional elements are defined for the ʺupdateʺ response.

The EPP ʺextensionʺ element of the ʺupdateʺ command contains a child ʺauction:updateʺ element to indicate that auction information should be updated. It identifies the registry auction namespace and the location of the registry auction schema. The ʺauction:updateʺ element must contain an ʺauction:bidʺ element, which specifies the new amount and currency as described above.

Whether all modifications of bids are allowed, only certain ones (e.g. only increases) or none at all depends on the .radio registry auction policy, which is described elsewhere.

An example of an ʺupdateʺ command can be found in attachment Q25-Ext-Auction.pdf, Section 2.3. EPP ʺupdateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example modifies the bid for the given domain name.


5.2.4 Formal Syntax

The formal syntax of this EPP extension is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The schema definition is listed in attachment Q25-Ext-Auction.pdf, Section 1. Schema Definition (Formal Syntax), since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.3 Extension for Language Information

The CORE Registration System used to operate the .radio registry provides a proprietary EPP extension for internationalised domain names (IDNs).


5.3.1 Introduction

This part of this answer desribes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730. This mapping is an extension of the domain name mapping described in RFC 5731. It is specified using the Extensible Markup Language (XML) and XML Schema notation.

This extension serves the purpose of supplying and querying information for internationalised domain names. In particular, the language or script used and domain name variants are addressed.


5.3.2 Object Attributes

This extension for IDNs adds additional elements to the EPP domain name mapping. Only new element descriptions are documented here.


5.3.2.1 Languages and Scripts

This extension allows the specification of either a language tag or a script tag when registering a domain name. The language or script defines the characters allowed for use in the domain name as specified in the IDN tables (see Question 44, Support for Registering IDN Domains). It is not allowed to specify more than one language or more than one script.

For the time being, the .radio registry expects the value of a language tag element to be a an ISO 639-1 language code referring to a supported language. The value of a script tag is expected to be an ISO 15924 script code referring to a supported script.


5.3.2.2 Variants

This extension allows to specify a number of variants of the domain name to be registered together with the supplied domain name. The variants are expected to be submitted in normalised form (see also Q44, Support for Registering IDN domains). The number of variants that can be specified is limited to at most 10.


5.3.3 EPP Command Mapping

This section deals with the specific command mappings for the .radio registry EPP extension for IDNs.


5.3.3.1 EPP Query Commands

There are four EPP commands to retrieve object information: ʺcheckʺ to find out whether an object is known to the server, ʺinfoʺ to ask for detailed information associated with an object, ʺpollʺ to discover and retrieve queued service messages for individual clients and ʺtransferʺ to get transfer status information for an object.


5.3.3.1.1 EPP ʺcheckʺ Command

This extension defines additional elements to extend the EPP ʺcheckʺ command described in the EPP domain mapping for IDN processing. No additional elements are defined for the ʺcheckʺ response.

The EPP ʺcheckʺ command is used to determine if an object can be provisioned within a repository. This IDN extension modifies base check processing to support language and script tags.

The EPP ʺextensionʺ element, if present, contains a child ʺidn:checkʺ element that identifies the registry IDN namespace and the location of the registry IDN schema. If at least one of the checked domains is an IDN, the ʺidn:checkʺ element must contain either an ʺidn:langʺ element or an ʺidn:scriptʺ element. The ʺidn:langʺ element contains the language whose characters may be used in the checked domain names; the ʺidn:scriptʺ element contains the script whose characters may be used in the checked domain names. The language or script specification applies to all domain names specified in the command. The results of the check (i.e., the domains namesʹ availability for provisioning) are governed by the validity of the names with respect to the specified language or script.

Examples of ʺcheckʺ commands can be found in attachment Q25-Ext-IDN.pdf, Section 2.1. EPP ʺcheckʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. Two examples are included, one with a language tag (Section 2.1.1), one with a script tag (Section 2.1.2).


5.3.3.1.2 EPP ʺinfoʺ Command

This extension does not add any elements to the EPP ʺinfoʺ command described in the EPP domain mapping. Additional elements are defined for the ʺinfoʺ response.

When an ʺinfoʺ command has been processed successfully, the EPP ʺextensionʺ element in the response, if present, contains a child ʺidn:infDataʺ element that identifies the registry IDN namespace and the location of the registry IDN schema. The ʺidn:infDataʺ element contains either an ʺidn:langʺ element or an ʺidn:scriptʺ element. The ʺidn:langʺ element contains the language that is set for the domain name object; the ʺidn:scriptʺ element contains the script that is set for the domain name object.

The ʺidn:infDataʺ element also contains an ʺidn:variantsʺ element, which in turn contains a (possibly empty) sequence of ʺidn:nameVariantʺ elements. The ʺidn:nameVariantʺ elements represent the variants that are registered together with the actual domain name.

Examples of ʺinfoʺ responses can be found in attachment Q25-Ext-IDN.pdf, Section 2.2. EPP ʺinfoʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. Three examples are included, one with a language tag only (Section 2.2.1), one with a script tag only (Section 2.2.2) and one with a language tag and variants (Section 2.2.3).


5.3.3.1.3 EPP ʺpollʺ Command

This extension does not add any elements to the EPP ʺpollʺ command or to the ʺpollʺ response described in the EPP domain mapping (s. RFC 5731).


5.3.3.1.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2 EPP Transform Commands

There are five EPP commands to transform objects: ʺcreateʺ to create an instance of an object, ʺdeleteʺ to delete an instance of an object, ʺrenewʺ to extend the validity period of an object, ʺtransferʺ to manage object sponsorship changes and ʺupdateʺ to change information associated with an object.


5.3.3.2.1 EPP ʺcreateʺ Command

This extension defines additional elements to extend the EPP ʺcreateʺ command described in the EPP domain mapping for IDN processing. No additional elements are defined for the ʺcreateʺ response.

The EPP ʺcreateʺ command provides a transform operation that allows a client to create an instance of a domain object. This IDN extension modifies base create processing to support language tags, script tags and domain name variants.

The EPP ʺextensionʺ element, if present, contains a child ʺidn:createʺ element that identifies the registry IDN namespace and the location of the registry IDN schema. The ʺidn:createʺ element must contain either an ʺidn:langʺ element or an ʺidn:scriptʺ element. The ʺidn:langʺ element contains the language whose characters may be used in the domain name; the ʺidn:scriptʺ element contains the script whose characters may be used in the domain name.

The ʺidn:createʺ element must also contain an ʺidn:variantsʺ element, which in turn contains a (possibly empty) sequence of ʺidn:nameVariantʺ elements. The ʺidn:nameVariantʺ elements represent the variants that are to be registered together with the actual domain name.

Note that the .radio registry restricts the number of domain name variants given in the ʺidn:variantsʺ element to at most 10. Submitting an empty ʺidn:variantsʺ element is allowed; this will not register any domain name variants.

Examples of ʺcreateʺ commands can be found in attachment Q25-Ext-IDN.pdf, Section 2.3. EPP ʺcreateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. Three examples are included, one with a language tag only (Section 2.3.1), one with a script tag only (Section 2.3.2) and one with language tags and variants (Section 2.3.3).


5.3.3.2.2 EPP ʺdeleteʺ Command

This extension does not add any elements to the EPP ʺdeleteʺ command or to the ʺdeleteʺ response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2.3 EPP ʺrenewʺ Command

This extension does not add any elements to the EPP ʺrenewʺ command or to the ʺrenewʺ response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2.4 EPP ʺtransferʺ Command

This extension does not add any elements to the EPP ʺtransferʺ command or to the ʺtransferʺ response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2.5 EPP ʺupdateʺ Command

This extension defines additional elements to extend the EPP ʺupdateʺ command described in the EPP domain mapping for IDN processing. No additional elements are defined for the ʺupdateʺ response.

The EPP ʺupdateʺ command provides a transform operation that allows a client to change the state of a domain object. This IDN extension modifies base update processing to support domain name variants.

The EPP ʺextensionʺ element, if present, must contain a child ʺidn:updateʺ element that identifies the registry IDN namespace and the location of the registry IDN schema. The ʺidn:updateʺ element may contain an ʺidn:addʺ element and an ʺidn:remʺ element. Each of these contain a (possibly empty) sequence of ʺidn:nameVariantʺ elements. Similar to the ʺupdateʺ commandʹs elements ʺdomain:addʺ and ʺdomain:remʺ, these are used to specify the domain name variants that are to be added to and removed from the domain object, respectively. If the EPP ʺextensionʺ element is missing in the ʺupdateʺ command, no change to the domain name variants will be made.

Note that the .radio registry restricts the number of domain name variants given in the ʺidn:addʺ and ʺidn:remʺ elements to at most 10.

An example of an ʺupdateʺ command can be found in attachment Q25-Ext-IDN.pdf, Section 2.4. EPP ʺupdateʺ command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example adds some variants to be associated with the given domain name while removing existing ones at the same time (Section 2.4.1).


5.3.4 Formal Syntax

The formal syntax of this EPP extension is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The schema definition is listed in attachment Q25-Ext-IDN.pdf, Section 1. Schema Definition (Formal Syntax), since the TLD Application System (TAS) is not well suited to pre-formatted text.


6. Resourcing plans


6.1 Initial Work

No resources are necessary for the initial implementation, since the CORE Registration System (including the EPP extensions) has already been implemented.


6.2 Ongoing Work

For registrar support regarding the EPP extensions, the following resource allocations are estimated:

First Level Support: 4 man hours per month.

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.