idnits 2.17.1 draft-mayrhofer-epp-domain-suggest-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 01, 2019) is 1610 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 REGEXT A. Mayrhofer 3 Internet-Draft nic.at GmbH 4 Intended status: Standards Track November 01, 2019 5 Expires: May 4, 2020 7 Domain Suggestion Extension for the Extensible Provisioning Protocol 8 (EPP) 9 draft-mayrhofer-epp-domain-suggest-00 11 Abstract 13 This document specifies an EPP Extension that allows servers to 14 suggest available domain names to clients, for example in cases where 15 the originally desired domain name is unavailable for registration. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 4, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Domain Name Suggestion Structure . . . . . . . . . . . . . . 3 54 4. Client and Server Behaviour . . . . . . . . . . . . . . . . . 3 55 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 56 5.1. EPP Query Command . . . . . . . . . . . . . . . . 4 57 6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 5 58 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 9.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 6 63 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 10.1. mayrhofer-epp-domain-suggestion-00 . . . . . . . . . . . 6 65 11. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 The Extensible Provisioning Protocol (EPP) [RFC5730] is a client- 72 server protocol for provisioning and managing objects in shared 73 repositories. In many cases, EPP is used to provision Domain Names 74 between Registrars and Domain Name Registries (see [RFC5731]). 76 EPP provides the "check" query command to determine whether an object 77 can be provisioned with a registry. That command is typically used 78 to determine whether a certain domain name is available for 79 registration at a Domain Name Registry. In case a requested domain 80 name is not available for registration, it is desirable to suggest 81 alternative, available names to the client. However, EPP does 82 currently not contain data structures suitable to transport such 83 "Domain Suggestions". 85 This document specifies a Command-Response level EPP extension for 86 the EPP Domain Mapping [RFC5731], allowing servers to include such 87 Domain Suggestions in responses to EPP "" commands. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 XML is case sensitive. Unless stated otherwise, XML specifications 98 and examples provided in this document MUST be interpreted in the 99 character case presented in order to develop a conforming 100 implementation. 102 In examples, "C:" represents lines sent by a protocol client and "S:" 103 represents lines returned by a protocol server. Indentation and 104 white space in examples are provided only to illustrate element 105 relationships and are not a REQUIRED feature of this protocol. 107 "ds" is used as a namespace abbreviation for 108 "urn:ietf:params:xml:ns:epp:domainSuggest-1.0", and "domain" is used 109 as an abbreviation for "urn:ietf:params:xml:ns:epp:domain-1.0". The 110 XML namespace prefix "ds" is used, but implementations MUST NOT 111 depend on it and instead employ a proper namespace-aware XML parser 112 and serializer to interpret and output the XML documents. 114 3. Domain Name Suggestion Structure 116 In order to convey domain name suggestions, the following XML 117 structure is defined: 119 o A element for use in responses, containing one or 120 more elements 122 o Each element contains a suggested (available) fully 123 qualified domain name, and an OPTIONAL "for" attribute. 125 o If present, the "for" attribute of the element MUST 126 contain a domain name given in one of the elements 127 of the corresponding command. This allows a client to correlate 128 suggestions with originally requested names when multiple names 129 were given in the command. 131 4. Client and Server Behaviour 133 o A client MUST indicate support for the 134 "urn:ietf:params:xml:ns:epp:domainSuggest-1.0" in the "" 135 command in order to receive suggestions 137 o When a client indicates support for the extension, it is local 138 server policy if and when suggestions are provided. 140 o When a server attempts to provide suggestions, but fails to do so 141 for the set of given names, it SHOULD indicate that situation with 142 an empty element in the response. 144 o A server SHOULD NOT suggest domain names which are unavailable for 145 registration. 147 o A client hence SHOULD assume that suggested names are available 148 for registration, without the need for an additional 149 command for those names. 151 o Servers SHOULD gracefully handle situations where generation of 152 suggestions triggers errors, and continue to process the base EPP 153 command. 155 o Servers MAY also give suggestions even if the originally requested 156 name is available. 158 5. EPP Command Mapping 160 The only command extended is the command. 162 5.1. EPP Query Command 164 This extension does not add any elements to the EPP command 165 described in the EPP Domain Mapping [RFC5731]. However, additional 166 elements are defined for the response: 168 When a command has been processed succesfully, the EPP 169 element MAY contain a child element, 170 structured as described above. 172 Example response: 174 S: 175 S: 176 S: 177 S: 178 S: Command completed successfully 179 S: 180 S: 181 S: 183 S: 184 S: example.com 185 S: 186 S: 187 S: example.net 188 S: In use 189 S: 190 S: 191 S: example.org 192 S: 193 S: 194 S: 195 S: 196 S: 198 S: my.example.net 199 S: wedosubdomains.example.com 200 S: betterexample.tld 201 S: 202 S: 203 S: ABC-12345 204 S: 54322-XYZ 205 S: 206 S: 207 S: 209 6. Open Questions 211 [Note to RFC Editor: Do not publish this document before that section 212 is empty :) ] 214 The following issues need to be solved / discussed before the 215 extension can be deemed stable: 217 o Shall there be an element in the commands to explicitly request 218 suggestions (). 220 o Corner Case: Can error responses contain suggestions? Eg. when a 221 domain in an unsupported TLD is given? 223 o Shall suggestions be allowed in other commands? 225 o More mechanics for handling keywords (back and forth?) 227 o Allow conveyance of user location? Tricky, involves handling PII 228 data... 230 o Maximum number of suggestions? Order / weight of suggestions? 232 7. Formal Syntax 234 TODO: Create Schema once structure of extension is stable. 236 8. Security Considerations 238 At this stage of the document, Security Considerations of the 239 Extension have not been discussed yet :) 241 9. IANA Considerations 243 IANA is requested to register perform registrations for the Namespace 244 and XML schema as follows: 246 9.1. Namespace 248 TODO once stable 250 9.2. XML Schema 252 TODO once stable 254 10. Changelog 256 Note to RFC editor: Remove this entire section before publication. 258 10.1. mayrhofer-epp-domain-suggestion-00 260 Initial strawman proposal 262 11. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 270 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 271 . 273 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 274 Domain Name Mapping", STD 69, RFC 5731, 275 DOI 10.17487/RFC5731, August 2009, 276 . 278 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 279 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 280 May 2017, . 282 Appendix A. Acknowledgments 284 Provide in-depth review or actual text if you like your name to 285 appear here :D 287 Author's Address 289 Alexander Mayrhofer 290 nic.at GmbH 291 Karlsplatz 1/2/9 292 Vienna 1010 293 Austria 295 Email: alex.mayrhofer.ietf@gmail.com