25 Extensible Provisioning Protocol (EPP)

Prototypical answer:

gTLDFull Legal NameE-mail suffixDetail
.amsterdamGemeente Amsterdamamsterdam.nlView

25 EPP

All core registry services for .amsterdam will be provided by .amsterdam’s back end provider SIDN. SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD.

The Shared Registration System for .amsterdam is cloned from SIDN’s registration system for .NL and offers an EPP-interface and a web interface. Both interfaces are available to all accredited registrars and offer the same functionality.

The EPP interface is based on the following standards:
- Guidelines for Extending the Extensible Provisioning Protocol (EPP) - RFC3735 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3735.txt),
- Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) RFC 3915 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3915.txt),
- Extensible Provisioning Protocol (EPP) - RFC5730 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5730.txt),
- Extensible Provisioning Protocol (EPP) Domain Name Mapping - RFC5731 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5731.txt),
- Extensible Provisioning Protocol (EPP) Host Mapping - RFC5732 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5732.txt),
- Extensible Provisioning Protocol (EPP) Contact Mapping - RFC5733 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5733.txt),
- Extensible Provisioning Protocol (EPP) Transport over TCP - RFC5734 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5734.txt) and
- Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) - RFC5910 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5910.txt)

The EPP interface maximizes the amount of simultaneous connections per registrar to eight. Only SIDN-authorized networks⁄interfaces can connect to the EPP interface. Connections will be closed:
- After being idle for 10 minutes;
- After being open for 24 consecutive hours;
- Upon receiving a ‘logout’ command.

Per session, multiple XML forms may be sent (containing one command per form, pipelining not possible). EPP commands are processed by the SRS in the sequence in which they are received. All commands are executed immediately and an immediate response containing the execution result is returned.

25.1 EPP objects and commands
EPP is used to create or edit three types of objects: domain names, contact persons and name servers. The object domain name refers to existing contact persons (registrant, administrative contact and technical contact) and name servers.

The SRS supports the following EPP commands:
Sessions
Hello⁄greeting
Login
Logout
Poll
Domain names
Domain check
Domain info
Domain create
Domain update
Domain delete
Domain transfer
Domain renew
Contact persons
Contact check
Contact info
Contact create
Contact update
Contact delete
Name servers
Host check
Host info
Host create
Host update
Host delete

25.2 Configuration Settings

clTRID
The clTRID element can be used with all commands in order to link the registrars’ identification to the command. When responding to this command, SRS sends this value back. The value for this element is freeform and should be unique. No checking is performed on this field by the registry.

Domain object
- Domain.ns: The ‘hostObj’ implementation is chosen for authoritative name servers for a domain name. The number of authoritative name servers has been limited to a maximum of thirteen but can be left empty. A domain should have a minimum of 2 name servers before the domain name is published in the zone.
- Domain.registrant: The registrant attribute is mandatory.
- Domain.contact: Only the ‘admin’ and ‘tech’ contact person types are supported and the following additional rules apply:
- a minimum of one and a maximum of one ‘admin’ must be submitted for a domain name
- a minimum of one ‘tech’ must be submitted for a domain name
- Domain.authInfo: The authInfo attribute is only used in the transfer procedure. Consequently, this attribute is only used in the Domain transfer (op=“request”) command and it is also issued in the response message to the Domain info command and in the response message after a successful transfer.
Note: this attribute is mandatory in the Domain.create command in EPP and will be filled with a value generated automatically by the SRS (see ‘Proprietary EPP Extension’).
- Domain.status: The following contact domain statuses are not used in the SRS:
- PendingUpdate
- PendingRenew
- PendingRestore. The domain name status ‘pendingRestore’ is not used in the SRS, since a restore report is a mandatory element of the restore-command.

Contact object
- Contact.name: In the EPP standards, the name is part of the «postalInfo» group. Both localized (unrestricted UTF-8) or internationalized (a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set) forms may be used for this group. The SRS implementation only allows one format (unrestricted UTF-8) for a name in order to avoid a situation where different names for the contact person are included in both formats.
- Contact.org: In the EPP standards, this field is reserved for the name of the organization. In the SRS implementation, however, it has been decided to use this field for the name of the department with which the contact person is associated (affiliated). The proprietary EPP extension contains two fields to describe legal registration information of companies (see ‘proprietary EPP extension’ below) and the organizations’ name is to be provided in Contact.name.
- In the EPP standards, the «org» attribute is part of the «postalInfo» group. Both localized (unrestricted UTF 8) or internationalized (a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set) forms may be used for this group. The SRS implementation only allows one format (unrestricted UTF-8) for the name in order to avoid a situation where different names are included in both formats.
- Contact.status: The following contact person statuses are not used in the SRS:
- clientDeleteProhibited
- clientTransferProhibited
- clientUpdateProhibited
- pendingCreate
- pendingDelete
- pendingTransfer
- serverDeleteProhibited
- serverTransferProhibited
- serverUpdateProhibited
Consequently, the responsible registrar is also unable to set ‘client’ statuses.
- Contact.postalinfo: A maximum of 1 is allowed. Only type=ʺlocʺ is supported.
- Contact.street: A maximum of 1 is allowed. A PO Box may not be entered in the first street tag.
- Contact.sp: The optional state⁄province attribute is not implemented.
- Contact.pc: This field is mandatory if country code “NL” is used. In this case, the postal code must always start with four digits and end in two letters (regular expression: ʺ[0-9]{4}[A-Z]{2}ʺ).
- Contact.voice: The telephone number is mandatory.
- Contact.trDate: This attribute is not implemented, since contact persons cannot be transferred in the SRS.
- Contact.authInfo: This attribute is not implemented, since contact persons cannot be transferred in the SRS.
Note: this attribute is mandatory in the Contact create command in EPP and will be filled with a value generated automatically by the SRS.
- Contact.disclose: This attribute is not implemented. Only the sponsoring client (responsible registrar) and the server (SIDN) may view the information for a contact person in the SRS.
- Contact.id: The submitted value of this attribute will be ignored in the SRS and the server will automatically generate an ID (= handle). The handle that is generated by SIDN follows the format XXX999999-YYYYY (regular expression: [A-Z]{3}[0-9]{6}[-][A-Z0-9]{5}). The first part of this handle is used to identify the contact. The second part is used to identify the maintaining registrar. If a domain name is transferred, all related contacts are copied to a new contact maintained by the gaining registrar. In that case, the contact-identifying part of the handle is unchanged and the registrar-identifying part is updated to reflect the new maintainer.

Host object
- Host.status: The following name server statuses are not used in the SRS:
- clientDeleteProhibited
- clientUpdateProhibited
- serverDeleteProhibited
- serverUpdateProhibited
- pendingCreate
- pendingDelete
- pendingTransfer
Consequently, the responsible registrar is also unable to set «client» statuses.
- Host.name: The name for a name server cannot be updated in the SRS. Consequently, the chg attribute is not implemented in the Host update command.
- Host.IP-adres: The number of IP addresses has been limited to a maximum of ten.
- secDNS.keyData: The Key Data Interface is chosen, implementing ‘secDNS.keyData’. As a consequence secDNS.dsData is not supported.
- secDNS.maxSigLife: This optional attribute is not implemented.

25.3 Proprietary EPP extension
SIDN provides a proprietary EPP extension (compliant with RFC 3735). The extension scheme is provided in the attachment ‘Q25-sidn-ext-epp-1.0.xsd’.
Since the proprietary extension is also used for registration of other TLD’s, including .NL domains, there may some elements present that are only in use for those TLD’s and will be ignored for .amsterdam. At the moment of writing, this is the case for elements containing the field ‘optOut’ (used for shielding privacy sensitive information in the .NL-Whois) and fields in the element ‘trnData’ (used in messages regarding escalation of transfers through the registry for .NL). Since .amsterdam is aimed at the same audience as .NL, we strive for an alignment in registry services and EPP-commands, however, if various policies lead to an unclear extension, we will decide to split the xsd to support only .amsterdam functionality.

This extension contains elements for the legal registration of companies in The Netherlands. This information specific to the Dutch market and relevant to the .amsterdam TLD.

The proprietary extension also contains a status element ‘limited’. This status is a more fine-grained setting of the ‘serverProhibited’ status, allowing for:
- Prohibition of changes to parts of an object (e.g. a domain object can be updated, but the registrant cannot be changed);
- Authorization of commands before execution by Registry Operator (a command is validated before being accepted or denied).
This status is used for controlling the registrant of specific reserved domains where a validated registrant may not be changed, but contact details for the registrant may be updated as needed by the registrar.
The EPP interface will show if the status ‘limited’ is present for objects and indicates that a command for this object will be rejected or pended. It doesn’t show the various types of this status used internally by the registry and the specific consequences involved.

To facilitate various specific TLD policies for transferring domain names (including .NL, where transfer policy compliancy is supported by escalation procedures at the registry), the SRS generates unique values for the authInfo attribute upon creation of the object. These values are reset and generated anew when the following transactions occur: transfer, restore by non-maintaining registrar, registrant update and bulk transfer. A reset and regeneration of this value can be requested by the registrar-of-record at any time through the regular support channels.


Proprietary extension attributes and elements
- Domain info
Extension for status limited in response message
- Domain cancelDelete
Message extension used for .NL
- Domain transfer (op = ʺrequestʺ)
Extension for authInfo-value (“pw”) in response message
- Contact info
Extension for legal form, registration number and limited in response message
- Contact create
Extension for legal form and registration number
- Contact update
Extension for legal form and registration number
- Host info
Extension for limited in response message
- All
Extension for message with field, code and message in response messages


25.4 Resources
SIDN is based in Arnhem, the Netherlands and has a total staff of 73 people employed, most of them entirely dedicated to .nl services. As back end registry operator of .amsterdam SIDN will provide all technical registry services on the basis of the .nl-infrastructure. This infrastructure is maintained by SIDN’s Technical Division that consist of a total staff of 26 under a dedicated manager who is a member of SIDN’s Management Team. The Technical Division is divided into 4 groups: ICT Operations, Software Development, Application Development and a Test Team.
For the services to .amsterdam the main resources will be drawn from the team ICT Operations. This team currently consists of 10 staff responsible for the 24x7 uptime of the .nl registration system including the network infrastructure and the DNS servers. From this team, every week, two persons are on 24x7 duty. Also, two persons are on 10x5 duty to handle regular service requests and the daily maintenance of systems and applications. This team will be extended with at least two new people before the end of this year. ICT Operations manages further an external company that is responsible for the daily maintenance (including monitoring, incident, problem and change management) of the databases.

Next to the Development Team (10 staff responsible for the software development at SIDN), SIDN has a dedicated Test Team of 4 staff. All members are ISQTB certified (http:⁄⁄www.istqb.org⁄). The Test Team tests all software through functional application testing and regression testing. The Test Team also supports end users with acceptance testing.

SIDN therefore has all necessary resources on hand to provide all services described in this answer.

Similar gTLD applications: (2)

gTLDFull Legal NameE-mail suffixzDetail
.overheidnlministery of the Interior and Kingdom Relationsminbzk.nl-3.28Compare
.politiePolitie Nederlandvtspn.nl-3.22Compare