idnits 2.17.00 (12 Aug 2021) /tmp/idnits27145/draft-belyavskiy-epp-eai-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 February 2021) is 446 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Belyavskiy 3 Internet-Draft 4 Intended status: Standards Track J. Gould 5 Expires: 26 August 2021 VeriSign, Inc. 6 22 February 2021 8 Use of Internationalized Email Addresses in EPP protocol 9 draft-belyavskiy-epp-eai-04 11 Abstract 13 This document describes an EPP extension that permits usage of 14 Internationalized Email Addresses in the EPP protocol and specifies 15 the terms when it can be used by EPP clients and servers. The 16 Extensible Provisioning Protocol (EPP), being developed before 17 appearing the standards for Internationalized Email Addresses (EAI), 18 does not support such email addresses. 20 TO BE REMOVED on turning to RFC: The document is edited in the 21 dedicated github repo (https://github.com/beldmit/eppeai). Please 22 send your submissions via GitHub. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 26 August 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 59 2. Migrating to Newer Versions of This Extension . . . . . . . . 3 60 3. Email Address Specification . . . . . . . . . . . . . . . . . 3 61 4. Functional Extension . . . . . . . . . . . . . . . . . . . . 4 62 5. Internationalized Email Addresses (EAI) Functional 63 Extension . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. Scope of Functional Extension . . . . . . . . . . . . . . 4 65 5.2. Signaling Client and Server Support . . . . . . . . . . . 5 66 5.3. Functional Extension Behavior . . . . . . . . . . . . . . 5 67 5.3.1. EAI Functional Extension Negotiated . . . . . . . . . 5 68 5.3.2. EAI Functional Extension Not Negotiated . . . . . . . 6 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 7 72 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 7 73 8. Implementation Considerations . . . . . . . . . . . . . . . . 8 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 9.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 9 78 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 9 79 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 9 80 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 10 81 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 [RFC6530] introduced the framework for Internationalized Email 87 Addresses. To make such addresses more widely accepted, the changes 88 to various protocols need to be introduced. 90 This document describes an Extensible Provisioning Protocol (EPP) 91 extension that permits usage of Internationalized Email Addresses in 92 the EPP protocol and specifies the terms when it can be used by EPP 93 clients and servers. A new form of EPP extension, referred to as a 94 Functional Extension, is defined and used to apply the rules for the 95 handling of email address elements in all of the [RFC5730] extensions 96 negotiated in the EPP session, which include the object and command- 97 responses extensions. The described mechanism can be applied to any 98 object or command-response extension that uses an email address. 100 The Extensible Provisioning Protocol (EPP) specified in [RFC5730] is 101 a base document for object management operations and an extensible 102 framework that maps protocol operations to objects. The specifics of 103 various objects managed via EPP is described in separate documents. 104 This document is only referring to an email address as a property of 105 a managed object, such as the element in the EPP 106 contact mapping [RFC5733] or the element in the EPP 107 organization mapping [RFC8543], and command-response extensions 108 applied to a managed object. 110 1.1. Conventions Used in This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 2. Migrating to Newer Versions of This Extension 120 Servers that implement this extension SHOULD provide a way for 121 clients to progressively update their implementations when a new 122 version of the extension is deployed. A newer version of the 123 extension is expected to use an XML namespace with a higher version 124 number than the prior versions. 126 3. Email Address Specification 128 Support of non-ASCII email address syntax is defined in RFC 6530 129 [RFC6530]. This mapping does not prescribe minimum or maximum 130 lengths for character strings used to represent email addresses. The 131 exact syntax of such addresses is described in Section 3.3 of 132 [RFC6531]. The validation rules introduced in RFC 6531 are 133 considered to be followed. 135 The definition of email address in the EPP RFCs, including 136 Section 2.6 of [RFC5733] and Section 4.1.2, 4.2.1, and 4.2.5 of 137 [RFC8543], references [RFC5322] for the email address syntax. The 138 XML schema definition in Section 4 of [RFC5733] and Section 5 of 139 [RFC8543] defines the "email" element using the type 140 "eppcom:minTokenType", which is defined in Section 4.2 of [RFC5730] 141 as an XML schema "token" type with minimal length of one. The XML 142 schema "token" type will fully support the use of EAI addresses, so 143 the primary application of the EAI extension is to apply the use of 144 [RFC6531] instead of [RFC5322] for the email address syntax. Other 145 EPP extensions may follow the formal syntax definition using the XML 146 schema type "eppcom:minTokenType" and the [RFC5322] format 147 specification, where this extension applies to all EPP extensions 148 with the same or similar definitions. 150 The email address format is formally defined in Section 3.4.1 of 151 [RFC5322], which only consists of printable US-ASCII characters for 152 both the local-part and the domain ABNF rules. In [RFC6531], the 153 extends the Mailbox, Local-part and Domain ABNF rules in [RFC5321] to 154 support "UTF8-non-ascii", defined in Section 3.1 of [RFC6532], for 155 the local-part and U-label, defined in Section 2.3.2.1 of [RFC5890], 156 for the domain. By applying the syntax rules of [RFC5322], the EPP 157 extensions will change from supporting only ASCII characters to 158 supporting Internationailzed characters in the email address local- 159 part and domain-part. 161 4. Functional Extension 163 [RFC5730] defines three types of extensions at the protocol, object, 164 and command-response level, which impact the structure of the EPP 165 messages. A Functional Extension applies a functional capability to 166 an existing set of EPP extensions and properties. The scope of the 167 applicable EPP extensions and applicable extension properties are 168 defined in the Functional Extension along with the requirements for 169 the servers and clients that support it. The Functional Extension 170 needs to cover the expected behavior of the supporting client or 171 server when interfacing with an unsupporting client or server. 172 Negotiating support for a Functional Extension is handled using the 173 EPP Greeting and EPP Login services. 175 5. Internationalized Email Addresses (EAI) Functional Extension 177 5.1. Scope of Functional Extension 179 The functional extension applies to all object extensions and 180 command-response extensions negotiated in the EPP session that 181 include email address properties. Examples include the 182 element in the EPP contact mapping [RFC5733] or the 183 element in the EPP organization mapping [RFC8543]. All 184 registry zones (e.g., top-level domains) authorized for the client in 185 the EPP session apply. There is no concept of a per-client, per- 186 zone, per-extension, or per-field setting that is used to indicate 187 support for EAI, but instead it's a global setting that applies to 188 the EPP session. 190 5.2. Signaling Client and Server Support 192 The client and the server can signal support for the functional 193 extension using a namespace URI in the login and greeting extension 194 services. The namespace URI "urn:ietf:params:xml:ns:epp:eai-0.2" is 195 used to signal support for the functional extension. The client 196 includes the namespace URI in an element of 197 the [RFC5730] Command. The server includes the namespace URI 198 in an element of the [RFC5730] Greeting. 200 5.3. Functional Extension Behavior 202 5.3.1. EAI Functional Extension Negotiated 204 If both client and server have indicated the support of the EAI 205 addresses during the session establishment, it implies possibility to 206 process the EAI address in any message having an email property 207 during the established EPP session. Below are the server and client 208 obligations when the EAI extension has been successfuly negotiated in 209 the EPP session. 211 The server MUST satisfy the following obligations when the EAI 212 extension has been negotiated: 214 * Accept EAI compatible addresses for all email properties in the 215 EPP session negotiated object extensions and command-response 216 extensions. For example the element in [RFC5733] 217 and the element in [RFC8543]. 219 * Accept EAI compatible addresses for all registry zones (e.g., top- 220 level domains) authorized for the client in the EPP session. 222 * Email address validation based on EAI validation rules defined in 223 Section 3 225 * Storage of email properties that supports internationalized 226 characters. 228 * Return EAI compatible addresses for all email properties in the 229 EPP responses. 231 The server MUST satisfy the following obligations when THE EAI 232 extension has been negotiated: 234 * Provide EAI compatible addresses for all e-mail properties in the 235 EPP session negotiated object extensions and command-response 236 extensions. For example the element in [RFC5733] 237 and the element in [RFC8543]. 239 * Provide EAI compatible addresses for all registry zones (e.g., 240 top-level domains) authorized for the client in the EPP session. 242 * Accept EAI compatible addresses in the EPP responses for all email 243 properties in the EPP session negotiated object extensions and 244 command-response extensions. 246 5.3.2. EAI Functional Extension Not Negotiated 248 The lack of EAI support can cause data and functional issues, so an 249 EAI supporting client or server needs to handle cases where the 250 opposite party doesn't support EAI. Below are the server and client 251 obligations when the EAI extension is not negotiated due to the lack 252 of support by the opposite party. 254 The EAI supporting server MUST satisfy the following obligations when 255 the client does not support the EAI extension: 257 * When the email property is required in the EPP extension command, 258 the server SHOULD validate the email property by the client using 259 the ASCII email validation rules. 261 * When the email property is optional according the EPP extension 262 command, if the client supplies the email property the server 263 SHOULD validate the email property using the ASCII email 264 validation rules. 266 * When the email property is required in the EPP extension response, 267 the server MUST validate whether the email property is an EAI 268 address and if so return the predefined placeholder email TBD and 269 otherwise return the email property that has been set. 271 * When the email property is optional in the EPP extension response, 272 the server MUST validate whether the email property is an EAI 273 address and if so don't return the email property in the response 274 and otherwise return the email property that has been set based on 275 server policy. 277 The EAI supporting client MUST satisfy the following obligations when 278 the server does not support the EAI extension: 280 * When the email property is required in the EPP extension command 281 and the email property is an EAI address with no alternative ASCII 282 address, the client MUST provide the predefined placeholder email 283 address TBD. 285 * When the email property is optional in the EPP extension command 286 and the email property is an EAI address with no alternative ASCII 287 address, the client SHOULD omit the email property. 289 6. Security Considerations 291 Registries SHOULD validate the domain names in the provided email 292 addresses. This can be done by validating all code points according 293 to IDNA2008 [RFC5892]. 295 7. IANA Considerations 297 7.1. XML Namespace 299 This document uses URNs to describe XML namespaces and XML schemas 300 conforming to a registry mechanism described in RFC 3688 [RFC3688]. 301 The following URI assignment should be made by IANA: 303 Registration request for the eai namespace: 305 URI: urn:ietf:params:xml:ns:epp:eai-0.2 306 Registrant Contact: IESG 307 XML: None. Namespace URIs do not represent an XML specification. 309 Registration request for the eai XML Schema: 311 URI: urn:ietf:params:xml:schema:epp:eai-0.2 312 Registrant Contact: IESG 313 XML: See the "Formal Syntax" section of this document. 315 7.2. EPP Extension Registry 317 The EPP extension described in this document should be registered by 318 IANA in the "Extensions for the Extensible Provisioning Protocol 319 (EPP)" registry described in RFC 7451 [RFC7451]. The details of the 320 registration are as follows: 322 Name of Extension: Use of Internationalized Email Addresses 323 in EPP protocol 324 Document status: Standards Track 325 Reference: TBA 326 Registrant Name and Email Address: IESG, 327 Top-Level Domains(TLDs): Any 328 IPR Disclosure: None 329 Status: Active 330 Notes: None 332 8. Implementation Considerations 334 Registries MAY apply extra limitation to the email address syntax 335 (e.g. the addresses can be limited to Left-to-Right scripts). These 336 limitations are out of scope of this document. 338 9. References 340 9.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.27487/RFC2119, March 1997, 345 . 347 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 348 DOI 10.27487/RFC3688, January 2004, 349 . 351 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 352 DOI 10.17487/RFC5321, October 2008, 353 . 355 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 356 DOI 10.17487/RFC5322, October 2008, 357 . 359 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 360 STD 69, RFC 5730, DOI 10.27487/RFC5730, August 2009, 361 . 363 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 364 Contact Mapping", STD 69, RFC 5733, DOI 10.27487/RFC5733, 365 August 2009, . 367 [RFC5890] Klensin, J., "Internationalized Domain Names for 368 Applications (IDNA): Definitions and Document Framework", 369 RFC 5890, DOI 10.17487/RFC5890, August 2010, 370 . 372 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 373 Internationalized Email", RFC 6530, DOI 10.27487/RFC6530, 374 February 2012, . 376 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 377 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 378 . 380 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 381 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 382 2012, . 384 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 385 Provisioning Protocol", RFC 7451, DOI 10.27487/RFC7451, 386 February 2015, . 388 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 389 2119 Key Words", BCP 14, RFC 8174, DOI 10.27487/RFC8174, 390 May 2017, . 392 9.2. Informative References 394 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 395 Internationalized Domain Names for Applications (IDNA)", 396 RFC 5892, DOI 10.27487/RFC5892, August 2010, 397 . 399 [RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou, 400 "Extensible Provisioning Protocol (EPP) Organization 401 Mapping", RFC 8543, DOI 10.27487/RFC8543, March 2019, 402 . 404 Appendix A. Change History 406 A.1. Change from 00 to 01 408 1. Changed from update of RFC 5733 to use the "Placeholder Text and 409 a New Email Element" EPP Extension approach. 411 A.2. Change from 01 to 02 413 1. Fixed the XML schema and the XML examples based on validating 414 them. 416 2. Added James Gould as co-author. 418 3. Updated the language to apply to any EPP object mapping and to 419 use the EPP contact mapping as an example. 421 4. Updated the structure of document to be consistent with the other 422 Command-Response Extensions. 424 5. Replaced the use of "eppEAI" in the XML namespace and the XML 425 namespace prefix with "eai". 427 6. Changed to use a pointed XML namespace with "0.2" instead of 428 "1.0". 430 A.3. Change from 02 to 03 432 1. The approach has changed to use the concept of Functional EPP 433 Extension. 435 2. The examples are removed 437 A.4. Change from 03 to 04 439 1. More detailed reference to email syntax is provided 441 2. The shortened eai namespace reference is removed 443 Authors' Addresses 445 Dmitry Belyavskiy 446 8 marta st. 447 Moscow 448 127083 449 Russian Federation 451 Phone: +7 916 262 5593 452 Email: beldmit@gmail.com 454 James Gould 455 VeriSign, Inc. 456 12061 Bluemont Way 457 Reston, VA 20190 458 United States of America 460 Email: jgould@verisign.com 461 URI: http://www.verisigninc.com