draft-ietf-regext-epp-eai-10.txt		draft-ietf-regext-epp-eai-11.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: 24 November 2022 VeriSign, Inc.		Expires: 7 December 2022 VeriSign, Inc.
	23 May 2022		5 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-10		draft-ietf-regext-epp-eai-11
	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		Extensible Provisioning Protocol (EPP), being developed before the
	appearing the standards for Internationalized Email Addresses (EAI),		standards for Internationalized Email Addresses (EAI), does not
	does not support such email addresses.		support such email addresses.
	TO BE REMOVED on turning to RFC: The document is edited in the		TO BE REMOVED on turning to RFC: The document is edited in the
	dedicated github repo (https://github.com/beldmit/eppeai). Please		dedicated github repo (https://github.com/beldmit/eppeai). Please
	send your submissions via GitHub.		send your submissions via GitHub.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 24 November 2022.		This Internet-Draft will expire on 7 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 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	A.5. Change from 04 to the regext 01 version . . . . . . . . . 11		A.5. Change from 04 to the regext 01 version . . . . . . . . . 11
	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 . . . . . 12
	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
	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 4, line 35 ¶		skipping to change at page 4, line 35 ¶
	schema type "eppcom:minTokenType" and the [RFC5322] format		schema type "eppcom:minTokenType" and the [RFC5322] format
	specification, where this extension applies to all EPP extensions		specification, where this extension applies to all EPP extensions
	with the same or similar definitions.		with the same or similar definitions.
	The email address format is formally defined in Section 3.4.1 of		The email address format is formally defined in Section 3.4.1 of
	[RFC5322], which only consists of printable US-ASCII characters for		[RFC5322], which only consists of printable US-ASCII characters for
	both the local-part and the domain ABNF rules. [RFC6531] extends the		both the local-part and the domain ABNF rules. [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 U-label, defined in Section 2.3.2.1 of [RFC5890], for the		part and U-label, defined in Section 2.3.2.1 of [RFC5890], for the
	domain. By applying the syntax rules of [RFC5322], the EPP		domain. By applying the syntax rules of [RFC6531], the EPP
	extensions will change from supporting only ASCII characters to		extensions will change from supporting only ASCII characters to
	supporting Internationalized characters both in the email address		supporting Internationalized characters both in the email address
	local-part and domain-part.		local-part and domain-part.
	4. Functional Extension		4. Functional Extension
	[RFC5730] defines three types of extensions at the protocol, object,		[RFC5730] defines three types of extensions at the protocol, object,
	and command-response level, which impact the structure of the EPP		and command-response level, which impact the structure of the EPP
	messages. A Functional Extension applies a functional capability to		messages. A Functional Extension applies a functional capability to
	an existing set of EPP extensions and properties. The scope of the		an existing set of EPP extensions and properties. The scope of the
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 41 ¶
	The lack of EAI support can cause data and functional issues, so an		The lack of EAI support can cause data and functional issues, so an
	EAI supporting client or server needs to handle cases where the		EAI supporting client or server needs to handle cases where the
	opposite party doesn't support EAI. Below are the server and client		opposite party doesn't support EAI. Below are the server and client
	obligations when the EAI extension is not negotiated due to the lack		obligations when the EAI extension is not negotiated due to the lack
	of support by the peer.		of support by the peer.
	The EAI supporting server MUST satisfy the following obligations when		The EAI supporting server MUST satisfy the following obligations when
	the client does not support the EAI extension:		the client does not support the EAI extension:
	* When the email property is required in the EPP command, the server		* When the email property is required in the EPP command, the server
	SHOULD validate the email property sent by the client using the		MUST validate the email property sent by the client using the
	ASCII email validation rules.		ASCII email validation rules.
	* When the email property is optional in the EPP command, if the		* When the email property is optional in the EPP command, if the
	client supplies the email property the server SHOULD validate the		client supplies the email property the server MUST validate the
	email property using the ASCII email validation rules.		email property using the ASCII email validation rules.
	* When the email property is required in the EPP response, the		* When the email property is required in the EPP response, the
	server MUST validate whether the email property is an EAI address		server MUST validate whether the email property is an EAI address
	and if so return the error code 2308 "Data management policy		and if so return the error code 2308 "Data management policy
	violation".		violation".
	* When the email property is optional in the EPP response and is		* When the email property is optional in the EPP response and is
	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
	skipping to change at page 9, line 31 ¶		skipping to change at page 9, line 31 ¶
	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 all
	code points in the domain name according to IDNA2008 [RFC5892].		code points in the domain name according to IDNA2008 [RFC5892].
	9. Acknowledgments		9. Acknowledgments
	The authors would like to thank Alexander Mayrhofer, Gustavo Lozano,		The authors would like to thank Alexander Mayrhofer, Gustavo Lozano,
	Jody Kolker, John Levine, Klaus Malorny, Marco Schrieck, Mario		Jody Kolker, John C Klensin, John Levine, Klaus Malorny, Marco
	Loffredo, Murray S. Kucherawy, Patrick Mevzek, Scott Hollenbeck,		Schrieck, Mario Loffredo, Murray S. Kucherawy, Patrick Mevzek, Pete
	Taras Heichenko, and Thomas Corte for their careful review and		Resnick, Scott Hollenbeck, Taras Heichenko, and Thomas Corte for
	valuable comments.		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 13, line 9 ¶		skipping to change at page 13, line 9 ¶
	5. Sections are reordered to align with the other regext documents		5. Sections are reordered to align with the other regext documents
	A.13. Change from the regext 08 to regext 09 version		A.13. Change from the regext 08 to regext 09 version
	1. Nitpicking according to Murray S. Kucherawy review		1. Nitpicking according to Murray S. Kucherawy review
	A.14. Change from the regext 09 to regext 10 version		A.14. Change from the regext 09 to regext 10 version
	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
			1. Nitpicking according mostly GenArt 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. 10 change blocks.
	15 lines changed or deleted		19 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/