/DKHM-RFC-CLID

Request For Comments for EPP Create Domain Specification Draft for DK Hostmaster

MIT LicenseMIT

DK Hostmaster Logo

DKHM RFC for Client ID support for EPP

Markdownlint Action Spellcheck Action

Table of Contents

Introduction

This is a draft and proposal for implementation of the process for domain name and contact creation via the DK Hostmaster EPP portal/service. The specification briefly touches on the registrar portal service (RP), 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 Client-ID in the context of an implementation proposal.

The registrar model offered by DK Hostmaster, gives registrars the option to manage a customer’s .dk domain name if the customer would prefer this. We call this "registrar management". Where the model to allow the customer to manage their own domain name themselves, as they do today, is referred to as "registrant management".

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.

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 the 3.2 candidate of the DK Hostmaster XSD, which is currently a draft and work in progress and marked as a pre-release.

Description

DK Hostmaster are extending the registry capabilities to support one-stop-shop so registrars and registrants will have the option to pick the model for domain name administration with suit their requirements.

As for the proposal for support for the EPP transfer command, described in the RFC: "DKHM RFC for Transfer Domain EPP Command", support for specifying the sponsoring client has to be supported for several of the EPP commands:

  • create domain
  • create contact
  • create host

The goal is to support the standard to the extent possible. Changing the behavior might not suit everybody and this proposal aims to address this particular challenge.

Domain Creation, Maintenance and Deletion

The default behavior of the EPP create domain command as described in RFC:5731, will attach the client-ID (CLID) of the authenticated party to the object created.

Having the client-ID specified at this time indicates that the domain name is under registrar management from creation. To change the registrar and discontinue the registrar management will require a transfer, as described in the RFC: "DKHM RFC for Transfer Domain EPP Command".

If the registrar does not want to create domains under registrar management the default behaviour can be defined in RP, where the available are:

  • registrar management
  • registrant management

The setting will be global and will influence the behaviour in both:

  • EPP
  • RP

These settings are controlling the account as a whole for all relevant commands.

  • create domain, this section
  • create contact, described below
  • create host, described below

Contact Creation, Maintenance and Deletion

The default behavior of the EPP create contact command as described in RFC:5733, will attach the client-ID (CLID) of the authenticated party to the object created, just as for the domain creation described above.

The contact object will be under the sponsoring party throughout it's life-cycle and transfer of contact objects will not be explicitly supported. See our proposal for transfer support described in our RFC: "DKHM RFC for Transfer Domain EPP Command".

As for the create domain command (above) the default behaviour can be defined in RP. Where the option "registrant management", will create contact objects sponsored by DK Hostmaster instead instead of the registrar.

Deletion will not be supported and will work as it currently is implemented in the DK Hostmaster EPP service and described in the specification. See the section: "Unimplemented commands" for details. Contact objects are automatically delete, under the following policy:

  • The contact object is not in use
  • It holds not roles/association with other objects
  • The associated financial account holds a balance of 0
  • It has been inactive for 45 days

The maintenance, meaning changes and updates to data, will also be limited. DK Hostmaster locks contact objects for changes if these have been matched to a register for name and address information, this applies to:

  • Danish citizens of the type individual, bound to the CPR register
  • Danish companies, public organizations and associations of the types, bound to the CVR register

The following contact types are also limited, due to the VAT number validation:

  • EU companies, public organizations and associations of the types, bound to the EU Vies register

All other types has to be maintained by the sponsoring client, with the exception of the name attribute.

Host Creation, Maintenance and Deletion

The default behavior of the EPP create host command as described in RFC:5732, will attach the client-ID (CLID) of the authenticated party to the object created.

The create host command will be limited in that sense that it will not be possible to create a host object, which is subordinate to a domain name (superordinate), which is sponsored by another registrar. This limitation will only be enforced for domain names under the .dk TLD. All domain names under other TLDs will be subject to this limitation.

As for the create domain and create contact commands (above) the default behaviour can be defined in RP. Where the option "registrant management", will create host objects sponsored by DK Hostmaster instead of the registrar.

Responsibility and privileges for maintenance (update host) of the host object is assigned to the name server administrator as described in the DK Hostmaster EPP Service specification.

If the name server responsible is allocated to the registrar account (group), this can be handled via RP and EPP.

The deletion of host objects are under a similar regime, as specified in the DK Hostmaster EPP Service specification.

Visibility of Client ID

As specified in RFC:5731, [RFC:5732][RFC:5732] and [RFC:5733][RFC:5733] the info commands all display a reference sponsoring entity.

The same scheme will be implemented in RP and the end-user self-service portal (SB) the data presentation is consistent across portals.

The public facing interface is expected to present the registrar relation as well. Meaning that the information on registrar relation will be made available:

References