draft-ietf-regext-epp-eai-08.txt   draft-ietf-regext-epp-eai-09.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: 5 October 2022 VeriSign, Inc. Expires: 23 November 2022 VeriSign, Inc.
3 April 2022 22 May 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-08 draft-ietf-regext-epp-eai-09
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 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 5 October 2022. This Internet-Draft will expire on 23 November 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 38 skipping to change at page 2, line 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 7 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 7
6.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 7 6.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 7
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
7.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 8 7.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . 11
A.6. Change from the regext 01 to regext 02 version . . . . . 11 A.6. Change from the regext 01 to regext 02 version . . . . . 12
A.7. Change from the regext 02 to regext 03 version . . . . . 11 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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 11 skipping to change at page 4, line 11
version of the extension is deployed. A newer version of the version of the extension is deployed. A newer version of the
extension is expected to use an XML namespace with a higher version extension is expected to use an XML namespace with a higher version
number than the prior versions. number than the prior versions.
3. Email Address Specification 3. Email Address Specification
Support of non-ASCII email address syntax is defined in RFC 6530 Support of non-ASCII email address syntax is defined in RFC 6530
[RFC6530]. This mapping does not prescribe minimum or maximum [RFC6530]. This mapping does not prescribe minimum or maximum
lengths for character strings used to represent email addresses. The lengths for character strings used to represent email addresses. The
exact syntax of such addresses is described in Section 3.3 of exact syntax of such addresses is described in Section 3.3 of
[RFC6531]. The validation rules introduced in RFC 6531 are [RFC6531]. The validation rules introduced in RFC 6531 MUST be
considered to be followed. followed when processing this extension.
The definition of email address in the EPP RFCs, including The definition of email address in the EPP RFCs, including
Section 2.6 of [RFC5733] and Section 4.1.2, 4.2.1, and 4.2.5 of Section 2.6 of [RFC5733] and Section 4.1.2, 4.2.1, and 4.2.5 of
[RFC8543], references [RFC5322] for the email address syntax. The [RFC8543], references [RFC5322] for the email address syntax. The
XML schema definition in Section 4 of [RFC5733] and Section 5 of XML schema definition in Section 4 of [RFC5733] and Section 5 of
[RFC8543] defines the "email" element using the type [RFC8543] defines the "email" element using the type
"eppcom:minTokenType", which is defined in Section 4.2 of [RFC5730] "eppcom:minTokenType", which is defined in Section 4.2 of [RFC5730]
as an XML schema "token" type with minimal length of one. The XML as an XML schema "token" type with minimal length of one. The XML
schema "token" type will fully support the use of EAI addresses, so schema "token" type will fully support the use of EAI addresses, so
the primary application of the EAI extension is to apply the use of the primary application of the EAI extension is to apply the use of
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 possibility to addresses during the session establishment, it implies the
process the EAI address in any message having an email property possibility to process the EAI address in any message having an email
during the established EPP session. Below are the server and client property during the established EPP session. Below are the server
obligations when the EAI extension has been successfuly negotiated in and client obligations when the EAI extension has been successfuly
the EPP session. negotiated in 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 9, line 14 skipping to change at page 9, line 14
Licensing: GNU Lesser General Public License Licensing: GNU Lesser General Public License
Contact: jgould@verisign.com Contact: jgould@verisign.com
URL: https://www.verisign.com/en_US/channel-resources/domain- URL: https://www.verisign.com/en_US/channel-resources/domain-
registry-products/epp-sdks registry-products/epp-sdks
8. Security Considerations 8. Security Considerations
Registries SHOULD validate the domain names syntax in the provided The extended security considerations discussion in [RFC6530] and
email addresses to reduce the risk of future usability errors. It is [RFC6531] applies here.
RECOMMENDED to validate all code points in the domain names according
to IDNA2008 [RFC5892]. As email address is often a primary end user contact, invalid email
address may put the communication with the end user into risk in case
when such contact is necessary. In case of invalid domain name a
malicious actor can register a valid domain with similar U-label
(homograph attack) and get a control over the domain using social
engineering techniques. To reduce the risk of the use of invalid
domain names in email addresses, registries SHOULD validate the
domain name syntax in the provided email addresses and validate all
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 Levine, Klaus Malorny, Marco Schrieck, Mario
Loffredo, Patrick Mevzek, Scott Hollenbeck, Taras Heichenko, and Loffredo, Murray S. Kucherawy, Patrick Mevzek, Scott Hollenbeck,
Thomas Corte for their careful review and valuable comments. 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 15 skipping to change at page 10, line 23
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", STD 69, RFC 5733, DOI 10.27487/RFC5733, Contact Mapping", STD 69, RFC 5733, DOI 10.27487/RFC5733,
August 2009, <https://www.rfc-editor.org/info/rfc5733>. August 2009, <https://www.rfc-editor.org/info/rfc5733>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 6530, DOI 10.27487/RFC6530, Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
February 2012, <https://www.rfc-editor.org/info/rfc6530>. February 2012, <https://www.rfc-editor.org/info/rfc6530>.
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, Email", RFC 6531, DOI 10.17487/RFC6531, February 2012,
<https://www.rfc-editor.org/info/rfc6531>. <https://www.rfc-editor.org/info/rfc6531>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>. 2012, <https://www.rfc-editor.org/info/rfc6532>.
skipping to change at page 12, line 39 skipping to change at page 12, line 46
1. Information about implementations is provided. 1. Information about implementations is provided.
2. Acknowledgments section is added. 2. Acknowledgments section is added.
3. Reference to RFC 7451 is moved to Informative. 3. Reference to RFC 7451 is moved to Informative.
4. IPR information is provided 4. IPR information is provided
5. Sections are reordered to align with the other regext documents 5. Sections are reordered to align with the other regext documents
Authors' Addresses A.13. Change from the regext 08 to regext 09 version
1. Nitpicking according to Murray S. Kucherawy review
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. 14 change blocks. 
22 lines changed or deleted 36 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/