⚠️ TAKE NOTICE! ⚠️

This RFC is no longer being updated, the proposed changes have been implemented.

Please refer to the EPP Service Specification and the Registrar Portal Service Specification for details.

DKHM RFC for Delete Domain EPP Command

2020-11-23 Revision: 1.4

Introduction
Description
- Delete and Scheduling Deletion
- Restore
XSD Definition
References

Introduction

This is a draft and proposal for changes to the process for domain name deletion via the DK Hostmaster EPP portal/service. The specification briefly touches on the registrar portal service, which mimicks the EPP service for consistency.

The overall description of the concept of the registrar model offered by DK Hostmaster A/S provided as a general overview, where this RFC digs into the details of the cancellation/deletion of domain names in the context of an implementation proposal.

About this Document

We have adopted the term RFC (Request For Comments), due to the recognition in the term and concept, so this document is a process supporting document, aiming to serve the purpose of obtaining a common understanding of the proposed implementation and to foster discussion on the details of the implementation. The final specification will be lifted into the DK Hostmaster EPP Service Specification implementation and this document will be closed for comments and the document no longer be updated.

This document is not the authoritative source for business and policy rules and possible discrepancies between this an any authoritative sources are regarded as errors in this document. This document is aimed at the technical specification and possible implementation and is an interpretation of authoritative sources and can therefor be erroneous.

License

This document is copyright by DK Hostmaster A/S and is licensed under the MIT License, please see the separate LICENSE file for details.

Document History

1.4 2020-11-23
- Removal of restoration information, which has been collected in a separate RFC
- Addition of additional links to resources
- Correction to links pointing to redundant resources
- Minor rephrasing and clarifications
1.3 2020-09-17
- Addition of disclaimer
1.2 2020-09-17
- Added information on restore as described in RFC:3915 and RFC:8748
1.1 2020-09-01
- Clarification on deletion and handling of subordinates, as specified in RFC:5731
1.0 2020-08-25
- Initial revision

XML and XSD Examples

All example XML files are available in the DK Hostmaster EPP XSD repository.

The proposed extensions and XSD definitions are available in version 4.0 of the DK Hostmaster XSD, which is marked as a pre-release.

The referenced XSD version is not deployed at this time and is only available in the EPP XSD repository, it might be surpassed by a newer version upon deployment of the EPP service implementing the proposal, please refer to the revision of EPP Service Specification describing the implementation.

Description

Delete and Scheduling Deletion

In addition to the standard EPP delete domain command, DK Hostmaster will support scheduling of deletion of domain names, by providing a date to the EPP delete domain command via an optional extension.

The default is to deactivate immediately if possible, which complies with RFC:5731. Not being able to complete the request will result in a error, also in compliance with RFC:5731. Please see below for more information on the business process for deletion.

The extension offers the ability to specify a date, this date will have to be in the future and prior to, or on the expiration date of the specified domain name.

The current expiration date can be obtained using the info domain command and is specified in the domain:exDate field. The date conforms with the required format.

An example (do note the dates in the below examples are examples and are fabricated and might not be correct, meaning they might be in the past by the time of reading):

  <extension>
    <dkhm:delDate xmlns:dkhm="urn:dkhm:xml:ns:dkhm-3.2">2021-01-31T00:00:00.0Z</dkhm:delDate>
  </extension>

The date follows the format used in the EPP protocol, which complies with RFC:3339.

The XSD for the extension look as follows:

  <!-- custom: delDate  -->
  <simpleType name="delDate">
    <restriction base="dateTime" />
  </simpleType>

Ref: dkhm-4.0.xsd

⚠️ The reference and file mentioned above is not released at this time, so this file might be re-versioned upon release.

The complete command will look as follows (example lifted from RFC:5731):

<?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>eksempel.dk</domain:name>
          </domain:delete>
      </delete>
      <clTRID>ABC-12345</clTRID>
    </command>
  </epp>

And the complete command with a deletion date specification (example lifted from RFC:5731 and modified):

<?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>eksempel.dk</domain:name>
          </domain:delete>
      </delete>
      <extension>
        <dkhm:delDate xmlns:dkhm="urn:dkhm:xml:ns:dkhm-4.0">2021-01-31T00:00:00.0Z</dkhm:delDate>
      </extension>
      <clTRID>ABC-12345</clTRID>
    </command>
  </epp>

Domain names are not deleted immediately, but are flagged as scheduled for deletion. This of the delete command is successful, the domain name will be flagged for deletion within the timeframe specified by the business rules implemented by DK Hostmaster.

The scheduling of a future delete date supports the handling of automatic renewal or expiration as outlined in "DKHM RFC for handling of Automatic Renewal and Expiration".

The response for a delete domain command will be 1001.

Response example (example lifted from RFC:5731 and modified):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  <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>54321-XYZ</svTRID>
      </trID>
    </response>
  </epp>

The expiration date will be adjusted accordingly and a status pendingDelete with an advisory date will be applied and made available via the response to the info domain command, via the DK Hostmaster extension: domainAdvisory.

Example:

<extension>
    <dkhm:domainAdvisory advisory="pendingDeletionDate" date="2021-01-31T00:00:00.0Z" domain="eksempel.dk" xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.0"/>
</extension>

In the RFC outlining automatic renewal "DKHM RFC for handling of Automatic Renewal and Expiration", it is described that a delete domain command will disable auto renewal if enabled. Please see the RFC for more details.

Do note that if subordinates exist these will block for a delete and the request will result in an error: 2305.

Restore

As described in RFC:3915, with a support for grace periods, it is possible to restore a domain name scheduled for deletion, (in the state pendingDelete).

The ability to restore a domain from a suspended state, is mentioned in the introduction as a billable operation.

The proposal for the restore implementation is outlined in the separate RFC: "DKHM RFC for Restore Command".

XSD Definition

This XSD definition is for the proposed extension dkhm:delDate, which is used to communicate a deletion date differing from the default via the delete domain request.

  <!-- custom: delDate  -->
  <simpleType name="delDate">
    <restriction base="dateTime" />
  </simpleType>

Example (lifted from above):

  <extension>
    <dkhm:delDate xmlns:dkhm="urn:dkhm:xml:ns:dkhm-4.0">2021-01-31T00:00:00.0Z</dkhm:delDate>
  </extension>