Internet DRAFT - draft-mayrhofer-epp-domain-suggest
draft-mayrhofer-epp-domain-suggest
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]
