Diff: draft-ietf-regext-epp-eai-02.txt - draft-ietf-regext-epp-eai-03.txt

	draft-ietf-regext-epp-eai-02.txt	draft-ietf-regext-epp-eai-03.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: 9 February 2022 VeriSign, Inc.	Expires: 14 February 2022 VeriSign, Inc.
	8 August 2021	13 August 2021


	Use of Internationalized Email Addresses in EPP protocol	Use of Internationalized Email Addresses in the Extensible Provisioning
	draft-ietf-regext-epp-eai-02	Protocol (EPP)
		draft-ietf-regext-epp-eai-03

	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
	appearing the standards for Internationalized Email Addresses (EAI),	appearing the standards for Internationalized Email Addresses (EAI),
	does not support such email addresses.	does not support such email addresses.


	skipping to change at page 1, line 40 ¶	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 9 February 2022.	This Internet-Draft will expire on 14 February 2022.

	Copyright Notice	Copyright Notice

	Copyright (c) 2021 IETF Trust and the persons identified as the	Copyright (c) 2021 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
	and restrictions with respect to this document. Code Components	and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text	extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are	as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.	provided without warranty as described in the Simplified BSD License.

	Table of Contents	Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions Used in This Document . . . . . . . . . . . . 3	1.1. Conventions Used in This Document . . . . . . . . . . . . 3

	skipping to change at page 2, line 40 ¶	skipping to change at page 2, line 43 ¶
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8	9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 9	9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix A. Change History . . . . . . . . . . . . . . . . . . . 9	Appendix A. Change History . . . . . . . . . . . . . . . . . . . 9
	A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 9	A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 9
	A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 9	A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 9
	A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 10	A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 10
	A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 10	A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 10
	A.5. Change from 04 to the regext 01 version . . . . . . . . . 10	A.5. Change from 04 to the regext 01 version . . . . . . . . . 10
	A.6. Change from the regext 01 to regext 02 version . . . . . 10	A.6. Change from the regext 01 to regext 02 version . . . . . 10

		A.7. Change from the regext 02 to regext 03 version . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10

	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 10 ¶	skipping to change at page 5, line 13 ¶
	the EPP session apply. There is no concept of a per-client, per-	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	zone, per-extension, or per-field setting that is used to indicate
	support for EAI, but instead it's a global setting that applies to	support for EAI, but instead it's a global setting that applies to
	the EPP session.	the EPP session.

	5.2. Signaling Client and Server Support	5.2. Signaling Client and Server Support

	The client and the server can signal support for the functional	The client and the server can signal support for the functional
	extension using a namespace URI in the login and greeting extension	extension using a namespace URI in the login and greeting extension
	services respectively. The namespace URI	services respectively. The namespace URI

	"urn:ietf:params:xml:ns:epp:eai-0.2" is used to signal support for	"urn:ietf:params:xml:ns:epp:eai-0.3" is used to signal support for
	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

	skipping to change at page 6, line 28 ¶	skipping to change at page 6, line 28 ¶

	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 response, the	* When the email property is required in the EPP command, the server
	server SHOULD validate the email property sent by the client using	SHOULD validate the email property sent by the client using the
	the ASCII email validation rules.	ASCII email validation rules.


	* When the email property is optional according the EPP response, if	* When the email property is optional in the EPP command, if the
	the client supplies the email property the server SHOULD validate	client supplies the email property the server SHOULD validate the
	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" and otherwise return the email property that has been	violation".
	set.


	* When the email property is optional in the EPP response, the	* When the email property is optional in the EPP response and is
	server MUST validate whether the email property is an EAI address	provided, the server MUST validate whether the email property is
	and if so don't return the email property in the response and	an EAI address and if so return the error code 2308 "Data
	otherwise return the email property that has been set based on	management policy violation".
	server policy.

	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 request and the	* When the email property is required in the EPP command and the
	email property is an EAI address, the client MUST provide the	email property is an EAI address, the client MUST provide an ASCII
	ASCII email address. The provided email address should provide a	email address. The provided email address should provide a way to
	way to contact the registrant. It can be a secondary ASCII email	contact the registrant. It can be a secondary ASCII email address
	address or registrar-provided proxy email address.	or registrar-provided proxy email address.


	* When the email property is optional in the EPP request 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 with no alternative ASCII

	address, the client SHOULD omit the email property.	address, the client SHOULD omit the email property. If the email
		property is provided, the client MUST provide an ASCII email
		address. The provided email address should provide a way to
		contact the registrant. It can be a secondary ASCII email address
		or registrar-provided proxy email address.

	6. Security Considerations	6. Security Considerations

	Registries SHOULD validate the domain names in the provided email	Registries SHOULD validate the domain names in the provided email
	addresses. This can be done by validating all code points according	addresses. This can be done by validating all code points according
	to IDNA2008 [RFC5892].	to IDNA2008 [RFC5892].

	7. IANA Considerations	7. IANA Considerations

	7.1. XML Namespace	7.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:


	URI: urn:ietf:params:xml:ns:epp:eai-0.2	URI: urn:ietf:params:xml:ns:epp:eai-0.3
	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 request for the eai XML Schema:	Registration request for the eai XML Schema:


	URI: urn:ietf:params:xml:schema:epp:eai-0.2	URI: urn:ietf:params:xml:schema:epp:eai-0.3
	Registrant Contact: IESG	Registrant Contact: IESG
	XML: See the "Formal Syntax" section of this document.	XML: See the "Formal Syntax" section of this document.

	7.2. EPP Extension Registry	7.2. EPP Extension Registry

	The EPP extension described in this document should be registered by	The EPP extension described in this document should be registered by
	IANA in the "Extensions for the Extensible Provisioning Protocol	IANA in the "Extensions for the Extensible Provisioning Protocol
	(EPP)" registry described in RFC 7451 [RFC7451]. The details of the	(EPP)" registry described in RFC 7451 [RFC7451]. The details of the
	registration are as follows:	registration are as follows:


	skipping to change at page 10, line 40 ¶	skipping to change at page 10, line 40 ¶
	2. The shortened eai namespace reference is removed	2. The shortened eai namespace reference is removed

	A.5. Change from 04 to the regext 01 version	A.5. Change from 04 to the regext 01 version

	1. Provided the recommended placeholder value	1. Provided the recommended placeholder value

	A.6. Change from the regext 01 to regext 02 version	A.6. Change from the regext 01 to regext 02 version

	1. Removed the concept of the placeholder value	1. Removed the concept of the placeholder value


	Authors' Addresses	A.7. Change from the regext 02 to regext 03 version

		1. Changed to use a pointed XML namespace with "0.3" instead of
		"0.2".


		2. Some wording improvements

		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


	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: http://www.verisigninc.com	URI: http://www.verisigninc.com

End of changes. 18 change blocks.
	30 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/