draft-ietf-regext-epp-eai-12.txt		draft-ietf-regext-epp-eai-13.txt
	Network Working Group D. Belyavskiy		Network Working Group D. Belyavskiy
	Internet-Draft		Internet-Draft
	Intended status: Standards Track J. Gould		Intended status: Standards Track J. Gould
	Expires: 10 December 2022 VeriSign, Inc.		Expires: 17 December 2022 VeriSign, Inc.
	8 June 2022		15 June 2022
	Use of Internationalized Email Addresses in the Extensible Provisioning		Use of Internationalized Email Addresses in the Extensible Provisioning
	Protocol (EPP)		Protocol (EPP)
	draft-ietf-regext-epp-eai-12		draft-ietf-regext-epp-eai-13
	Abstract		Abstract
	This document describes an EPP extension that permits usage of		This document describes an EPP extension that permits usage of
	Internationalized Email Addresses in the EPP protocol and specifies		Internationalized Email Addresses in the EPP protocol and specifies
	the terms when it can be used by EPP clients and servers. The		the terms when it can be used by EPP clients and servers. The
	Extensible Provisioning Protocol (EPP), being developed before the		Extensible Provisioning Protocol (EPP), being developed before the
	standards for Internationalized Email Addresses (EAI), does not		standards for Internationalized Email Addresses (EAI), does not
	support such email addresses.		support such email addresses.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 10 December 2022.		This Internet-Draft will expire on 17 December 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Change History . . . . . . . . . . . . . . . . . . . 11		Appendix A. Change History . . . . . . . . . . . . . . . . . . . 11
	A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 11		A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 11
	A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 11		A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 11
	A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 11		A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 11
	A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 11		A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 11
	A.5. Change from 04 to the regext 01 version . . . . . . . . . 11		A.5. Change from 04 to the regext 01 version . . . . . . . . . 12
	A.6. Change from the regext 01 to regext 02 version . . . . . 12		A.6. Change from the regext 01 to regext 02 version . . . . . 12
	A.7. Change from the regext 02 to regext 03 version . . . . . 12		A.7. Change from the regext 02 to regext 03 version . . . . . 12
	A.8. Change from the regext 03 to regext 04 version . . . . . 12		A.8. Change from the regext 03 to regext 04 version . . . . . 12
	A.9. Change from the regext 04 to regext 05 version . . . . . 12		A.9. Change from the regext 04 to regext 05 version . . . . . 12
	A.10. Change from the regext 05 to regext 06 version . . . . . 12		A.10. Change from the regext 05 to regext 06 version . . . . . 12
	A.11. Change from the regext 06 to regext 07 version . . . . . 12		A.11. Change from the regext 06 to regext 07 version . . . . . 12
	A.12. Change from the regext 07 to regext 08 version . . . . . 12		A.12. Change from the regext 07 to regext 08 version . . . . . 12
	A.13. Change from the regext 08 to regext 09 version . . . . . 12		A.13. Change from the regext 08 to regext 09 version . . . . . 13
	A.14. Change from the regext 09 to regext 10 version . . . . . 13		A.14. Change from the regext 09 to regext 10 version . . . . . 13
	A.15. Change from the regext 10 to regext 11 version . . . . . 13		A.15. Change from the regext 10 to regext 11 version . . . . . 13
	A.16. Change from the regext 11 to regext 12 version . . . . . 13		A.16. Change from the regext 11 to regext 12 version . . . . . 13
			A.17. Change from the regext 12 to regext 13 version . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	[RFC6530] introduced the framework for Internationalized Email		[RFC6530] introduced the framework for Internationalized Email
	Addresses. To make such addresses more widely accepted, the changes		Addresses. To make such addresses more widely accepted, the changes
	to various protocols need to be introduced.		to various protocols need to be introduced.
	This document describes an Extensible Provisioning Protocol (EPP)		This document describes an Extensible Provisioning Protocol (EPP)
	extension that permits usage of Internationalized Email Addresses in		extension that permits usage of Internationalized Email Addresses in
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 36 ¶
	the functional extension. The client includes the namespace URI in		the functional extension. The client includes the namespace URI in
	an <svcExtension> <extURI> element of the [RFC5730] <login> Command.		an <svcExtension> <extURI> element of the [RFC5730] <login> Command.
	The server includes the namespace URI in an <svcExtension> <extURI>		The server includes the namespace URI in an <svcExtension> <extURI>
	element of the [RFC5730] Greeting.		element of the [RFC5730] Greeting.
	5.3. Functional Extension Behavior		5.3. Functional Extension Behavior
	5.3.1. EAI Functional Extension Negotiated		5.3.1. EAI Functional Extension Negotiated
	If both client and server have indicated the support of the EAI		If both client and server have indicated the support of the EAI
	addresses during the session establishment, it implies the		addresses during the session establishment, they MUST be able to
	possibility to process the EAI address in any message having an email		process the EAI address in any message having an email property
	property during the established EPP session. Below are the server		during the established EPP session. Below are the server and client
	and client obligations when the EAI extension has been successfuly		obligations when the EAI extension has been successfuly negotiated in
	negotiated in the EPP session.		the EPP session.
	The server MUST satisfy the following obligations when the EAI		The server MUST satisfy the following obligations when the EAI
	extension has been negotiated:		extension has been negotiated:
	* Accept EAI compatible addresses for all email properties in the		* Accept EAI compatible addresses for all email properties in the
	EPP session negotiated object extensions and command-response		EPP session negotiated object extensions and command-response
	extensions. For example the <contact:email> element in [RFC5733]		extensions. For example the <contact:email> element in [RFC5733]
	and the <org:email> element in [RFC8543].		and the <org:email> element in [RFC8543].
	* Accept EAI compatible addresses for all registry zones (e.g., top-		* Accept EAI compatible addresses for all registry zones (e.g., top-
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	provided, the server MUST validate whether the email property is		provided, the server MUST validate whether the email property is
	an EAI address and if so return the error code 2308 "Data		an EAI address and if so return the error code 2308 "Data
	management policy violation".		management policy violation".
	The EAI supporting client MUST satisfy the following obligations when		The EAI supporting client MUST satisfy the following obligations when
	the server does not support the EAI extension:		the server does not support the EAI extension:
	* When the email property is required in the EPP command and the		* When the email property is required in the EPP command and the
	email property is an EAI address, the client MUST provide an ASCII		email property is an EAI address, the client MUST provide an ASCII
	email address. The provided email address should provide a way to		email address. The provided email address should provide a way to
	contact the registrant. It can be a secondary ASCII email address		contact the registrant. It can be an extra ASCII email address
	or registrar-provided proxy email address.		collected by registrar or registrar-provided proxy email address.
	* When the email property is optional in the EPP command and the		* When the email property is optional in the EPP command and the
	email property is an EAI address with no alternative ASCII		email property is an EAI address and client does not have an ASCII
	address, the client SHOULD omit the email property. If the email		address providing a way to contact the registrant, the client MUST
	property is provided, the client MUST provide an ASCII email		omit the email property. If the email property is provided, the
	address. The provided email address should provide a way to		client MUST provide an ASCII email address. The provided address
	contact the registrant. It can be a secondary ASCII email address		can be an extra ASCII email address collected by registrar or
	or registrar-provided proxy email address.		registrar-provided proxy email address.
	6. IANA Considerations		6. IANA Considerations
	6.1. XML Namespace		6.1. XML Namespace
	This document uses URNs to describe XML namespaces and XML schemas		This document uses URNs to describe XML namespaces and XML schemas
	conforming to a registry mechanism described in RFC 3688 [RFC3688].		conforming to a registry mechanism described in RFC 3688 [RFC3688].
	The following URI assignment should be made by IANA:		The following URI assignment should be made by IANA:
	Registration request for the eai namespace:		Registration request for the eai namespace:
	skipping to change at page 9, line 25 ¶		skipping to change at page 9, line 25 ¶
	[RFC6531] applies here.		[RFC6531] applies here.
	As email address is often a primary end user contact, an invalid		As email address is often a primary end user contact, an invalid
	email address may put the communication with the end user into risk		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		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		name in the email address a malicious actor can register a valid
	domain name with similar U-label (homograph attack) and get a control		domain name with similar U-label (homograph attack) and get a control
	over the domain name associated with the contact using social		over the domain name associated with the contact using social
	engineering techniques. To reduce the risk of the use of invalid		engineering techniques. To reduce the risk of the use of invalid
	domain names in email addresses, registries SHOULD validate the		domain names in email addresses, registries SHOULD validate the
	domain name syntax in the provided email addresses and validate all		domain name syntax in the provided email addresses and validate
	code points in the domain name according to IDNA2008 [RFC5892].		whether the domain name consists of the code points allow:ed by IDNA
			Rules and Derived Property Values (https://www.iana.org/assignments/
			idna-tables).
			When the EAI functional 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 EAI address may be
			mishandled in processing or storage and be unusable.
	9. Acknowledgments		9. Acknowledgments
	The authors would like to thank Alexander Mayrhofer, Gustavo Lozano,		The authors would like to thank Alexander Mayrhofer, Chris Lonvick,
	Jody Kolker, John C Klensin, John Levine, Klaus Malorny, Marco		Gustavo Lozano, Jody Kolker, John C Klensin, John Levine, Klaus
	Schrieck, Mario Loffredo, Murray S. Kucherawy, Patrick Mevzek, Pete		Malorny, Marc Blanchet, Marco Schrieck, Mario Loffredo, Murray S.
	Resnick, Scott Hollenbeck, Taras Heichenko, and Thomas Corte for		Kucherawy, Patrick Mevzek, Pete Resnick, Scott Hollenbeck, Takahiro
	their careful review and valuable comments.		Nemoto, Taras Heichenko, and Thomas Corte for their careful review
			and valuable comments.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.27487/RFC2119, March 1997,		DOI 10.27487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 10, line 45 ¶		skipping to change at page 11, line 5 ¶
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		RFC 7942, DOI 10.17487/RFC7942, July 2016,
	<https://www.rfc-editor.org/info/rfc7942>.		<https://www.rfc-editor.org/info/rfc7942>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.27487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.27487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	10.2. Informative References		10.2. Informative References
	[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
	Internationalized Domain Names for Applications (IDNA)",
	RFC 5892, DOI 10.27487/RFC5892, August 2010,
	<https://www.rfc-editor.org/info/rfc5892>.
	[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible		[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
	Provisioning Protocol", RFC 7451, DOI 10.27487/RFC7451,		Provisioning Protocol", RFC 7451, DOI 10.27487/RFC7451,
	February 2015, <https://www.rfc-editor.org/info/rfc7451>.		February 2015, <https://www.rfc-editor.org/info/rfc7451>.
	[RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou,		[RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou,
	"Extensible Provisioning Protocol (EPP) Organization		"Extensible Provisioning Protocol (EPP) Organization
	Mapping", RFC 8543, DOI 10.27487/RFC8543, March 2019,		Mapping", RFC 8543, DOI 10.27487/RFC8543, March 2019,
	<https://www.rfc-editor.org/info/rfc8543>.		<https://www.rfc-editor.org/info/rfc8543>.
	Appendix A. Change History		Appendix A. Change History
	skipping to change at page 13, line 17 ¶		skipping to change at page 13, line 21 ¶
	1. Some nitpicking in the security considerations.		1. Some nitpicking in the security considerations.
	A.15. Change from the regext 10 to regext 11 version		A.15. Change from the regext 10 to regext 11 version
	1. Nitpicking according mostly GenArt review.		1. Nitpicking according mostly GenArt review.
	A.16. Change from the regext 11 to regext 12 version		A.16. Change from the regext 11 to regext 12 version
	1. XML schema registration request removed.		1. XML schema registration request removed.
			A.17. Change from the regext 12 to regext 13 version
			1. Document updated according to SecDir and ART-ART review.
	Authors' Addresses		Authors' Addresses
	Dmitry Belyavskiy		Dmitry Belyavskiy
	8 marta st.		8 marta st.
	Moscow		Moscow
	127083		127083
	Russian Federation		Russian Federation
	Phone: +7 916 262 5593		Phone: +7 916 262 5593
	Email: beldmit@gmail.com		Email: beldmit@gmail.com
End of changes. 13 change blocks.
	31 lines changed or deleted		40 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/