[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
REGEXT                                                      A. Mayrhofer
Internet-Draft                                               nic.at GmbH
Intended status: Standards Track                       November 01, 2019
Expires: May 4, 2020


  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.




Mayrhofer                  Expires May 4, 2020                  [Page 1]


Internet-Draft            EPP Domain Suggestion            November 2019


Table of Contents

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

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.




Mayrhofer                  Expires May 4, 2020                  [Page 2]


Internet-Draft            EPP Domain Suggestion            November 2019


   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:

   o  A <ds:suggestions> element for use in responses, containing one or
      more <ds:name> elements

   o  Each <ds:name> element contains a suggested (available) fully
      qualified domain name, and an OPTIONAL "for" attribute.

   o  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

   o  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

   o  When a client indicates support for the extension, it is local
      server policy if and when suggestions are provided.

   o  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.





Mayrhofer                  Expires May 4, 2020                  [Page 3]


Internet-Draft            EPP Domain Suggestion            November 2019


   o  A server SHOULD NOT suggest domain names which are unavailable for
      registration.

   o  A client hence SHOULD assume that suggested names are available
      for registration, without the need for an additional <check>
      command for those names.

   o  Servers SHOULD gracefully handle situations where generation of
      suggestions triggers errors, and continue to process the base EPP
      command.

   o  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:






















Mayrhofer                  Expires May 4, 2020                  [Page 4]


Internet-Draft            EPP Domain Suggestion            November 2019


   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:

   o  Shall there be an element in the commands to explicitly request
      suggestions (<ds:yesplease>).

   o  Corner Case: Can error responses contain suggestions?  Eg. when a
      domain in an unsupported TLD is given?



Mayrhofer                  Expires May 4, 2020                  [Page 5]


Internet-Draft            EPP Domain Suggestion            November 2019


   o  Shall suggestions be allowed in other commands?

   o  More mechanics for handling keywords (back and forth?)

   o  Allow conveyance of user location?  Tricky, involves handling PII
      data...

   o  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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.






Mayrhofer                  Expires May 4, 2020                  [Page 6]


Internet-Draft            EPP Domain Suggestion            November 2019


   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
              <https://www.rfc-editor.org/info/rfc5730>.

   [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Domain Name Mapping", STD 69, RFC 5731,
              DOI 10.17487/RFC5731, August 2009,
              <https://www.rfc-editor.org/info/rfc5731>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Appendix A.  Acknowledgments

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

Author's Address

   Alexander Mayrhofer
   nic.at GmbH
   Karlsplatz 1/2/9
   Vienna  1010
   Austria

   Email: alex.mayrhofer.ietf@gmail.com
























Mayrhofer                  Expires May 4, 2020                  [Page 7]