Domain Suggestion Extension for the Extensible Provisioning Protocol (EPP)
draft-mayrhofer-epp-domain-suggest-00

Abstract

This document specifies an EPP Extension that allows servers to suggest available domain names to clients, for example in cases where the originally desired domain name is unavailable for registration.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 4, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Domain Name Suggestion Structure
• 4. Client and Server Behaviour
• 5. EPP Command Mapping
• 5.1. EPP <check> Query Command
• 6. Open Questions
• 7. Formal Syntax
• 8. Security Considerations
• 9. IANA Considerations
• 9.1. Namespace
• 9.2. XML Schema
• 10. Changelog
• 10.1. mayrhofer-epp-domain-suggestion-00
• 11. Normative References
• Appendix A. Acknowledgments
• Author's Address

1. Introduction

The Extensible Provisioning Protocol (EPP) [RFC5730] is a client-server protocol for provisioning and managing objects in shared repositories. In many cases, EPP is used to provision Domain Names between Registrars and Domain Name Registries (see [RFC5731]).

EPP provides the “check” query command to determine whether an object can be provisioned with a registry. That command is typically used to determine whether a certain domain name is available for registration at a Domain Name Registry. In case a requested domain name is not available for registration, it is desirable to suggest alternative, available names to the client. However, EPP does currently not contain data structures suitable to transport such “Domain Suggestions”.

This document specifies a Command-Response level EPP extension for the EPP Domain Mapping [RFC5731], allowing servers to include such Domain Suggestions in responses to EPP “<domain:check>” commands.

2. Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.

In examples, “C:” represents lines sent by a protocol client and “S:” represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this protocol.

“ds” is used as a namespace abbreviation for “urn:ietf:params:xml:ns:epp:domainSuggest-1.0”, and “domain” is used as an abbreviation for “urn:ietf:params:xml:ns:epp:domain-1.0”. The XML namespace prefix “ds” is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents.

3. Domain Name Suggestion Structure

In order to convey domain name suggestions, the following XML structure is defined:

• A <ds:suggestions> element for use in responses, containing one or more <ds:name> elements
• Each <ds:name> element contains a suggested (available) fully qualified domain name, and an OPTIONAL “for” attribute.
• If present, the “for” attribute of the <ds:name> element MUST contain a domain name given in one of the <domain:name> elements of the corresponding command. This allows a client to correlate suggestions with originally requested names when multiple names were given in the command.

4. Client and Server Behaviour

• A client MUST indicate support for the “urn:ietf:params:xml:ns:epp:domainSuggest-1.0” in the “<login>” command in order to receive suggestions
• When a client indicates support for the extension, it is local server policy if and when suggestions are provided.
• When a server attempts to provide suggestions, but fails to do so for the set of given names, it SHOULD indicate that situation with an empty <ds:suggestions> element in the response.
• A server SHOULD NOT suggest domain names which are unavailable for registration.
• A client hence SHOULD assume that suggested names are available for registration, without the need for an additional <check> command for those names.
• Servers SHOULD gracefully handle situations where generation of suggestions triggers errors, and continue to process the base EPP command.
• Servers MAY also give suggestions even if the originally requested name is available.

5. EPP Command Mapping

The only command extended is the <domain:check> command.

5.1. EPP <check> Query Command

This extension does not add any elements to the EPP <check> command described in the EPP Domain Mapping [RFC5731]. However, additional elements are defined for the <check> response:

When a <check> command has been processed succesfully, the EPP <extension> element MAY contain a child <ds:suggestions> element, structured as described above.

Example <check> response:

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>
   S:    </result>
   S:    <resData>
   S:      <domain:chkData
   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:cd>
   S:          <domain:name avail="1">example.com</domain:name>
   S:        </domain:cd>
   S:        <domain:cd>
   S:          <domain:name avail="0">example.net</domain:name>
   S:          <domain:reason>In use</domain:reason>
   S:        </domain:cd>
   S:        <domain:cd>
   S:          <domain:name avail="1">example.org</domain:name>
   S:        </domain:cd>
   S:      </domain:chkData>
   S:    </resData>
   S:    <extension>
   S:      <ds:suggestions
   S:       xmlns:ds="urn:ietf:params:xml:ns:domainSuggest-1.0">
   S:        <ds:name for="example.net">my.example.net</ds:name>
   S:        <ds:name for="example.com">wedosubdomains.example.com</ds:name>
   S:        <ds:name>betterexample.tld</ds:name>
   S:      </ds:suggestions>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

6. Open Questions

[Note to RFC Editor: Do not publish this document before that section is empty :) ]

The following issues need to be solved / discussed before the extension can be deemed stable:

• Shall there be an element in the commands to explicitly request suggestions (<ds:yesplease>).
• Corner Case: Can error responses contain suggestions? Eg. when a domain in an unsupported TLD is given?
• Shall suggestions be allowed in other commands?
• More mechanics for handling keywords (back and forth?)
• Allow conveyance of user location? Tricky, involves handling PII data…
• Maximum number of suggestions? Order / weight of suggestions?

7. Formal Syntax

TODO: Create Schema once structure of extension is stable.

8. Security Considerations

At this stage of the document, Security Considerations of the Extension have not been discussed yet :)

9. IANA Considerations

IANA is requested to register perform registrations for the Namespace and XML schema as follows:

9.1. Namespace

TODO once stable

9.2. XML Schema

TODO once stable

10. Changelog

Note to RFC editor: Remove this entire section before publication.

10.1. mayrhofer-epp-domain-suggestion-00

Initial strawman proposal

11. Normative References

Appendix A. Acknowledgments

Provide in-depth review or actual text if you like your name to appear here :D

Author's Address