Network Working Group                                            P. Garg
Internet-Draft                                                  J. Gould
Intended status: Informational                                 J. Colosi
Expires: 16 September 2026                                VeriSign, Inc.
                                                           15 March 2026


   Change Extension Mapping for the Extensible Provisioning Protocol
                        draft-garg-change-ext-00

Abstract

   This document describes an Extensible Provisioning Protocol (EPP)
   extension of the domain name mapping and the host mapping to link
   transform commands to a change request described in the EPP Change
   Mapping.

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 16 September 2026.

Copyright Notice

   Copyright (c) 2026 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.




Garg, et al.            Expires 16 September 2026               [Page 1]

Internet-Draft            EPP Change Extension                March 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
   2.  Object Attributes . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Request Identifier  . . . . . . . . . . . . . . . . . . .   3
   3.  EPP Command Mapping . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  EPP Query Commands  . . . . . . . . . . . . . . . . . . .   3
       3.1.1.  EPP <check> Command . . . . . . . . . . . . . . . . .   4
       3.1.2.  EPP <info> Command  . . . . . . . . . . . . . . . . .   4
       3.1.3.  EPP <transfer> Command  . . . . . . . . . . . . . . .   4
     3.2.  EPP Transform Commands  . . . . . . . . . . . . . . . . .   4
       3.2.1.  EPP <create> Command  . . . . . . . . . . . . . . . .   4
       3.2.2.  EPP <create> Response . . . . . . . . . . . . . . . .   5
       3.2.3.  EPP <delete> Command  . . . . . . . . . . . . . . . .   6
       3.2.4.  EPP <delete> Response . . . . . . . . . . . . . . . .   6
       3.2.5.  EPP <renew> Command . . . . . . . . . . . . . . . . .   6
       3.2.6.  EPP <renew> Response  . . . . . . . . . . . . . . . .   6
       3.2.7.  EPP <transfer> Command  . . . . . . . . . . . . . . .   6
       3.2.8.  EPP <transfer> Response . . . . . . . . . . . . . . .   6
       3.2.9.  EPP <update> Command  . . . . . . . . . . . . . . . .   7
       3.2.10. EPP <update> Response . . . . . . . . . . . . . . . .   7
   4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  XML Namespace . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  EPP Extension Registry  . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This document describes the change extension mapping for version 1.0
   of the Extensible Provisioning Protocol (EPP).  This mapping, an
   extension of the domain name mapping described in [7], and an
   extension of the host mapping described in [8], is specified using
   the Extensible Markup Language (XML) 1.0 as described in [1] and XML
   Schema notation as described in [2] and [3].

   This document describes an Extensible Provisioning Protocol (EPP)
   extension of the domain name mapping described in [7] and the host
   mapping described in [8] to link transform commands to a change
   request described in the EPP Change Mapping - Add link TBD.






Garg, et al.            Expires 16 September 2026               [Page 2]

Internet-Draft            EPP Change Extension                March 2026


1.1.  Conventions Used in This Document

   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 [4]
   when, and only when, they appear in all capitals, as shown here.

   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 is provided only to illustrate element
   relationships and is not a REQUIRED feature of this specification.

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

   The XML namespace prefix "changeExt" is used for the namespace
   "http://www.verisign-grs.com/epp/changeExt-1.0", but implementations
   MUST NOT depend on it; instead, they should employ a proper
   namespace-aware XML parser and serializer to interpret and output the
   XML documents.

2.  Object Attributes

   This extension adds additional elements to the domain name mapping
   described in [7] and the host mapping described in [8].  Only new
   elements are described here.

2.1.  Request Identifier

   The request identifier is used to identify the target Change Request
   object that the EPP operation is intended for.  The request
   identifier uses the <changeExt:requestId> element, and is defined in
   section 2.1 of the EPP Change Mapping - Add link TBD.

3.  EPP Command Mapping

   A detailed description of the EPP syntax and semantics can be found
   in the EPP core protocol specification [6].

3.1.  EPP Query Commands

   EPP provides three commands to retrieve object information: <check>
   to determine if an object is known to the server, <info> to retrieve
   detailed information associated with an object, and <transfer> to
   retrieve object transfer status information.





Garg, et al.            Expires 16 September 2026               [Page 3]

Internet-Draft            EPP Change Extension                March 2026


   The syntax of the Change extension is identical for all types of EPP
   commands.

3.1.1.  EPP <check> Command

   This extension does not add any elements to the EPP <check> command
   or <check> response described in the EPP domain mapping [7] and the
   EPP host mapping [8].

3.1.2.  EPP <info> Command

   This extension does not add any elements to the EPP <info> command or
   <info> response described in the EPP domain mapping [7] and the EPP
   host mapping [8].

3.1.3.  EPP <transfer> Command

   This extension does not add any elements to the EPP <transfer> query
   command or <transfer> query response described in the EPP domain
   mapping [7] and the EPP host mapping [8].

3.2.  EPP Transform Commands

   EPP provides five commands to transform objects: <create> to create
   an instance of an object, <delete> to delete an instance of an
   object, <renew> to extend the validity period of an object,
   <transfer> to manage object sponsorship changes, and <update> to
   change information associated with an object.

   The syntax of the Change extension is identical for all types of EPP
   commands.  Please see the <create> Command, in section 3.2.1, for a
   detailed description of command syntax.

3.2.1.  EPP <create> Command

   This extension defines additional elements for the EPP <create>
   command.

   The EPP <create> command provides a transform operation that allows a
   client to create a domain or host object.  In addition to the EPP
   command elements described in [EPP-D] and [EPP-H], the command MAY
   contain an <extension> element.  The <extension> element MUST contain
   a child <changeExt:changeExt> element that contains the following
   child elements:

   *  A <changeExt:requestID> element that MUST contain a request
      identifier, defined in section 2.1, specifying the target Change
      Request object.



Garg, et al.            Expires 16 September 2026               [Page 4]

Internet-Draft            EPP Change Extension                March 2026


   Example <create> command:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example</domain:name>
C:        <domain:period unit="y">1</domain:period>
C:        <domain:ns>
C:          <domain:hostObj>ns1.example.com</domain:hostObj>
C:          <domain:hostObj>ns1.example.net</domain:hostObj>
C:        </domain:ns>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <changeExt:changeExt
C:       xmlns:changeExt="http://www.verisign-grs.com/epp/changeExt-1.0">
C:         <changeExt:requestID>tk421</changeExt:requestID>
C:      </changeExt:changeExt>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

                               Figure 1

3.2.2.  EPP <create> Response

   When a <create> command has been processed successfully, the server
   MUST respond with an EPP response with no <resData> element.

   Example <create> response:














Garg, et al.            Expires 16 September 2026               [Page 5]

Internet-Draft            EPP Change Extension                March 2026


   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1001">
   S:      <msg>Command completed successfully; action pending</msg>
   S:    </result>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>SRV-43659</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

                                  Figure 2

   An EPP error response MUST be returned if a <create> command can not
   be processed for any reason

   TBD - The response has a pending action and the server MUST notify
   the client when offline processing of the action has been completed
   using the Change Request Poll message as defined by the EPP Change
   Mapping - Add link TBD.

3.2.3.  EPP <delete> Command

   (see section 3.2.1)

3.2.4.  EPP <delete> Response

   (see section 3.2.2)

3.2.5.  EPP <renew> Command

   (see section 3.2.1)

3.2.6.  EPP <renew> Response

   (see section 3.2.2)

3.2.7.  EPP <transfer> Command

   (see section 3.2.1)

3.2.8.  EPP <transfer> Response

   (see section 3.2.2)






Garg, et al.            Expires 16 September 2026               [Page 6]

Internet-Draft            EPP Change Extension                March 2026


3.2.9.  EPP <update> Command

   (see section 3.2.1)

3.2.10.  EPP <update> Response

   (see section 3.2.2)

4.  Formal Syntax

   An EPP object mapping is specified in XML Schema notation.  The
   formal syntax presented here is a complete schema representation of
   the object mapping suitable for automated validation of EPP XML
   instances.  The BEGIN and END tags are not part of the schema; they
   are used to note the beginning and ending of the schema for URI
   registration purposes.

 BEGIN
 <?xml version="1.0" encoding="UTF-8"?>
 <schema targetNamespace="http://www.verisign-grs.com/epp/changeExt-1.0"
   xmlns:changeExt="http://www.verisign-grs.com/epp/changeExt-1.0"
   xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
   xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
   xmlns="http://www.w3.org/2001/XMLSchema"
   elementFormDefault="qualified">

   <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
     schemaLocation="eppcom-1.0.xsd"/>
   <import namespace="urn:ietf:params:xml:ns:epp-1.0"
     schemaLocation="epp-1.0.xsd"/>

   <annotation>
     <documentation>
       Extensible Provisioning Protocol v1.0
       Change extension schema
     </documentation>
   </annotation>

   <element name="changeExt" type="changeExt:changeExtType"/>

   <complexType name="changeExtType">
     <sequence>
       <element name="requestID" type="epp:trIDStringType"/>
     </sequence>
   </complexType>

 </schema>
 END



Garg, et al.            Expires 16 September 2026               [Page 7]

Internet-Draft            EPP Change Extension                March 2026


5.  IANA Considerations

5.1.  XML Namespace

   This document uses URNs to describe XML namespaces and XML schemas
   conforming to a registry mechanism described in [5].  The following
   URI assignment has been made by IANA:

   Registration request for the Change Extension namespace:

   URI:  http://www.verisign-grs.com/epp/changeExt-1.0
   Registrant Contact:  VeriSign Inc., <epp-registry@verisign.com>
   XML:  None.  Namespace URIs do not represent an XML specification.

   Registration request for the Change Extension XML Schema:

   URI:  http://www.verisign-grs.com/epp/changeExt-1.0
   Registrant Contact:  VeriSign Inc., <epp-registry@verisign.com>
   XML:  See the "Formal Syntax" section of this document.

5.2.  EPP Extension Registry

   The EPP extension described in this document has been registered by
   IANA in the "Extensions for the Extensible Provisioning Protocol
   (EPP)" registry described in [9].  The details of the registration
   are as follows:

   Name of Extension:  "Change Extension Mapping for the Extensible
      Provisioning Protocol"
   Document Status:  Informational
   Reference:  (insert reference to RFC version of this document)
   Registrant Name and Email Address:  VeriSign Inc., <epp-
      registry@verisign.com>
   TLDs:  Any
   IPR Disclosure:  None
   Status:  Active
   Notes:  None

6.  Security Considerations

   The mapping extensions described in this document do not provide any
   security services beyond those described by EPP [6], the EPP domain
   name mapping [7], the EPP host mapping [8] and protocol layers used
   by EPP.  The security considerations described in these other
   specifications apply to this specification as well.

7.  References




Garg, et al.            Expires 16 September 2026               [Page 8]

Internet-Draft            EPP Change Extension                March 2026


7.1.  Normative References

   [1]        Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
              F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third
              Edition)", World Wide Web Consortium FirstEdition REC-xml-
              20040204", February 2004,
              <http://www.w3.org/TR/2004/REC-xml-20040204>.

   [2]        Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
              ""XML Schema Part 1: Structures Second Edition", World
              Wide Web Consortium Recommendation REC-xmlschema-
              1-20041028", October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

   [3]        Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes
              Second Edition", World Wide Web Consortium Recommendation
              REC-xmlschema-2-20041028", October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

   [4]        Best Current Practice 14,
              <https://www.rfc-editor.org/info/bcp14>.
              At the time of writing, this BCP comprises the following:

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

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

   [5]        Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

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

   [7]        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>.

   [8]        Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
              August 2009, <https://www.rfc-editor.org/info/rfc5732>.



Garg, et al.            Expires 16 September 2026               [Page 9]

Internet-Draft            EPP Change Extension                March 2026


7.2.  Informative References

   [9]        Hollenbeck, S., "Extension Registry for the Extensible
              Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
              February 2015, <https://www.rfc-editor.org/info/rfc7451>.

Authors' Addresses

   Poonam Garg
   VeriSign, Inc.
   12061 Bluemont Way
   Reston, VA 20190
   United States of America
   Email: pogarg@verisign.com
   URI:   http://www.verisign.com


   James Gould
   VeriSign, Inc.
   12061 Bluemont Way
   Reston, VA 20190
   United States of America
   Email: jgould@verisign.com
   URI:   http://www.verisign.com


   John Colosi
   VeriSign, Inc.
   12061 Bluemont Way
   Reston, VA 20190
   United States of America
   Email: jcolosi@verisign.com
   URI:   http://www.verisign.com


















Garg, et al.            Expires 16 September 2026              [Page 10]