Diff: rfc9873v1.txt - rfc9873.txt

	rfc9873v1.txt	rfc9873.txt

	Internet Engineering Task Force (IETF) D. Belyavskiy	Internet Engineering Task Force (IETF) D. Belyavskiy
	Request for Comments: 9873	Request for Comments: 9873
	Category: Standards Track J. Gould	Category: Standards Track J. Gould
	ISSN: 2070-1721 VeriSign, Inc.	ISSN: 2070-1721 VeriSign, Inc.
	S. Hollenbeck	S. Hollenbeck
	Verisign Labs	Verisign Labs

	September 2025	October 2025

	Additional Email Address Extension for the Extensible Provisioning	Additional Email Address Extension for the Extensible Provisioning
	Protocol (EPP)	Protocol (EPP)

	Abstract	Abstract


	The Extensible Provisioning Protocol (EPP) does not natively support	The Extensible Provisioning Protocol (EPP) does not inherently
	internationalized email addresses because the specifications for	support internationalized email addresses because the specifications
	these addresses did not exist when EPP was developed. This document	for these addresses did not exist when EPP was developed. This
	describes a command-response extension that adds support for	document describes a command-response extension that adds support for
	associating an additional email address with an EPP contact object.	associating an additional email address with an EPP contact object.
	That additional email address can be either an internationalized	That additional email address can be either an internationalized

	email address or an all-ASCII address.	email address or an ASCII-only address.

	Status of This Memo	Status of This Memo

	This is an Internet Standards Track document.	This is an Internet Standards Track document.

	This document is a product of the Internet Engineering Task Force	This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has	(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the	received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on	Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.	Internet Standards is available in Section 2 of RFC 7841.

	skipping to change at line 111 ¶	skipping to change at line 111 ¶
	delivery issues.	delivery issues.

	While this extension adds support for an additional email address to	While this extension adds support for an additional email address to
	contact objects, and that additional email address can be an SMTPUTF8	contact objects, and that additional email address can be an SMTPUTF8
	address, it does not in any way update or change any other EPP	address, it does not in any way update or change any other EPP
	extension that includes an email address. Adding support for	extension that includes an email address. Adding support for
	SMTPUTF8 addresses to those extensions will require an update to the	SMTPUTF8 addresses to those extensions will require an update to the
	relevant extension specifications. In cases where a contact object	relevant extension specifications. In cases where a contact object
	contains two email addresses, all users of these addresses should be	contains two email addresses, all users of these addresses should be
	aware that either address may be forwarded to the other. This	aware that either address may be forwarded to the other. This

	implies that a message sent to an all-ASCII address may receive a	implies that a message sent to an ASCII-only address may receive a
	reply from an SMTPUTF8 address or vice versa.	reply from an SMTPUTF8 address or vice versa.

	1.1. Conventions Used in This Document	1.1. Conventions Used in This Document

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in	"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.


	skipping to change at line 134 ¶	skipping to change at line 134 ¶
	character case presented in order to develop a conforming	character case presented in order to develop a conforming
	implementation.	implementation.

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

	The XML namespace prefix "addlEmail" is used for the namespace	The XML namespace prefix "addlEmail" is used for the namespace
	"urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST	"urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST

	NOT depend on it and instead employ a proper namespace-aware XML	NOT depend on it and instead MUST employ a proper namespace-aware XML
	parser and serializer to interpret and output the XML documents.	parser and serializer to interpret and output the XML documents.

	2. Email Address Specification	2. Email Address Specification

	The EPP contact object mapping [RFC5733] normatively references	The EPP contact object mapping [RFC5733] normatively references
	[RFC5322] as the specification for email address syntax. That	[RFC5322] as the specification for email address syntax. That
	specification does not include support for internationalized email	specification does not include support for internationalized email
	addresses. [RFC6530] provides an overview and describes the	addresses. [RFC6530] provides an overview and describes the
	framework for internationalized email. SMTPUTF8 email address syntax	framework for internationalized email. SMTPUTF8 email address syntax
	is described in Section 3.3 of [RFC6531]. [RFC6531] extends the	is described in Section 3.3 of [RFC6531]. [RFC6531] extends the
	Mailbox, Local-part, and Domain ABNF rules in [RFC5321] to support	Mailbox, Local-part, and Domain ABNF rules in [RFC5321] to support
	"UTF8-non-ascii" (defined in Section 3.1 of [RFC6532]) for the local-	"UTF8-non-ascii" (defined in Section 3.1 of [RFC6532]) for the local-
	part and to support U-label (defined in Section 2.3.2.1 of [RFC5890])	part and to support U-label (defined in Section 2.3.2.1 of [RFC5890])
	for the domain. The validation rules described in [RFC6531] MUST be	for the domain. The validation rules described in [RFC6531] MUST be
	followed when processing internationalized email addresses associated	followed when processing internationalized email addresses associated
	with this extension.	with this extension.

	3. Additional Email Address Element	3. Additional Email Address Element

	A second email address can be set using the <addlEmail:addlEmail>	A second email address can be set using the <addlEmail:addlEmail>

	element with the command and response extensions defined in	element with the command-response extensions defined in Section 5.
	Section 5. The <addlEmail:addlEmail> element contains the following	The <addlEmail:addlEmail> element contains the following child
	child element:	element:

	<addlEmail:email>: An element following the syntax in Section 2 for	<addlEmail:email>: An element following the syntax in Section 2 for
	defining a second ASCII or SMTPUTF8 address. An empty	defining a second ASCII or SMTPUTF8 address. An empty
	<addlEmail:email/> element unsets the second email address in the	<addlEmail:email/> element unsets the second email address in the
	Update Command (Section 5.2.5) and indicates the second email is	Update Command (Section 5.2.5) and indicates the second email is
	not set in the Info Response (Section 5.1.2). The	not set in the Info Response (Section 5.1.2). The
	<addlEmail:email> element contains an OPTIONAL "primary"	<addlEmail:email> element contains an OPTIONAL "primary"
	attribute that can be used to indicate that the extension email	attribute that can be used to indicate that the extension email
	address should be treated as the primary email address for the	address should be treated as the primary email address for the
	extended contact object. The "primary" attribute MUST NOT be	extended contact object. The "primary" attribute MUST NOT be

	skipping to change at line 179 ¶	skipping to change at line 179 ¶

	Additional email address considerations:	Additional email address considerations:

	* The value set for the <contact:disclose><contact:email/> "flag"	* The value set for the <contact:disclose><contact:email/> "flag"
	attribute (described in Section 2.9 of [RFC5733]) MUST also be	attribute (described in Section 2.9 of [RFC5733]) MUST also be
	applied to all additional email addresses that are added by a	applied to all additional email addresses that are added by a
	contact extension.	contact extension.

	* Any address included in an extension is intended to be an	* Any address included in an extension is intended to be an
	additional address that is associated only with the primary	additional address that is associated only with the primary

	<contact:email> address, and that support for any other additional	<contact:email> address, and support for any other additional
	email addresses MUST explicitly describe how the additional	email addresses MUST explicitly describe how the additional
	addresses are associated with the existing addresses.	addresses are associated with the existing addresses.

	4. Extension Considerations	4. Extension Considerations

	4.1. Signaling Client and Server Support	4.1. Signaling Client and Server Support

	As described in Section 2.4 of [RFC5730], the client and the server	As described in Section 2.4 of [RFC5730], the client and the server
	can signal support for the extension using a namespace URI in the	can signal support for the extension using a namespace URI in the
	login and greeting extension services, respectively. The namespace	login and greeting extension services, respectively. The namespace

	skipping to change at line 216 ¶	skipping to change at line 216 ¶

	The server MUST satisfy the following obligations when support for	The server MUST satisfy the following obligations when support for
	this extension has been negotiated:	this extension has been negotiated:

	* Accept SMTPUTF8-compliant addresses for the extended contact	* Accept SMTPUTF8-compliant addresses for the extended contact
	object in the EPP session.	object in the EPP session.

	* Support email address validation based on the SMTPUTF8 validation	* Support email address validation based on the SMTPUTF8 validation
	rules defined in Section 2.	rules defined in Section 2.


	* Storage of email properties that support internationalized	* Store email properties that support internationalized characters.
	characters.

	* Return SMTPUTF8-compliant addresses for the extended contact	* Return SMTPUTF8-compliant addresses for the extended contact
	object in EPP responses.	object in EPP responses.

	* Support the SMTP extension for internationalized email described	* Support the SMTP extension for internationalized email described
	in [RFC6531] when sending or receiving email.	in [RFC6531] when sending or receiving email.

	The client MUST satisfy the following obligations when support for	The client MUST satisfy the following obligations when support for
	this extension has been negotiated:	this extension has been negotiated:


	skipping to change at line 270 ¶	skipping to change at line 269 ¶

	5.1.2. EPP <info> Command	5.1.2. EPP <info> Command

	This extension does not add any elements to the EPP <info> command	This extension does not add any elements to the EPP <info> command
	response described in [RFC5730].	response described in [RFC5730].

	If the query is successful, the server replies with an	If the query is successful, the server replies with an
	<addlEmail:addlEmail> element (Section 3) along with the regular EPP	<addlEmail:addlEmail> element (Section 3) along with the regular EPP
	<resData>.	<resData>.


	The following is an example <info> contact response using the
	<addlEmail:addlEmail> extension with no alternate email address:

	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <resData>	S: <resData>
	S: <contact:infData	S: <contact:infData
	S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">	S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
	S: <contact:id>sh8013</contact:id>	S: <contact:id>sh8013</contact:id>

	skipping to change at line 332 ¶	skipping to change at line 328 ¶
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	Figure 1: Example <info> Contact Response Using the	Figure 1: Example <info> Contact Response Using the
	<addlEmail:addlEmail> Extension with No Alternate Email Address	<addlEmail:addlEmail> Extension with No Alternate Email Address


	The following is an example <info> contact response using the
	<addlEmail:addlEmail> extension with an ASCII alternate email
	address:

	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <resData>	S: <resData>
	S: <contact:infData	S: <contact:infData
	S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">	S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
	S: <contact:id>sh8013</contact:id>	S: <contact:id>sh8013</contact:id>

	skipping to change at line 393 ¶	skipping to change at line 385 ¶
	S: </addlEmail:addlEmail>	S: </addlEmail:addlEmail>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	Figure 2: Example <info> Contact Response Using the	Figure 2: Example <info> Contact Response Using the

	<addlEmail:addlEmail> Extension with an ASCII Alternate Email	<addlEmail:addlEmail> Extension with an Alternate ASCII Email
	Address	Address


	The following is an example <info> contact response using the
	<addlEmail:addlEmail> extension with an SMTPUTF8 primary email
	address:

	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <resData>	S: <resData>
	S: <contact:infData	S: <contact:infData
	S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">	S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
	S: <contact:id>sh8013</contact:id>	S: <contact:id>sh8013</contact:id>

	skipping to change at line 477 ¶	skipping to change at line 465 ¶

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

	5.2.1. EPP <create> Command	5.2.1. EPP <create> Command

	This extension defines additional elements to extend the EPP <create>	This extension defines additional elements to extend the EPP <create>

	command of an object mapping like [RFC5733].	command described in [RFC5733].

	The EPP <create> command provides a transform operation that allows a	The EPP <create> command provides a transform operation that allows a
	client to create an instance of an object. In addition to the EPP	client to create an instance of an object. In addition to the EPP

	command elements described in an object mapping like [RFC5733], the	command elements described in [RFC5733], the command MUST contain a
	command MUST contain a child <addlEmail:addlEmail> element	child <addlEmail:addlEmail> element (Section 3) for the client to set
	(Section 3) for the client to set an alternate email address.	an alternate email address.

	The following is an example <create> command to create a contact
	object with an alternate ASCII email address:

	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>	C: <command>
	C: <create>	C: <create>
	C: <contact:create	C: <contact:create
	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
	C: <contact:id>sh8013</contact:id>	C: <contact:id>sh8013</contact:id>
	C: <contact:postalInfo type="int">	C: <contact:postalInfo type="int">
	C: <contact:name>John Doe</contact:name>	C: <contact:name>John Doe</contact:name>

	skipping to change at line 532 ¶	skipping to change at line 517 ¶
	C: <addlEmail:email>jdoe-alt@example.net</addlEmail:email>	C: <addlEmail:email>jdoe-alt@example.net</addlEmail:email>
	C: </addlEmail:addlEmail>	C: </addlEmail:addlEmail>
	C: </extension>	C: </extension>
	C: <clTRID>ABC-12345</clTRID>	C: <clTRID>ABC-12345</clTRID>
	C: </command>	C: </command>
	C:</epp>	C:</epp>

	Figure 4: Example <create> Command to Create a Contact Object	Figure 4: Example <create> Command to Create a Contact Object
	with an Alternate ASCII Email Address	with an Alternate ASCII Email Address


	The following is an example <create> command to create a contact
	object with a primary SMTPUTF8 email address:

	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>	C: <command>
	C: <create>	C: <create>
	C: <contact:create	C: <contact:create
	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
	C: <contact:id>sh8013</contact:id>	C: <contact:id>sh8013</contact:id>
	C: <contact:postalInfo type="int">	C: <contact:postalInfo type="int">
	C: <contact:name>John Doe</contact:name>	C: <contact:name>John Doe</contact:name>
	C: <contact:org>Example Inc.</contact:org>	C: <contact:org>Example Inc.</contact:org>

	skipping to change at line 601 ¶	skipping to change at line 583 ¶
	or <renew> response described in [RFC5730].	or <renew> response described in [RFC5730].

	5.2.4. EPP <transfer> Command	5.2.4. EPP <transfer> Command

	This extension does not add any elements to the EPP <transfer>	This extension does not add any elements to the EPP <transfer>
	command or <transfer> response described in [RFC5730].	command or <transfer> response described in [RFC5730].

	5.2.5. EPP <update> Command	5.2.5. EPP <update> Command

	This extension defines additional elements to extend the EPP <update>	This extension defines additional elements to extend the EPP <update>

	command of an object mapping like [RFC5733].	command described in [RFC5733].

	The EPP <update> command provides a transform operation that allows a	The EPP <update> command provides a transform operation that allows a
	client to update an instance of an object. In addition to the EPP	client to update an instance of an object. In addition to the EPP

	command elements described in an object mapping like [RFC5733], the	command elements described in [RFC5733], the command MUST contain a
	command MUST contain a child <addlEmail:addlEmail> element	child <addlEmail:addlEmail> element (Section 3) for the client to set
	(Section 3) for the client to set or unset an alternate email	or unset an alternate email address. If the alternate email address
	address. If the alternate email address cannot be applied to the	cannot be applied to the object, the server MUST return an EPP error
	object, the server MUST return an EPP error result code of 2201.	result code of 2201.

	The following is an example <update> command to set a contact object
	with an alternate ASCII email address:

	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>	C: <command>
	C: <update>	C: <update>
	C: <contact:update	C: <contact:update
	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
	C: <contact:id>sh8013</contact:id>	C: <contact:id>sh8013</contact:id>
	C: </contact:update>	C: </contact:update>
	C: </update>	C: </update>

	skipping to change at line 636 ¶	skipping to change at line 615 ¶
	C: <addlEmail:email>jdoe-alt@example.net</addlEmail:email>	C: <addlEmail:email>jdoe-alt@example.net</addlEmail:email>
	C: </addlEmail:addlEmail>	C: </addlEmail:addlEmail>
	C: </extension>	C: </extension>
	C: <clTRID>ABC-12345</clTRID>	C: <clTRID>ABC-12345</clTRID>
	C: </command>	C: </command>
	C:</epp>	C:</epp>

	Figure 6: Example <update> Command to Set a Contact Object with	Figure 6: Example <update> Command to Set a Contact Object with
	an Alternate ASCII Email Address	an Alternate ASCII Email Address


	The following is an example <update> command to set a contact object
	with an alternate SMTPUTF8 email address:

	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>	C: <command>
	C: <update>	C: <update>
	C: <contact:update	C: <contact:update
	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
	C: <contact:id>sh8013</contact:id>	C: <contact:id>sh8013</contact:id>
	C: </contact:update>	C: </contact:update>
	C: </update>	C: </update>
	C: <extension>	C: <extension>

	skipping to change at line 661 ¶	skipping to change at line 637 ¶
	C: <addlEmail:email>麥克風@example.com</addlEmail:email>	C: <addlEmail:email>麥克風@example.com</addlEmail:email>
	C: </addlEmail:addlEmail>	C: </addlEmail:addlEmail>
	C: </extension>	C: </extension>
	C: <clTRID>ABC-12345</clTRID>	C: <clTRID>ABC-12345</clTRID>
	C: </command>	C: </command>
	C:</epp>	C:</epp>

	Figure 7: Example <update> Command to Set a Contact Object with	Figure 7: Example <update> Command to Set a Contact Object with
	an Alternate SMTPUTF8 Email Address	an Alternate SMTPUTF8 Email Address


	The following is an example <update> command to unset a contact
	object alternate email address:

	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>	C: <command>
	C: <update>	C: <update>
	C: <contact:update	C: <contact:update
	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">	C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
	C: <contact:id>sh8013</contact:id>	C: <contact:id>sh8013</contact:id>
	C: </contact:update>	C: </contact:update>
	C: </update>	C: </update>
	C: <extension>	C: <extension>

	skipping to change at line 739 ¶	skipping to change at line 712 ¶
	<!--	<!--
	End of schema.	End of schema.
	-->	-->
	</schema>	</schema>
	<CODE ENDS>	<CODE ENDS>

	7. IANA Considerations	7. IANA Considerations

	7.1. XML Namespace	7.1. XML Namespace


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

	Registration for the addlEmail namespace:	Registration for the addlEmail namespace:

	URI: urn:ietf:params:xml:ns:epp:addlEmail-1.0	URI: urn:ietf:params:xml:ns:epp:addlEmail-1.0
	Registrant Contact: IESG	Registrant Contact: IESG
	XML: None. Namespace URIs do not represent an XML specification.	XML: None. Namespace URIs do not represent an XML specification.

	Registration for the addlEmail XML Schema:	Registration for the addlEmail XML Schema:

	URI: urn:ietf:params:xml:schema:epp:addlEmail-1.0	URI: urn:ietf:params:xml:schema:epp:addlEmail-1.0

	skipping to change at line 776 ¶	skipping to change at line 749 ¶
	Registrant Name and Email Address: IESG, <iesg@ietf.org>	Registrant Name and Email Address: IESG, <iesg@ietf.org>
	TLDs: Any	TLDs: Any
	IPR Disclosure: None	IPR Disclosure: None
	Status: Active	Status: Active
	Notes: None	Notes: None

	8. Security Considerations	8. Security Considerations

	As noted in Sections 10.1 and 13 of [RFC6530], unconstrained Unicode	As noted in Sections 10.1 and 13 of [RFC6530], unconstrained Unicode
	in email addresses can introduce a class of security threats that do	in email addresses can introduce a class of security threats that do

	not exist with all-ASCII email addresses. As EPP exists in	not exist with ASCII-only email addresses. As EPP exists in
	ecosystems where email addresses passed in EPP are displayed in the	ecosystems where email addresses passed in EPP are displayed in the
	Registration Data Access Protocol (RDAP) and other services, and	Registration Data Access Protocol (RDAP) and other services, and
	copy-and-paste of these email addresses is common for businesses	copy-and-paste of these email addresses is common for businesses
	transferring domains via EPP, there should be safeguards against	transferring domains via EPP, there should be safeguards against
	these threats. Therefore, use of the SMTPUTF8 email addresses as	these threats. Therefore, use of the SMTPUTF8 email addresses as
	described in this document SHOULD be done with policies that disallow	described in this document SHOULD be done with policies that disallow
	the use of unconstrained Unicode. The domain-part of these SMTPUTF8	the use of unconstrained Unicode. The domain-part of these SMTPUTF8

	email addresses SHOULD conform to IDNA2008. The local-part of these	email addresses SHOULD conform to IDNA2008 [RFC5895]. The local-part
	SMTPUTF8 email addresses SHOULD be restricted to Unicode that does	of these SMTPUTF8 email addresses SHOULD be restricted to Unicode
	not introduce the threats noted in [RFC6530]. One such possible	that does not introduce the threats noted in [RFC6530]. One such
	solution would be to disallow characters outside of Unicode Annex 31	possible solution would be to disallow characters outside of Unicode
	[Unicode-UAX31].	Annex 31 [Unicode-UAX31].

	As an email address is often a primary end user contact, an invalid	As an email address is often a primary end user contact, an invalid
	email address may put communication with the end user at risk when	email address may put communication with the end user at risk when
	such contact is necessary. In case of an invalid domain name in the	such contact is necessary. In case of an invalid domain name in the
	email address, a malicious actor can register a valid domain name	email address, a malicious actor can register a valid domain name
	with a similar U-label (homograph attack) and assume control over the	with a similar U-label (homograph attack) and assume control over the
	domain name associated with the contact using social engineering	domain name associated with the contact using social engineering
	techniques. To reduce the risk of the use of invalid domain names in	techniques. To reduce the risk of the use of invalid domain names in
	email addresses, registries SHOULD validate the domain name syntax in	email addresses, registries SHOULD validate the domain name syntax in

	the provided email addresses and validate whether the domain name	provided email addresses and validate whether the domain name
	consists of the code points allowed by "IDNA Rules and Derived	consists of the code points listed in the "IDNA Rules and Derived
	Property Values" (https://www.iana.org/assignments/idna-tables).	Property Values" registry <https://www.iana.org/assignments/idna-
		tables>).


	Note that the syntax for internationalized email localparts is very	Note that the syntax for internationalized email local-parts is very
	liberal. Domains are normalized during MX lookup, while localparts	liberal. Domains are normalized during MX lookup, while local-parts
	are unconstrained. Implementers may wish to test that their database	are unconstrained. Implementers may wish to test that their database

	is able to store difficult localparts such as U+0061 U+0300 U+00E0.	is able to store difficult local-parts such as U+0061 U+0300 U+00E0.
	For more on normalization and these three code points, see [RFC5198],	For more on normalization and these three code points, see [RFC5198],
	Section 3.	Section 3.

	9. Privacy Considerations	9. Privacy Considerations

	The content of <addlEmail:email> elements can be processed by EPP	The content of <addlEmail:email> elements can be processed by EPP
	clients and servers in the same way that <contact:email> elements are	clients and servers in the same way that <contact:email> elements are
	processed, including publication in directory services such as RDAP	processed, including publication in directory services such as RDAP
	[STD95]. Many data protection regulations recognize email addresses	[STD95]. Many data protection regulations recognize email addresses
	as personal data, so any policies governing the collection,	as personal data, so any policies governing the collection,

	skipping to change at line 887 ¶	skipping to change at line 861 ¶
	2: Datatypes Second Edition", W3C Recommendation, 28	2: Datatypes Second Edition", W3C Recommendation, 28
	October 2004,	October 2004,
	<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.	<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

	10.2. Informative References	10.2. Informative References

	[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network	[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
	Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,	Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
	<https://www.rfc-editor.org/info/rfc5198>.	<https://www.rfc-editor.org/info/rfc5198>.


		[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
		Internationalized Domain Names in Applications (IDNA)
		2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
		<https://www.rfc-editor.org/info/rfc5895>.

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

	[STD95] Internet Standard 95,	[STD95] Internet Standard 95,
	<https://www.rfc-editor.org/info/std95>.	<https://www.rfc-editor.org/info/std95>.
	At the time of writing, this STD comprises the following:	At the time of writing, this STD comprises the following:

	Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the	Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
	Registration Data Access Protocol (RDAP)", STD 95,	Registration Data Access Protocol (RDAP)", STD 95,

	skipping to change at line 952 ¶	skipping to change at line 931 ¶
	Czech Republic	Czech Republic
	Phone: +420 603 261 036	Phone: +420 603 261 036
	Email: beldmit@gmail.com	Email: beldmit@gmail.com

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

	URI: https://www.verisigninc.com	URI: https://www.verisign.com

	Scott Hollenbeck	Scott Hollenbeck
	Verisign Labs	Verisign Labs
	12061 Bluemont Way	12061 Bluemont Way
	Reston, VA 20190	Reston, VA 20190
	United States of America	United States of America
	Email: shollenbeck@verisign.com	Email: shollenbeck@verisign.com
	URI: https://www.verisignlabs.com/	URI: https://www.verisignlabs.com/

End of changes. 27 change blocks.
	67 lines changed or deleted	46 lines changed or added
This html diff was produced by rfcdiff 1.48.