Domain variant support for EPP
draft-galvin-regext-epp-variants-00

EXTRA                                                          J. Galvin
Internet-Draft                                          Identity Digital
Intended status: Standards Track                          A. Gulbrandsen
Expires: 22 March 2025                                             ICANN
                                                       18 September 2024

                     Domain variant support for EPP
                  draft-galvin-regext-epp-variants-00

Abstract

   This document defines an EPP extension allowing clients to learn
   about and manipulate variant groups of domains, ie. groups of domains
   whose names are equivalent in a registry-defined way and are tied to
   a single registrant.

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 22 March 2025.

Copyright Notice

   Copyright (c) 2024 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Galvin & Gulbrandsen      Expires 22 March 2025                 [Page 1]
Internet-Draft                EPP Variants                September 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  EPP Commands  . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  EPP <check> command . . . . . . . . . . . . . . . . . . .   3
   5.  EPP <info> command  . . . . . . . . . . . . . . . . . . . . .   4
   6.  EPP <transfer> command  . . . . . . . . . . . . . . . . . . .   4
   7.  EPP <create> command  . . . . . . . . . . . . . . . . . . . .   4
   8.  EPP <update> command  . . . . . . . . . . . . . . . . . . . .   4
   9.  EPP <delete> command  . . . . . . . . . . . . . . . . . . . .   5
   10. EPP renew command . . . . . . . . . . . . . . . . . . . . . .   5
   11. EPP <transfer> query command  . . . . . . . . . . . . . . . .   5
   12. Result codes  . . . . . . . . . . . . . . . . . . . . . . . .   5
   13. Security Considerations . . . . . . . . . . . . . . . . . . .   6
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   15. Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Open issues  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Spelling is not necessarily uniform.  For example, an è and an e may
   be regarded as equivalent in some languages, and as different in
   others.

   Some registries plan to support this explicitly, with groups of
   variant domains that can only be registered by the same registrant.

   This document defines an EPP extension allowing clients to learn
   about and manipulate variant groups.  (EPP is defined in [RFC5730].)

   Registering a domain creates a variant group and the first domain in
   the group becomes the group's primary domain.  Subsequent domains in
   the same group can only be registered by the same registrar, which
   asserts that it is acting on behalf of the same registrant.  Domains
   in a variant group are transferred or deleted together with the
   primary domain.  The remainder of this document describes the
   specific details.

2.  Requirements Language

   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.

Galvin & Gulbrandsen      Expires 22 March 2025                 [Page 2]
Internet-Draft                EPP Variants                September 2024

3.  Terms

   Variant group: An implicit set of domains.  This set is not expressed
   explicitly in EPP, because it can be impractically large.  At the
   time of writing, a domain is registered whose a variant group would
   contain 10¹⁵ variants.

   Primary domain: The chronologically first domain in a variant group.

   Variant domain: A domain in a variant group.

   Allocatable variant: A domain that has not been registered, and which
   is conceptually tied to an existing primary domain.

   Allocated variant: A domain that has been registered, and which is
   tied to an existing primary domain.

   Grandfathered domain: A preexisting domain that would form a variant
   group if it were registered now.

   Blocked domain: A domain that has not been registered, and which is
   conceptually tied to one or more existing grandfathered domains.

   Normal domain: Any domain that has no variants, ie. its variant group
   would consist of only the domain itself. "42.example" might be such a
   domain, assuming that there are no equivalent variants of "42".

4.  EPP Commands

4.1.  EPP <check> command

   The EPP <check> command may return three new results:

   *  The domain cannot be provisioned because it is a variant of a
      primary domain, and the primary domain was not mentioned in the
      <check> command.

   *  The domain cannot be provisioned because it is a variant of at
      least one grandfathered domain.

   *  The domain cannot be provisioned because it is a variant in a
      group that is currently being transferred to a different
      registrar.

   TODO XML examples of at least one

Galvin & Gulbrandsen      Expires 22 March 2025                 [Page 3]
Internet-Draft                EPP Variants                September 2024

5.  EPP <info> command

   The EPP <info> command is not extended, but its response is extended
   with the name of the primary domain if the <info> command concerns a
   variant domain.

   TODO XML example of response

6.  EPP <transfer> command

   The EPP <transfer> command is modified as follows:

   *  A transfer of a primary domain also transfers all of the variants
      of that domain.

   *  A transfer of a variant domain returns en error.

7.  EPP <create> command

   The EPP <create> command may have three new errors, as described in
   the <check> section above.

   The EPP <create> command's task is to provision a new normal domain.
   The task of converting an allocatable domain into an allocated domain
   is instead performed using the update command.

8.  EPP <update> command

   The EPP <update> command is extended to cover two new major tasks:

   When an EPP client wishes to provision a new domain in a variant
   group, it uses the <update> command rather than the <create> command.
   This informs the EPP server that the client understands that the task
   is to provision a variant domain rather than a new normal domain, and
   asserts that the two domains belong to the same registrant.

   Note that depending on registry policy, the variant domain may e.g.
   share name servers with the primary domain.  This implies that the
   set of elements required/permitted for a variant domain may differ
   from that of a primary domain or a normal domain.

   TODO update XML that shows the primary domain specified

   When an EPP client wishes to turn a grandfathered domain into a
   primary domain, it issues an <update> command including the list of
   variant domains, which the EPP client thereby asserts belong to the
   same registrant.

Galvin & Gulbrandsen      Expires 22 March 2025                 [Page 4]
Internet-Draft                EPP Variants                September 2024

   TODO update XML that shows the list of variant domains specified

9.  EPP <delete> command

   The EPP <delete> command is extended with one new task: Deleting the
   primary domain deletes all allocated variant groups along with the
   primary domain.

   Deleting a variant group other than the primary deletes just that
   domain.

10.  EPP renew command

   The EPP renew command is not extended.

   The server MAY reject renewals while a variant group is being
   transferred.

11.  EPP <transfer> query command

   The EPP <transfer> query command is not extended.

   Note that because variant groups are transferred as a group, the
   result of the a <transfer> query command is necessarily the same for
   all domains in a group.  Therefore, the result of <transfer> query
   command for any domain in a variant group applies to all domains in
   the group.

12.  Result codes

   The following additional result codes are defined:

   23x1: Change impossible because of a transfer in progress.

   23x2: Change impossible because something is not a variant.

   This error code is used when a change presupposes that two domains
   belong to the same variant group, but the EPP server's implementation
   disagrees.

   23x3: Change impossible due to invalid primary domain

   This error code is used when the primary domain specified in the
   command is not registered, or is not registered via this registrar.

   23x4: Change impossible due to unspecified primary domain

Galvin & Gulbrandsen      Expires 22 March 2025                 [Page 5]
Internet-Draft                EPP Variants                September 2024

   This error code is used when a command needs to specify a primary
   domain, and does not.

   23x5: Specified domain is grandfathered

   This error code is used when a domain specifies a primary domain, and
   the change is impossible because the specified domain is
   grandfathered instead.

   23x6: Specified domain is allocatable, but not by you.

   This result code is used when a domain is a member of a variant set,
   and the command did not refer to the primary domain.

13.  Security Considerations

   If two domains are different according to the DNS rules and identical
   in the eyes of the intended audience, then the audience may be
   confused.  Confusion can always have security-related effects.

   This extension expresses the relationships between variants clearly,
   making it a little more difficult for a would-be impersonator to
   register a variant of another registrant's existing domain.

14.  IANA Considerations

15.  Normative References

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

   [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/rfc/rfc2119>.

   [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/rfc/rfc8174>.

Appendix A.  Open issues

   Open issue: Assign numbers to the error codes, properly.

Galvin & Gulbrandsen      Expires 22 March 2025                 [Page 6]
Internet-Draft                EPP Variants                September 2024

   Open issue: Not clear that there are any security considerations here
   — the relationships between the domains may have some, but those
   exist outside EPP, EPP merely describes them.  In Italian, caffe and
   caffè are variants of the same thing, it's not clear that linking
   them in a protocol affects security in any way.

   Open issue: Check how to insert a DS record in a variant domain.

   Open issue: Can a unicode upgrade cause domains to become
   grandfathered?  Yes, I think, and the terminology covers it, but as
   of now, it's difficult for the EPP client to understand the
   situation.  Extending the <info> command would help here, perhaps.

   Open issue: Creating a primary domain now consists of a two-step
   process, <create> and then <update>.  The first step turns all
   variants into blocked domains, the second makes them allocatable.
   It's not clear to me why the two-step process is desirable, compared
   to a one-step process where a <create> command creates a primary
   domain if the variant group contains other domains than that one.
   That needs a couple of sentences of explanation, or else a change.

   Open issue: <Delete> now cascades and deletes many domains.  Should
   it instead turn any variant domains into grandfathered domains?

   Open issue: Should the <info> of the primary domain also return the
   list of allocated variants?  Probably not — at the moment, this
   extension has the client send a set that the server checks, and the
   server may need to generate a set for checking, but the server does
   not need to generate a list for returning.

Authors' Addresses

   James Galvin
   Identity Digital
   Bellevue
   Email: jgalvin@identity.digital

   Arnt Gulbrandsen
   ICANN
   6 Rond Point Schumann, Bd. 1
   1040 Brussels
   Belgium
   Email: arnt@gulbrandsen.priv.no
   URI:   https://icann.org/ua

Galvin & Gulbrandsen      Expires 22 March 2025                 [Page 7]