eppeai.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC5321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY RFC5322 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY RFC5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY RFC6530 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6530.xml">
<!ENTITY RFC6531 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6531.xml">
<!ENTITY RFC6532 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6532.xml">
<!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml">
<!ENTITY RFC8590 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8590.xml">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-regext-epp-eai-19"
  category="std" ipr="trust200902" obsoletes="" updates=""
  submissionType="IETF" xml:lang="en" symRefs="true" sortRefs="false"
  tocInclude="true" version="3" consensus="true">
  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title abbrev="Use of SMTPUTF8 addresses in EPP">Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-regext-epp-eai-19"/>
    <author fullname="Dmitry Belyavskiy" initials="D." surname="Belyavskiy">
      <address>
        <postal>
          <street>8 marta st.</street>
	  <city>Moscow</city>
	  <code>127083</code>
          <country>Russian Federation</country>
        </postal>
        <phone>+7 916 262 5593</phone>
        <email>beldmit@gmail.com</email>
      </address>
    </author>
    <author fullname="James Gould" surname="Gould">
      <organization>VeriSign, Inc.</organization>
      <address>
        <postal>
          <street>12061 Bluemont Way</street>
          <city>Reston</city>
          <region>VA</region>
          <code>20190</code>
          <country>US</country>
        </postal>
        <email>jgould@verisign.com</email>
        <uri>http://www.verisigninc.com</uri>
      </address>
    </author>
    <abstract>
      <t>
   This document describes an EPP command-response extension that permits usage of Internationalized Email Addresses in the EPP protocol
   and specifies the terms when it can be used by EPP clients and servers.
	 The Extensible Provisioning Protocol (EPP), being developed before the standards
	 for SMTPUTF8 compliant addresses, does not support such email addresses.
      </t>
      <t>TO BE REMOVED on turning to RFC: The document is edited in <eref target="https://github.com/beldmit/eppeai"> the dedicated github repo</eref>. Please send your submissions via GitHub.
      </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>
	<xref target="RFC6530" format="default"/> introduced the framework for Internationalized Email Addresses.
	To make such addresses more widely accepted, the changes to various protocols need to be introduced.
      </t>
      <t>
   This document describes an Extensible Provisioning Protocol (EPP) command-response extension, defined in <xref target="RFC5730" format="default"/>,
   that permits the usage of Internationalized Email Addresses in the EPP protocol, specifies the terms when it can be used by EPP clients and servers,
   and defines an alternate email to use from ASCII-only to both ASCII and SMTPUTF8.  The extension is used
   to apply the rules for the processing of email address elements in all of the <xref target="RFC5730" format="default"/> extensions negotiated in the EPP session,
   which include the object and command-responses extensions. The extension can be applied to any object or command-response extension that uses an email address.
      </t>
      <t>
	The Extensible Provisioning Protocol (EPP) specified in <xref target="RFC5730" format="default"/>
	is a base document for object management operations and an extensible framework that maps
  protocol operations to objects. The specifics of various objects managed via EPP is described in separate documents.
  This document is only referring to an email address as a property of a managed object, such as
  the &lt;contact:email&gt; element in the <xref target="RFC5733" format="default">EPP contact mapping</xref> or
  the &lt;org:email&gt; element in the <xref target="RFC8543" format="default">EPP organization mapping</xref>, and command-response
  extensions applied to a managed object.
      </t>
        <section numbered="true" toc="default">
        <name>Conventions Used in This Document</name>
        <t> 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 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when,
  they appear in all capitals, as shown here.</t>

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

  <t>In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server.
  Indentation and white space in the examples are provided only to
  illustrate element relationships and are not REQUIRED in the protocol.</t>

  <t>The XML namespace prefix "eai" is used for the namespace
"urn:ietf:params:xml:ns:epp:eai-1.0", 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.</t>

      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Migrating to Newer Versions of This Extension</name>
      <t>
   Servers that implement this extension <bcp14>SHOULD</bcp14> provide a way for
   clients to progressively update their implementations when a new
   version of the extension is deployed.  A newer version of the
   extension is expected to use an XML namespace URI with a higher version
   number than the prior versions.
      </t>
    </section>
    <section anchor="emailAddressSpec" numbered="true" toc="default">
      <name>Email Address Specification</name>
      <t>
      Support of non-ASCII email address syntax is defined in <xref target="RFC6530" format="default">RFC 6530</xref>. This mapping does not prescribe minimum or maximum lengths for character strings used to represent email addresses.
        The exact syntax of such addresses is described in Section 3.3 of <xref target="RFC6531" format="default"/>. The validation rules introduced in RFC 6531 MUST be followed when processing this extension.
      </t>
      <t>
        The definition of email address in the EPP RFCs, including Section 2.6 of <xref target="RFC5733" format="default"/> and
        Section 4.1.2, 4.2.1, and 4.2.5 of <xref target="RFC8543" format="default"/>, references <xref target="RFC5322" format="default"/> for the email address syntax.  The XML schema
        definition in Section 4 of <xref target="RFC5733" format="default"/> and Section 5 of <xref target="RFC8543" format="default"/> defines the "email" element using the type "eppcom:minTokenType",
        which is defined in Section 4.2 of <xref target="RFC5730" format="default"/> as an XML schema "token" type with minimal length of one.  The XML schema "token" type will fully support the use
        of SMTPUTF8 compliant addresses so the primary application of the extension is to apply the use of <xref target="RFC6531" format="default"/> instead of <xref target="RFC5322" format="default"/> for
        the email address syntax.  Other EPP extensions may follow the formal syntax definition using the XML schema type "eppcom:minTokenType" and the <xref target="RFC5322" format="default"/> format specification,
        where this extension applies to all EPP extensions with the same or similar definitions.
      </t>
      <t>
        The email address format is formally defined in Section 3.4.1 of <xref target="RFC5322" format="default"/>, which only consists of printable US-ASCII characters for both the local-part and the domain ABNF rules.
        <xref target="RFC6531" format="default"/> extends the Mailbox, Local-part and Domain ABNF rules in <xref target="RFC5321" format="default"/> to support "UTF8-non-ascii", defined in Section 3.1 of <xref target="RFC6532" format="default"/>, for the local-part and
        U-label, defined in Section 2.3.2.1 of <xref target="RFC5890" format="default"/>, for the domain.  By applying the syntax rules of <xref target="RFC6531" format="default"/>, the EPP extensions will
        change from supporting only ASCII characters to supporting Internationalized characters both in the email address local-part and domain-part.
      </t>
    </section>
    <section anchor="eaiElement" numbered="true" toc="default">
      <name>SMTPUTF8 &lt;eai:eai&gt; Element</name>
      <t>An alternate email can be set using the &lt;eai:eai&gt; element
      with the command and response extensions defined in <xref target="commands"/>.  The &lt;eai:eai&gt; element contains the following child element:</t>
      <dl newline="false" indent="4">
          <dt>&lt;eai:email&gt;:</dt>
          <dd>An element following the syntax in <xref target="emailAddressSpec"/> for defining an alternate ASCII or SMTPUTF8 address.  An empty &lt;eai:email/&gt; element unsets
          the alternate email in the <xref target="updateCommand">Update Command</xref> and indicates the alternate email is not set in the <xref target="infoCommand">Info Response</xref>.</dd>
      </dl>
    </section>
    <section numbered="true" toc="default">
      <name>SMTPUTF8 Extension</name>
      <section numbered="true" toc="default">
  	    <name>Scope of Extension</name>
  	    <t>
           The extension applies to all object extensions and command-response extensions negotiated in the EPP session that include email address properties.
           Examples include the &lt;contact:email&gt; element in the <xref target="RFC5733" format="default">EPP contact mapping</xref> or
           the &lt;org:email&gt; element in the <xref target="RFC8543" format="default">EPP organization mapping</xref>.  All registry zones (e.g., top-level domains) authorized
           for the client in the EPP session apply.  There is no concept of a per-client, per-zone, per-extension, or per-field setting that is used to indicate
           support for SMTPUTF8 compliant addresses, but instead it's a global setting that applies to the EPP session.
  	    </t>
      </section>
      <section numbered="true" toc="default">
  	    <name>Signaling Client and Server Support</name>
  	    <t>
           The client and the server can signal support for the extension using a
           namespace URI in the login and greeting extension services respectively.  The
           namespace URI "urn:ietf:params:xml:ns:epp:eai-1.0" is used to signal support for the extension.
	         The client includes the namespace URI in an &lt;svcExtension&gt; &lt;extURI&gt; element of
           the <xref target="RFC5730" format="default"/> &lt;login&gt; Command.  The server includes the namespace URI
           in an &lt;svcExtension&gt; &lt;extURI&gt; element of the <xref target="RFC5730" format="default"/> Greeting.
  	    </t>
      </section>
      <section numbered="true" toc="default">
  	    <name>Extension Behavior</name>
          <section numbered="true" toc="default">
      	    <name>SMTPUTF8 compliant addresses Extension Negotiated</name>
	    <t>
		    If both client and server have indicated the support of the SMTPUTF8 addresses during the session establishment,
		    they MUST be able to process the SMTPUTF8 address in any message having an email property during the established EPP session.
              	Below are the server and client obligations when the SMTPUTF8 extension has been successfuly negotiated in the EPP session.
      	    </t>
      	    <t>The server MUST satisfy the following obligations when the SMTPUTF8 extension has been negotiated:</t>
      	    <ul>
      	    <li>Accept SMTPUTF8 compliant addresses for all email properties in the EPP session negotiated object extensions and command-response extensions.
                For example the &lt;contact:email&gt; element in <xref target="RFC5733" format="default"/> and the &lt;org:email&gt; element in <xref target="RFC8543" format="default"/>.</li>

	    <li>Accept SMTPUTF8 compliant addresses for all registry zones (e.g., top-level domains) authorized for the client in the EPP session.</li>
	    <li>Email address validation based on SMTPUTF8 validation rules defined in <xref target="emailAddressSpec" format="default"/></li>
	    <li>Storage of email properties that support internationalized characters.</li>
	    <li>Return SMTPUTF8 compliant addresses for all email properties in the EPP responses.</li>
          </ul>

          <t>The client MUST satisfy the following obligations when the SMTPUTF8 extension has been negotiated:</t>
          <ul>
      	    <li>Provide SMTPUTF8 compliant addresses for all e-mail properties in the EPP session negotiated object extensions and command-response extensions.  For example the &lt;contact:email&gt; element in <xref target="RFC5733" format="default"/> and the &lt;org:email&gt; element in <xref target="RFC8543" format="default"/>.</li>

      	    <li>Provide SMTPUTF8 compliant addresses for all registry zones (e.g., top-level domains) authorized for the client in the EPP session.</li>

      	    <li>Accept SMTPUTF8 compliant addresses in the EPP responses for all email properties in the EPP session negotiated object extensions and command-response extensions.</li>
      	  </ul>
        </section>

        <section numbered="true" toc="default">
          <name>SMTPUTF8 Extension Not Negotiated</name>
          <t>
            The lack of SMTPUTF8 adresses support can cause data and functional issues, so an SMTPUTF8 supporting client or server needs to handle cases where the opposite party doesn't support SMTPUTF8 addresses processing.
            Below are the server and client obligations when the SMTPUTF8 extension is not negotiated due to the lack of support by the peer.
          </t>
          <t>The SMTPUTF8 supporting server MUST satisfy the following obligations when the client does not support the SMTPUTF8 extension:</t>
            <ul>
              <li>When the email property is required in the EPP command, the server MUST validate the email property sent by the client using the ASCII email validation rules.</li>
              <li>When the email property is optional in the EPP command, if the client supplies the email property the server MUST validate the email property using the ASCII email validation rules.</li>
              <li>When the email property is required in the EPP response, the server MUST validate whether the email property is an SMTPUTF8 address and if so return the error code 2308 "Data management policy violation".</li>
              <li>When the email property is optional in the EPP response and is provided, the server MUST validate whether the email property is an SMTPUTF8 address and if so return the error code 2308 "Data management policy violation".</li>
            </ul>

            <t>The SMTPUTF8 supporting client MUST satisfy the following obligations when the server does not support the SMTPUTF8 extension:</t>
              <ul>
                <li>When the email property is required in the EPP command and the email property is an SMTPUTF8 address, the client MUST provide an ASCII email address.  The provided email address should provide a way to contact the registrant.</li>
		<li>When the email property is optional in the EPP command and the email property is an SMTPUTF8 address and client does not have an ASCII address providing a way to contact the registrant, the client MUST omit the email property. If the email property is provided, the client MUST provide an ASCII email address.
	</li>
              </ul>
        </section>
      </section>
    </section>

    <section anchor="commands" title="EPP Command Mapping">
      <t>A detailed description of the EPP syntax and semantics can be found
      in the EPP core protocol specification <xref target="RFC5730"/>.
      This section defines the provisioning of an alternate email address.</t>

      <section anchor="queryCommands" title="EPP Query Commands">

        <t>EPP provides three commands to retrieve object information: &lt;check&gt; to determine
        if an object can be provisioned, &lt;info&gt; to retrieve  information associated
        with an object, and &lt;transfer&gt; to retrieve object-transfer status information.</t>

      <section anchor="checkCommand" title="EPP &lt;check&gt; Command">

        <t>This extension does not add any elements to the EPP &lt;check&gt; command
        or &lt;check&gt; response described in <xref target="RFC5730"/>.</t>

      </section>

      <!-- end CHECK command -->

      <section anchor="infoCommand" title="EPP &lt;info&gt; Command">

        <t>This extension does not add any elements to the EPP &lt;info&gt; command
        response described in <xref target="RFC5730"/>.</t>

          <t>
          If the query was successful, the server replies with an <xref target="eaiElement">&lt;eai:eai&gt; element</xref>
          along with the regular EPP &lt;resData&gt;.
          </t>

          <t>The following is an example &lt;info&gt; contact response using the
          &lt;eai:eai&gt; extension with no alternate email:</t>
          <figure>
            <name>Example &lt;info&gt; contact response using the
            &lt;eai:eai&gt; extension with no alternate email</name>
<sourcecode type="xml" markers="false"><![CDATA[
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:      <contact:infData
S:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
S:        <contact:id>sh8013</contact:id>
S:        <contact:roid>SH8013-REP</contact:roid>
S:        <contact:status s="linked"/>
S:        <contact:status s="clientDeleteProhibited"/>
S:        <contact:postalInfo type="int">
S:          <contact:name>John Doe</contact:name>
S:          <contact:org>Example Inc.</contact:org>
S:          <contact:addr>
S:            <contact:street>123 Example Dr.</contact:street>
S:            <contact:street>Suite 100</contact:street>
S:            <contact:city>Dulles</contact:city>
S:            <contact:sp>VA</contact:sp>
S:            <contact:pc>20166-6503</contact:pc>
S:            <contact:cc>US</contact:cc>
S:          </contact:addr>
S:        </contact:postalInfo>
S:        <contact:voice x="1234">+1.7035555555</contact:voice>
S:        <contact:fax>+1.7035555556</contact:fax>
S:        <contact:email>麥克風@example.com</contact:email>
S:        <contact:clID>ClientY</contact:clID>
S:        <contact:crID>ClientX</contact:crID>
S:        <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>
S:        <contact:upID>ClientX</contact:upID>
S:        <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
S:        <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate>
S:        <contact:authInfo>
S:          <contact:pw>2fooBAR</contact:pw>
S:        </contact:authInfo>
S:        <contact:disclose flag="0">
S:          <contact:voice/>
S:          <contact:email/>
S:        </contact:disclose>
S:      </contact:infData>
S:    </resData>
S:    <extension>
S:      <eai:eai
S:       xmlns:eai="urn:ietf:params:xml:ns:epp:eai-1.0">
S:        <eai:email/>
S:      </eai:eai>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]></sourcecode>
          </figure>

          <t>The following is an example &lt;info&gt; contact response using the
          &lt;eai:eai&gt; extension with an ASCII alternate email:</t>
          <figure>
            <name>Example &lt;info&gt; contact response using the
            &lt;eai:eai&gt; extension with an ASCII alternate email</name>
<sourcecode type="xml" markers="false"><![CDATA[
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:      <contact:infData
S:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
S:        <contact:id>sh8013</contact:id>
S:        <contact:roid>SH8013-REP</contact:roid>
S:        <contact:status s="linked"/>
S:        <contact:status s="clientDeleteProhibited"/>
S:        <contact:postalInfo type="int">
S:          <contact:name>John Doe</contact:name>
S:          <contact:org>Example Inc.</contact:org>
S:          <contact:addr>
S:            <contact:street>123 Example Dr.</contact:street>
S:            <contact:street>Suite 100</contact:street>
S:            <contact:city>Dulles</contact:city>
S:            <contact:sp>VA</contact:sp>
S:            <contact:pc>20166-6503</contact:pc>
S:            <contact:cc>US</contact:cc>
S:          </contact:addr>
S:        </contact:postalInfo>
S:        <contact:voice x="1234">+1.7035555555</contact:voice>
S:        <contact:fax>+1.7035555556</contact:fax>
S:        <contact:email>麥克風@example.com</contact:email>
S:        <contact:clID>ClientY</contact:clID>
S:        <contact:crID>ClientX</contact:crID>
S:        <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>
S:        <contact:upID>ClientX</contact:upID>
S:        <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
S:        <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate>
S:        <contact:authInfo>
S:          <contact:pw>2fooBAR</contact:pw>
S:        </contact:authInfo>
S:        <contact:disclose flag="0">
S:          <contact:voice/>
S:          <contact:email/>
S:        </contact:disclose>
S:      </contact:infData>
S:    </resData>
S:    <extension>
S:      <eai:eai
S:       xmlns:eai="urn:ietf:params:xml:ns:epp:eai-1.0">
S:        <eai:email>jdoe@example.com</eai:email>
S:      </eai:eai>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]></sourcecode>
          </figure>

          <t>The following is an example &lt;info&gt; contact response using the
          &lt;eai:eai&gt; extension with an SMTPUTF8 alternate email:</t>
          <figure>
            <name>Example &lt;info&gt; contact response using the
            &lt;eai:eai&gt; extension with an SMTPUTF8 alternate email</name>
<sourcecode type="xml" markers="false"><![CDATA[
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:      <contact:infData
S:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
S:        <contact:id>sh8013</contact:id>
S:        <contact:roid>SH8013-REP</contact:roid>
S:        <contact:status s="linked"/>
S:        <contact:status s="clientDeleteProhibited"/>
S:        <contact:postalInfo type="int">
S:          <contact:name>John Doe</contact:name>
S:          <contact:org>Example Inc.</contact:org>
S:          <contact:addr>
S:            <contact:street>123 Example Dr.</contact:street>
S:            <contact:street>Suite 100</contact:street>
S:            <contact:city>Dulles</contact:city>
S:            <contact:sp>VA</contact:sp>
S:            <contact:pc>20166-6503</contact:pc>
S:            <contact:cc>US</contact:cc>
S:          </contact:addr>
S:        </contact:postalInfo>
S:        <contact:voice x="1234">+1.7035555555</contact:voice>
S:        <contact:fax>+1.7035555556</contact:fax>
S:        <contact:email>jdoe@example.com</contact:email>
S:        <contact:clID>ClientY</contact:clID>
S:        <contact:crID>ClientX</contact:crID>
S:        <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>
S:        <contact:upID>ClientX</contact:upID>
S:        <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
S:        <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate>
S:        <contact:authInfo>
S:          <contact:pw>2fooBAR</contact:pw>
S:        </contact:authInfo>
S:        <contact:disclose flag="0">
S:          <contact:voice/>
S:          <contact:email/>
S:        </contact:disclose>
S:      </contact:infData>
S:    </resData>
S:    <extension>
S:      <eai:eai
S:       xmlns:eai="urn:ietf:params:xml:ns:epp:eai-1.0">
S:        <eai:email>麥克風@example.com</eai:email>
S:      </eai:eai>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]></sourcecode>
          </figure>

      </section>
      <!-- end INFO command -->

      <section anchor="transferQueryCommand" title="EPP &lt;transfer&gt; Query Command">

       <t>This extension does not add any elements to the EPP &lt;transfer&gt; query command
       or &lt;transfer&gt; query response described in <xref target="RFC5730"/>.</t>

      </section>
      <!-- end TRANSFER QUERY command -->

      </section>

      <section anchor="transformCommands" title="EPP Transform Commands">

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

      <section anchor="createCommand" title="EPP &lt;create&gt; Command">

       <t>This extension defines additional elements to extend the EPP
        &lt;create&gt; command of an object mapping like <xref target="RFC5733"/>.</t>

       <t>The EPP &lt;create&gt; command provides a transform operation that allows a client to create an instance of an object.
       In addition to the EPP command elements described in an object mapping like <xref target="RFC5733"/>, the command MUST contain a
       child <xref target="eaiElement">&lt;eai:eai&gt; element</xref> for the client to be set an alternate email.
       If the alternate email does not apply to the object, the server MUST return an EPP error result code of 2201.</t>

       <t>The following is an example &lt;create&gt; command to create a contact object with an alternate ASCII email:</t>
       <figure>
            <name>Example &lt;create&gt; command to create a contact object with an alternate ASCII email</name>

            <sourcecode type="xml" markers="false"><![CDATA[
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:      <contact:create
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C:        <contact:id>sh8013</contact:id>
C:        <contact:postalInfo type="int">
C:          <contact:name>John Doe</contact:name>
C:          <contact:org>Example Inc.</contact:org>
C:          <contact:addr>
C:            <contact:street>123 Example Dr.</contact:street>
C:            <contact:street>Suite 100</contact:street>
C:            <contact:city>Dulles</contact:city>
C:            <contact:sp>VA</contact:sp>
C:            <contact:pc>20166-6503</contact:pc>
C:            <contact:cc>US</contact:cc>
C:          </contact:addr>
C:        </contact:postalInfo>
C:        <contact:voice x="1234">+1.7035555555</contact:voice>
C:        <contact:fax>+1.7035555556</contact:fax>
C:        <contact:email>麥克風@example.com</contact:email>
C:        <contact:authInfo>
C:          <contact:pw>2fooBAR</contact:pw>
C:        </contact:authInfo>
C:        <contact:disclose flag="0">
C:          <contact:voice/>
C:          <contact:email/>
C:        </contact:disclose>
C:      </contact:create>
C:    </create>
C:    <extension>
C:      <eai:eai
C:       xmlns:eai="urn:ietf:params:xml:ns:epp:eai-1.0">
C:        <eai:email>jdoe@example.com</eai:email>
C:      </eai:eai>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></sourcecode>
       </figure>

       <t>The following is an example &lt;create&gt; command to create a contact object with an alternate SMTPUTF8 email:</t>
       <figure>
            <name>Example &lt;create&gt; command to create a contact object with an alternate SMTPUTF8 email</name>

            <sourcecode type="xml" markers="false"><![CDATA[
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:      <contact:create
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C:        <contact:id>sh8013</contact:id>
C:        <contact:postalInfo type="int">
C:          <contact:name>John Doe</contact:name>
C:          <contact:org>Example Inc.</contact:org>
C:          <contact:addr>
C:            <contact:street>123 Example Dr.</contact:street>
C:            <contact:street>Suite 100</contact:street>
C:            <contact:city>Dulles</contact:city>
C:            <contact:sp>VA</contact:sp>
C:            <contact:pc>20166-6503</contact:pc>
C:            <contact:cc>US</contact:cc>
C:          </contact:addr>
C:        </contact:postalInfo>
C:        <contact:voice x="1234">+1.7035555555</contact:voice>
C:        <contact:fax>+1.7035555556</contact:fax>
C:        <contact:email>jdoe@example.com</contact:email>
C:        <contact:authInfo>
C:          <contact:pw>2fooBAR</contact:pw>
C:        </contact:authInfo>
C:        <contact:disclose flag="0">
C:          <contact:voice/>
C:          <contact:email/>
C:        </contact:disclose>
C:      </contact:create>
C:    </create>
C:    <extension>
C:      <eai:eai
C:       xmlns:eai="urn:ietf:params:xml:ns:epp:eai-1.0">
C:        <eai:email>麥克風@example.com</eai:email>
C:      </eai:eai>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></sourcecode>
       </figure>

       <t>This extension does not add any elements to the EPP &lt;create&gt; response described
       in <xref target="RFC5730"/>.</t>

      </section>
      <!-- end CREATE command -->

      <section anchor="deleteCommand" title="EPP &lt;delete&gt; Command">

       <t>This extension does not add any elements to the EPP &lt;delete&gt; command
       or &lt;delete&gt; response described in <xref target="RFC5730"/>.</t>

      </section>
      <!-- end DELETE command -->

      <section anchor="renewCommand" title="EPP &lt;renew&gt; Command">

       <t>This extension does not add any elements to the EPP &lt;renew&gt; command
       or &lt;renew&gt; response described in <xref target="RFC5730"/>.</t>

      </section>
      <!-- end RENEW command -->

      <section anchor="transferCommand" title="EPP &lt;transfer&gt; Command">

        <t>This extension does not add any elements to the EPP &lt;transfer&gt; command
        or &lt;transfer&gt; response described in <xref target="RFC5730"/>.</t>

      </section>
      <!-- end TRANSFER command -->

      <section anchor="updateCommand" title="EPP &lt;update&gt; Command">

        <t>This extension defines additional elements to extend the EPP
         &lt;update&gt; command of an object mapping like <xref target="RFC5733"/>.</t>

        <t>The EPP &lt;update&gt; command provides a transform operation that allows a client to update an instance of an object.
        In addition to the EPP command elements described in an object mapping like <xref target="RFC5733"/>, the command MUST contain a
        child <xref target="eaiElement">&lt;eai:eai&gt; element</xref> for the client to be set or unset an alternate email.
        If the alternate email does not apply to the object, the server MUST return an EPP error result code of 2201.</t>

        <t>The following is an example &lt;update&gt; command to set a contact object with an alternate ASCII email:</t>
        <figure>
             <name>Example &lt;update&gt; command to set a contact object with an alternate ASCII email</name>

             <sourcecode type="xml" markers="false"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C:   <update>
C:     <contact:update
C:      xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C:       <contact:id>sh8013</contact:id>
C:     </contact:update>
C:   </update>
C:   <extension>
C:     <eai:eai
C:      xmlns:eai="urn:ietf:params:xml:ns:epp:eai-1.0">
C:       <eai:email>jdoe@example.com</eai:email>
C:     </eai:eai>
C:   </extension>
C:   <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>]]></sourcecode>
        </figure>

        <t>The following is an example &lt;update&gt; command to set a contact object with an alternate SMTPUTF8 email:</t>
        <figure>
             <name>Example &lt;update&gt; command to set a contact object with an alternate SMTPUTF8 email</name>

             <sourcecode type="xml" markers="false"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C:   <update>
C:     <contact:update
C:      xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C:       <contact:id>sh8013</contact:id>
C:     </contact:update>
C:   </update>
C:   <extension>
C:     <eai:eai
C:      xmlns:eai="urn:ietf:params:xml:ns:epp:eai-1.0">
C:       <eai:email>麥克風@example.com</eai:email>
C:     </eai:eai>
C:   </extension>
C:   <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>]]></sourcecode>
        </figure>

        <t>The following is an example &lt;update&gt; command to unset a contact object alternate email:</t>
        <figure>
             <name>Example &lt;update&gt; command to unset a contact object alternate email</name>

             <sourcecode type="xml" markers="false"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C:   <update>
C:     <contact:update
C:      xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C:       <contact:id>sh8013</contact:id>
C:     </contact:update>
C:   </update>
C:   <extension>
C:     <eai:eai
C:      xmlns:eai="urn:ietf:params:xml:ns:epp:eai-1.0">
C:       <eai:email/>
C:     </eai:eai>
C:   </extension>
C:   <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>]]></sourcecode>
        </figure>


        <t>This extension does not add any elements to the EPP &lt;create&gt; response described
        in <xref target="RFC5730"/>.</t>

      </section>
      <!-- end UPDATE command -->

    </section>

    </section>

    <section anchor="syntax" numbered="true" toc="default">
      <name>Formal Syntax</name>
      <t>The EPP SMTPUTF8 Addresses Extension schema is presented here.</t>
      <t>The formal
      syntax shown here is a complete XML Schema representation of the object
      mapping suitable for automated validation of EPP XML instances. The
      &lt;CODE BEGINS&gt; and &lt;CODE ENDS&gt; tags are not part of the XML Schema; they are used to note the
      beginning and ending of the XML Schema for URI registration purposes.</t>
      <section numbered="true" toc="default">
        <name>SMTPUTF8 Addresses Schema</name>
<sourcecode type="xml" markers="true"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:eai="urn:ietf:params:xml:ns:epp:eai-1.0"
  targetNamespace="urn:ietf:params:xml:ns:epp:eai-1.0"
  elementFormDefault="qualified">
  <annotation>
    <documentation>Extensible Provisioning Protocol v1.0
       SMTPUTF8 Addresses Schema.</documentation>
  </annotation>
  <!-- Create, Update, and Info Response extension element -->
  <element name="eai" type="eai:eaiType" />
  <!--
    Single email element that can be empty
   -->
  <complexType name="eaiType">
    <sequence>
      <element name="email"
        type="token"/>
    </sequence>
  </complexType>
  <!--
 End of schema.
 -->
</schema>]]></sourcecode>
      </section>
    </section>

    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section numbered="true" toc="default">
        <name>XML Namespace</name>
        <t> This document uses URNs to describe XML namespaces
   conforming to a registry mechanism described in  <xref target="RFC3688" format="default">RFC 3688</xref>.  The
   following URI assignment should be made by IANA:</t>
   <t>Registration request for the eai namespace:</t>
   <dl newline="false" spacing="compact">
     <dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:epp:eai-1.0</dd>
     <dt>Registrant Contact:</dt>
<dd>IESG</dd>
     <dt>XML:</dt>
<dd>None. Namespace URIs do not represent an XML specification.</dd>
   </dl>
   <t>Registration request for the eai XML Schema:</t>
   <dl newline="false" spacing="compact">
     <dt>URI:</dt>
<dd>urn:ietf:params:xml:schema:epp:eai-1.0</dd>
     <dt>Registrant Contact:</dt>
<dd>IESG</dd>
     <dt>XML:</dt>
<dd>See the "Formal Syntax" section of this document.</dd>
   </dl>
      </section>
      <section numbered="true" toc="default">
        <name>EPP Extension Registry</name>
        <t>
   The EPP extension described in this document should be registered by
   IANA in the "Extensions for the Extensible Provisioning Protocol
   (EPP)" registry described in RFC 7451 <xref target="RFC7451" format="default"/>.  The details of the
   registration are as follows:
        </t>
        <dl newline="false" spacing="compact">
                <dt>Name of Extension:</dt>
        	<dd>"Use of Internationalized Email Addresses in EPP protocol"</dd>
                <dt>Document status:</dt>
        	<dd>Standards Track</dd>
                <dt>Reference:</dt>
        	<dd>RFC 8807</dd>
                <dt>Registrant Name and Email Address:</dt>
        	<dd>IESG, &lt;iesg@ietf.org&gt;</dd>
                <dt>Top-Level Domains(TLDs):</dt>
        	<dd>Any</dd>
                <dt>IPR Disclosure:</dt>
        	<dd>None</dd>
                <dt>Status:</dt>
        	<dd>Active</dd>
                <dt>Notes:</dt>
        	<dd>None</dd>
        	</dl>
      </section>
    </section>
    <section anchor="Implementation" numbered="true" toc="default">
      <name>Implementation Status</name>
      <t>Note to RFC Editor: Please remove this section and the reference to
         <xref target="RFC7942" format="default">RFC 7942</xref> before publication.</t>
      <t>This section records the status of known implementations of the
      protocol defined by this specification at the time of posting of
      this Internet-Draft, and is based on a proposal described in <xref target="RFC7942" format="default">RFC
      7942</xref>.  The description of implementations in this section is
      intended to assist the IETF in its decision processes in
      progressing drafts to RFCs.  Please note that the listing of any
      individual implementation here does not imply endorsement by the
      IETF.  Furthermore, no effort has been spent to verify the
      information presented here that was supplied by IETF contributors.
      This is not intended as, and must not be construed to be, a
      catalog of available implementations or their features.  Readers
      are advised to note that other implementations may exist.</t>

      <t>According to <xref target="RFC7942" format="default">RFC 7942</xref>, "this will allow reviewers and working
      groups to assign due consideration to documents that have the
      benefit of running code, which may serve as evidence of valuable
      experimentation and feedback that have made the implemented
      protocols more mature.  It is up to the individual working groups
      to use this information as they see fit".</t>

      <section numbered="true" toc="default">
        <name>Verisign EPP SDK</name>
        <t>Organization: Verisign Inc.</t>
        <t>Name: Verisign EPP SDK</t>
        <t>Description: The Verisign EPP SDK includes both a full client implementation
        and a full server stub implementation of draft-ietf-regext-epp-eai.</t>
        <t>Level of maturity: Development</t>
        <t>Coverage: All aspects of the protocol are implemented.</t>
        <t>Licensing: GNU Lesser General Public License</t>
        <t>Contact: jgould@verisign.com</t>
        <t>URL: https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks</t>
      </section>

    </section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t> The extended security considerations discussion in <xref target="RFC6530" format="default"/> and <xref target="RFC6531" format="default"/> applies here.</t>
      <t>
	As email address is often a primary end user contact, an invalid email address may put the communication with the end user into risk in case when such contact is necessary. In case of an invalid domain name in the email address a malicious actor can register a valid domain name with similar U-label (homograph attack) and get a control over the domain name associated with the contact using social engineering techniques. To reduce the risk of the use of invalid domain names in email addresses, registries <bcp14>SHOULD</bcp14> validate the domain name syntax in the provided email addresses and validate whether the domain name consists of the code
		points allowed by <eref target="https://www.iana.org/assignments/idna-tables">IDNA Rules and Derived Property Values</eref>.
	</t>
	<t>When the SMTPUTF8 extension is negotiated by both the client and the server, the client and server obligations defined in Section 5.3.1 MUST be satisfied.  If the obligations are not satisfied by either the client or server, the SMTPUTF8 address may be mishandled in processing or storage and be unusable.</t>
    </section>
    <section numbered="true" toc="default">
	    <name>Acknowledgments</name>
	    <t>The authors would like to thank
	    Alexander Mayrhofer,
	    Chris Lonvick,
	    Gustavo Lozano,
	    Jody Kolker,
	    John C Klensin,
	    John Levine,
	    Klaus Malorny,
	    Marc Blanchet,
	    Marco Schrieck,
	    Mario Loffredo,
	    Murray S. Kucherawy,
	    Patrick Mevzek,
	    Pete Resnick,
	    Scott Hollenbeck,
	    Takahiro Nemoto,
	    Taras Heichenko,
	    and Thomas Corte
	    for their careful review and valuable comments.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.27487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">
          <front>
            <title>The IETF XML Registry</title>
            <seriesInfo name="DOI" value="10.27487/RFC3688"/>
            <seriesInfo name="RFC" value="3688"/>
            <seriesInfo name="BCP" value="81"/>
            <author initials="M." surname="Mealling" fullname="M. Mealling">
              <organization/>
            </author>
            <date year="2004" month="January"/>
            <abstract>
              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
        </reference>
        &RFC5321;
        &RFC5322;
        <reference anchor="RFC5730" target="https://www.rfc-editor.org/info/rfc5730" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml">
          <front>
            <title>Extensible Provisioning Protocol (EPP)</title>
            <seriesInfo name="DOI" value="10.27487/RFC5730"/>
            <seriesInfo name="RFC" value="5730"/>
            <seriesInfo name="STD" value="69"/>
            <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
              <organization/>
            </author>
            <date year="2009" month="August"/>
            <abstract>
              <t>This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository.  Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects.  This document includes a protocol specification, an object mapping template, and an XML media type registration.  This document obsoletes RFC 4930.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5733" target="https://www.rfc-editor.org/info/rfc5733" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5733.xml">
          <front>
            <title>Extensible Provisioning Protocol (EPP) Contact Mapping</title>
            <seriesInfo name="DOI" value="10.27487/RFC5733"/>
            <seriesInfo name="RFC" value="5733"/>
            <seriesInfo name="STD" value="69"/>
            <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
              <organization/>
            </author>
            <date year="2009" month="August"/>
            <abstract>
              <t>This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository.  Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts.  This document obsoletes RFC 4933.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
&RFC5890;
&RFC6530;
&RFC6531;
&RFC6532;
&RFC7942;
&RFC8590;
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.27487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7451" target="https://www.rfc-editor.org/info/rfc7451" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7451.xml">
          <front>
            <title>Extension Registry for the Extensible Provisioning Protocol</title>
            <seriesInfo name="DOI" value="10.27487/RFC7451"/>
            <seriesInfo name="RFC" value="7451"/>
            <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
              <organization/>
            </author>
            <date year="2015" month="February"/>
            <abstract>
              <t>The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol.  It does not, however, describe how those extensions are managed.  This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8543" target="https://www.rfc-editor.org/info/rfc8543" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8543.xml">
          <front>
            <title>Extensible Provisioning Protocol (EPP) Organization Mapping</title>
            <seriesInfo name="DOI" value="10.27487/RFC8543"/>
            <seriesInfo name="RFC" value="8543"/>
            <author initials="L." surname="Zhou" fullname="L. Zhou">
              <organization/>
            </author>
            <author initials="N." surname="Kong" fullname="N. Kong">
              <organization/>
            </author>
            <author initials="J." surname="Yao" fullname="J. Yao">
              <organization/>
            </author>
            <author initials="J." surname="Gould" fullname="J. Gould">
              <organization/>
            </author>
            <author initials="G." surname="Zhou" fullname="G. Zhou">
              <organization/>
            </author>
            <date year="2019" month="March"/>
            <abstract>
              <t>This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of organization objects stored in a shared central repository.</t>
            </abstract>
          </front>
        </reference>
      </references>
    </references>
    <section numbered="true" toc="default">
      <name>Change History</name>
      <section anchor="change-00-to-01" numbered="true" toc="default">
        <name>Change from 00 to 01</name>
        <ol spacing="normal" type="1">
          <li>Changed from update of RFC 5733 to use the "Placeholder Text and a New Email Element" EPP Extension approach.</li>
        </ol>
      </section>
      <section anchor="change-01-to-02" numbered="true" toc="default">
        <name>Change from 01 to 02</name>
        <ol spacing="normal" type="1">
          <li>Fixed the XML schema and the XML examples based on validating them.</li>
          <li>Added James Gould as co-author.</li>
          <li>Updated the language to apply to any EPP object mapping and to use the EPP contact mapping as an example.</li>
          <li>Updated the structure of document to be consistent with the other Command-Response Extensions.</li>
          <li>Replaced the use of "eppEAI" in the XML namespace and the XML namespace prefix with "eai".</li>
          <li>Changed to use a pointed XML namespace with "0.2" instead of "1.0".</li>
        </ol>
      </section>
      <section anchor="change-02-to-03" numbered="true" toc="default">
        <name>Change from 02 to 03</name>
	<ol spacing="normal" type="1">
	  <li>The approach has changed to use the concept of Functional EPP Extension.</li>
	  <li>The examples are removed</li>
        </ol>
      </section>
      <section anchor="change-03-to-04" numbered="true" toc="default">
        <name>Change from 03 to 04</name>
	<ol spacing="normal" type="1">
	  <li>More detailed reference to email syntax is provided</li>
	  <li>The shortened eai namespace reference is removed</li>
        </ol>
      </section>
      <section anchor="change-04-to-ietf-01" numbered="true" toc="default">
        <name>Change from 04 to the regext 01 version</name>
	<ol spacing="normal" type="1">
	  <li>Provided the recommended placeholder value</li>
        </ol>
      </section>
      <section anchor="change-ietf-01-to-ietf-02" numbered="true" toc="default">
        <name>Change from the regext 01 to regext 02 version</name>
	<ol spacing="normal" type="1">
	  <li>Removed the concept of the placeholder value</li>
        </ol>
      </section>
      <section anchor="change-ietf-02-to-ietf-03" numbered="true" toc="default">
        <name>Change from the regext 02 to regext 03 version</name>
	<ol spacing="normal" type="1">
          <li>Changed to use a pointed XML namespace with "0.3" instead of "0.2".</li>
	  <li>Some wording improvements</li>
        </ol>
      </section>
      <section anchor="change-ietf-03-to-ietf-04" numbered="true" toc="default">
        <name>Change from the regext 03 to regext 04 version</name>
	<ol spacing="normal" type="1">
	  <li>Some nitpicking</li>
        </ol>
      </section>
      <section anchor="change-ietf-04-to-ietf-05" numbered="true" toc="default">
        <name>Change from the regext 04 to regext 05 version</name>
	<ol spacing="normal" type="1">
		<li>Some nitpicking</li>
		<li>The "Implementation considerations" section is removed</li>
        </ol>
      </section>
      <section anchor="change-ietf-05-to-ietf-06" numbered="true" toc="default">
        <name>Change from the regext 05 to regext 06 version</name>
	<ol spacing="normal" type="1">
		<li>Some nitpicking</li>
        </ol>
      </section>
      <section anchor="change-ietf-06-to-ietf-07" numbered="true" toc="default">
        <name>Change from the regext 06 to regext 07 version</name>
	<ol spacing="normal" type="1">
		<li>Namespace version set to 1.0</li>
        </ol>
      </section>
      <section anchor="change-ietf-07-to-ietf-08" numbered="true" toc="default">
        <name>Change from the regext 07 to regext 08 version</name>
	<ol spacing="normal" type="1">
		<li>Information about implementations is provided.</li>
		<li>Acknowledgments section is added.</li>
		<li>Reference to RFC 7451 is moved to Informative.</li>
		<li>IPR information is provided</li>
		<li>Sections are reordered to align with the other regext documents</li>
        </ol>
      </section>
      <section anchor="change-ietf-08-to-ietf-09" numbered="true" toc="default">
        <name>Change from the regext 08 to regext 09 version</name>
	<ol spacing="normal" type="1">
		<li>Nitpicking according to Murray S. Kucherawy review</li>
        </ol>
      </section>
      <section anchor="change-ietf-09-to-ietf-10" numbered="true" toc="default">
        <name>Change from the regext 09 to regext 10 version</name>
	<ol spacing="normal" type="1">
		<li>Some nitpicking in the security considerations.</li>
        </ol>
      </section>
      <section anchor="change-ietf-10-to-ietf-11" numbered="true" toc="default">
        <name>Change from the regext 10 to regext 11 version</name>
	<ol spacing="normal" type="1">
		<li>Nitpicking according mostly GenArt review.</li>
        </ol>
      </section>
      <section anchor="change-ietf-11-to-ietf-12" numbered="true" toc="default">
        <name>Change from the regext 11 to regext 12 version</name>
	<ol spacing="normal" type="1">
		<li>XML schema registration request removed.</li>
        </ol>
      </section>
      <section anchor="change-ietf-12-to-ietf-13" numbered="true" toc="default">
        <name>Change from the regext 12 to regext 13 version</name>
	<ol spacing="normal" type="1">
		<li>Document updated according to SecDir and ART-ART review.</li>
        </ol>
      </section>
      <section anchor="change-ietf-13-to-ietf-14" numbered="true" toc="default">
        <name>Change from the regext 13 to regext 14 version</name>
	<ol spacing="normal" type="1">
		<li>Document updated according the IANA review #1231866.</li>
        </ol>
      </section>
      <section anchor="change-ietf-14-to-ietf-15" numbered="true" toc="default">
        <name>Change from the regext 14 to regext 15 version</name>
	<ol spacing="normal" type="1">
		<li>Document updated according to ART-ART review.</li>
        </ol>
      </section>
    <section anchor="change-ietf-15-to-ietf-16" numbered="true" toc="default">
      <name>Change from the regext 15 to regext 16 version</name>
<ol spacing="normal" type="1">
  <li>Document removed the definition of the concept of a functional extension and updated to use a command-response extension, based on the feedback from John C Klensin.</li>
  <li>Document removed the EAI abbreviation and uses SMTPUTF8 as umbrella term instead, based on the feedback from John C Klensin.</li>
      </ol>
    </section>
    <section anchor="change-ietf-16-to-ietf-17" numbered="true" toc="default">
      <name>Change from the regext 16 to regext 17 version</name>
<ol spacing="normal" type="1">
  <li>Added support for an alternate email during a transition period, based on feedback from John C Klensin.</li>
      </ol>
    </section>
    <section anchor="change-ietf-17-to-ietf-18" numbered="true" toc="default">
      <name>Change from the regext 17 to regext 18 version</name>
<ol spacing="normal" type="1">
  <li>Roll back to approach in -16 with the Cardinality of One Option, posted to and supported on the mailing list.</li>
  <li>Replaced references of eai to smtputf8, based on feedback from John C Klensin.</li>
  <li>Revised the Security Considerations section based on feedback and text from Andy Newton.</li>
      </ol>
    </section>
    <section anchor="change-ietf-18-to-ietf-19" numbered="true" toc="default">
      <name>Change from the regext 18 to regext 19 version</name>
<ol spacing="normal" type="1">
  <li>Reverted back to -17 with support for one or two email addresses using either ASCII or SMTPUTF8 and remove any reference to the requirement for an ASCII email address and remove the concept of a transition period.</li>
      </ol>
    </section>
  </section>
  </back>
</rfc>