idnits 2.17.1 draft-belyavskiy-epp-eai-02.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 (18 November 2020) is 1255 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) == Missing Reference: 'EAI-ADDRESS' is mentioned on line 164, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3735 ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: 22 May 2021 VeriSign, Inc. 6 18 November 2020 8 Use of Internationalized Email Addresses in EPP protocol 9 draft-belyavskiy-epp-eai-02 11 Abstract 13 This document permits usage of Internationalized Email Addresses in 14 the EPP protocol. The Extensible Provisioning Protocol (EPP), being 15 developed before appearing the standards for Internationalized Email 16 Addresses (EAI), does not support such email addressed. This 17 document describes an EPP extension that allows EAI addresses to be 18 used with an EPP object mapping like the EPP contact mapping. 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 22 May 2021. 41 Copyright Notice 43 Copyright (c) 2020 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. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Extension Element . . . . . . . . . . . . . . . 4 62 3.2. [EAI-ADDRESS] Email Value . . . . . . . . . . . . . . . . 4 63 4. Email Address Specification . . . . . . . . . . . . . . . . . 4 64 5. EPP commands mapping . . . . . . . . . . . . . . . . . . . . 4 65 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 66 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 5 67 5.1.2. EPP command . . . . . . . . . . . . . . . . . 5 68 5.1.3. EPP Command . . . . . . . . . . . . . . . 6 69 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 7 70 5.2.1. EPP command . . . . . . . . . . . . . . . . 7 71 5.2.2. EPP Command . . . . . . . . . . . . . . . . 8 72 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 9 73 5.2.4. EPP Command . . . . . . . . . . . . . . . 9 74 5.2.5. EPP command . . . . . . . . . . . . . . . . 9 75 6. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 11 79 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 12 80 9. Implementation Considerations . . . . . . . . . . . . . . . . 12 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 10.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 13 85 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 13 86 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 RFC 6530 [RFC6530] introduced the framework for Internationalized 92 Email Addresses. To make such addresses more widely accepted, the 93 changes to various protocols need to be introduced. 95 This document describes an Extensible Provisioning Protocol (EPP) 96 extension for using the Email Addresses Internationalized (EAI) in an 97 extension to EPP object mappings like the EPP contact mapping 98 [RFC5733]. The extension can be applied to any EPP object mapping 99 that uses an email address, where the EPP contact mapping [RFC5733] 100 is used in the examples. 102 The Extensible Provisioning Protocol (EPP) specified in RFC 5730 103 [RFC5730] is a base document for object management operations and an 104 extensible framework that maps protocol operations to objects. The 105 specifics of various objects managed via EPP is described in separate 106 documents. This document is only referring to an email address as a 107 property of a managed object, such as the element in 108 the EPP contact mapping [RFC5733] or the element in the 109 EPP organization mapping [RFC8543]. 111 RFC 3735 [RFC3735] provides a guideline to extend the EPP protocol 112 for various purposes. This extension represents a Command-Response 113 Extension. 115 1.1. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 In examples, "C:" represents lines sent by a protocol client and "S:" 124 represents lines returned by a protocol server. In examples, 125 indentation and whitespace are provided only to illustrate element 126 relationships and are not a required feature of this protocol. 128 "eai-0.1" is used as an abbreviation for 129 "urn:ietf:params:xml:ns:epp:eai-0.1". The XML namespace prefix "eai" 130 is used, but implementations MUST NOT depend on it. Instead, they 131 are to employ a proper namespace-aware XML parser and serializer to 132 interpret and output the XML documents. 134 2. Migrating to Newer Versions of This Extension 136 Servers that implement this extension SHOULD provide a way for 137 clients to progressively update their implementations when a new 138 version of the extension is deployed. A newer version of the 139 extension is expected to use an XML namespace with a higher version 140 number than the prior versions. 142 3. Object Attributes 144 This extension adds additional elements to EPP object mappings like 145 the EPP contact mapping [RFC5733]. Only those new elements are 146 described here. 148 3.1. Extension Element 150 The element can be added to a command or response to 151 override an email element using the "[EAI-ADDRESS]" value, as 152 described in Section 3.2. The element element contains the 153 following child elements: 155 : Contains an email address matching the specification in 156 RFC 6530 [RFC6530]. 158 Example element containing an EAI email address: 160 161 someaddress@example.com 162 164 3.2. [EAI-ADDRESS] Email Value 166 When an EPP object mapping email element contains the predefined 167 value of "[EAI-ADDRESS]", the element overrides the EPP 168 object mapping email element, which is a constant value for the 169 server to use the element for the value. The "[EAI- 170 ADDRESS]" predefined string MUST be supported by the server for the 171 client to explicitly indicate to the server whether to use 172 element in place of the EPP object email element. The 173 server MUST NOT allow the client to set the EPP object mapping email 174 element to the value "[EAI-ADDRESS]". 176 4. Email Address Specification 178 Email address syntax is defined in in RFC 6530 [RFC6530]. This 179 mapping does not prescribe minimum or maximum lengths for character 180 strings used to represent email addresses. 182 5. EPP commands mapping 184 A detailed description of the EPP syntax and semantics can be found 185 in the EPP core protocol specification [RFC5730]. 187 5.1. EPP Query Commands 189 EPP provides three commands to retrieve object information: 190 to determine if an object is known to the server, to retrieve 191 detailed information associated with an object, and to 192 retrieve object transfer status information. 194 5.1.1. EPP Command 196 This extension does not add any elements to the EPP command 197 or response described in the [RFC5730]. 199 5.1.2. EPP command 201 This extension does not define additional elements to extend the EPP 202 command of an EPP object mapping, but does include additional 203 elements to extend the EPP response. 205 If the query was successful, the server replies with the regular EPP 206 . If the client includes the "eai-0.1" XML namespace in the 207 login services, the email address exists, and the email address was 208 set using the extension in the create command (Section 5.2.1) or 209 update command (Section 5.2.5), then the EPP object mapping email 210 element SHOULD be set with the value "[EAI-ADDRESS]" value, as 211 described in Section 3.2, and the extension element 212 (Section 3.1) is included in the response with the email address 213 value. 215 Example response for the authorized client: 217 S: 218 S: 219 S: 220 S: 221 S: Command completed successfully 222 S: 223 S: 224 S: 226 S: sh8013 227 S: SH8013-REP 228 S: 229 S: 230 S: 231 S: John Doe 232 S: Example Inc. 233 S: 234 S: 123 Example Dr. 235 S: Suite 100 236 S: Dulles 237 S: VA 238 S: 20166-6503 239 S: US 240 S: 241 S: 242 S: +1.7035555555 243 S: +1.7035555556 244 S: jdoe@example.com 245 S: ClientY 246 S: ClientX 247 S: 1999-04-03T22:00:00.0Z 248 S: ClientX 249 S: 1999-12-03T09:00:00.0Z 250 S: 2000-04-08T09:00:00.0Z 251 S: 252 S: 2fooBAR 253 S: 254 S: 255 S: 256 S: 257 S: 258 S: 259 S: 260 S: 261 S: 264 S: someaddress@example.com 265 S: 266 S: 267 S: 268 S: ABC-12345 269 S: 54322-XYZ 270 S: 271 S: 272 S: 274 5.1.3. EPP Command 276 This extension does not add any elements to the EPP query 277 command or response described in the [RFC5730]. 279 5.2. EPP Transform Commands 281 EPP provides five commands to transform objects: to create 282 an instance of an object, to delete an instance of an 283 object, to extend the validity period of an object, 284 to manage object sponsorship changes, and to 285 change information associated with an object. 287 5.2.1. EPP command 289 This extension defines additional elements to extend the EPP 290 command of an object mapping like the EPP contact mapping [RFC5733] 292 The EPP command provides a transform operation that allows a 293 client to create an object. In addition to the EPP command elements 294 described in an object mapping like the EPP contact mapping 295 [RFC5733], the command MAY contain a child element, as 296 defined in Section 3.1. 298 Example command: 300 C: 301 C: 302 C: 303 C: 304 C: 306 C: sh8013 307 C: 308 C: John Doe 309 C: Example Inc. 310 C: 311 C: 123 Example Dr. 312 C: Suite 100 313 C: Dulles 314 C: VA 315 C: 20166-6503 316 C: US 317 C: 318 C: 319 C: +1.7035555555 320 C: +1.7035555556 321 C: [EAI-ADDRESS] 322 C: 323 C: 2fooBAR 324 C: 325 C: 326 C: 327 C: 328 C: 329 C: 330 C: 331 C: 332 C: 335 C: someaddress@example.com 336 C: 337 C: 338 C: ABC-12345 339 C: 340 C: 342 5.2.2. EPP Command 344 This extension does not add any elements to the EPP command 345 or response described in the [RFC5730]. 347 5.2.3. EPP Command 349 This extension does not add any elements to the EPP command 350 or response described in the [RFC5730]. 352 5.2.4. EPP Command 354 This extension does not add any elements to the EPP 355 command or response described in the [RFC5730]. 357 5.2.5. EPP command 359 The EPP command provides a transform operation that allows a 360 client to update an object. In addition to the EPP command elements 361 described in an object mapping like the EPP contact mapping 362 [RFC5733], the command MAY contain a child element, as 363 defined in Section 3.1. When executing the command, there 364 are multiple possibilities of changing the email address: 366 * The EPP object mapping email element is not includes, which means 367 the email address of the contact is not changed. The extension 368 MUST NOT be present. 370 * The EPP object mapping email element is included with the "[EAI- 371 ADDRESS]" value, the extension MUST be present and contain a valid 372 email address. 374 * The EPP object mapping email element is included without the 375 "[EAI-ADDRESS]" value, the extension MUST NOT be present. 377 Example command: 379 C: 380 C: 381 C: 382 C: 383 C: 385 C: sh8013 386 C: 387 C: [EAI-ADDRESS] 388 C: 389 C: 390 C: 391 C: 392 C: 395 C: someaddress@example.net 396 C: 397 C: 398 C: ABC-12345 399 C: 400 C: 402 6. Formal syntax 404 The Internationalized Email Addresses in EPP protocol schema is 405 presented here. 407 The formal syntax shown here is a complete XML Schema representation 408 of the object mapping suitable for automated validation of EPP XML 409 instances. The and tags are not part of 410 the XML Schema; they are used to note the beginning and ending of the 411 XML Schema for URI registration purposes. 413 414 415 421 424 425 426 427 428 Use of Internationalized Email Addresses in 429 Extensible Provisioning Protocol v1.0 Schema. 430 431 433 434 436 437 438 440 441 443 444 446 7. Security Considerations 448 Registries SHOULD validate the domain names in the provided email 449 addresses. This can be done by validating all code points according 450 to IDNA2008 [RFC5892]. 452 8. IANA Considerations 454 8.1. XML Namespace 456 This document uses URNs to describe XML namespaces and XML schemas 457 conforming to a registry mechanism described in RFC 3688 [RFC3688]. 458 The following URI assignment should be made by IANA: 460 Registration request for the eai namespace: 462 URI: urn:ietf:params:xml:ns:epp:eai-0.1 463 Registrant Contact: IESG 464 XML: None. Namespace URIs do not represent an XML specification. 466 Registration request for the eai XML Schema: 468 URI: urn:ietf:params:xml:schema:epp:eai-0.1 469 Registrant Contact: IESG 470 XML: See the "Formal Syntax" section of this document. 472 8.2. EPP Extension Registry 474 The EPP extension described in this document should be registered by 475 IANA in the "Extensions for the Extensible Provisioning Protocol 476 (EPP)" registry described in RFC 7451 [RFC7451]. The details of the 477 registration are as follows: 479 Name of Extension: Use of Internationalized Email Addresses 480 in EPP protocol 481 Document status: Standards Track 482 Reference: TBA 483 Registrant Name and Email Address: IESG, 484 Top-Level Domains(TLDs): Any 485 IPR Disclosure: None 486 Status: Active 487 Notes: None 489 9. Implementation Considerations 491 For the sake of uniform syntax on the client side, it is RECOMMENDED 492 to registries to allow any valid address, including the ASCII-only, 493 in the element. 495 Registries MAY apply extra limitation to the email address syntax 496 (e.g. the addresses can be limited to Left-to-Right scripts). These 497 limitations are out of scope of this document. 499 10. References 501 10.1. Normative References 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 509 DOI 10.17487/RFC3688, January 2004, 510 . 512 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 513 Provisioning Protocol (EPP)", RFC 3735, 514 DOI 10.17487/RFC3735, March 2004, 515 . 517 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 518 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 519 . 521 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 522 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 523 August 2009, . 525 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 526 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 527 February 2012, . 529 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 530 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 531 February 2015, . 533 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 534 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 535 May 2017, . 537 10.2. Informative References 539 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 540 Internationalized Domain Names for Applications (IDNA)", 541 RFC 5892, DOI 10.17487/RFC5892, August 2010, 542 . 544 [RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou, 545 "Extensible Provisioning Protocol (EPP) Organization 546 Mapping", RFC 8543, DOI 10.17487/RFC8543, March 2019, 547 . 549 Appendix A. Change History 551 A.1. Change from 00 to 01 553 1. Changed from update of RFC 5733 to use the "Placeholder Text and 554 a New Email Element" EPP Extension approach. 556 A.2. Change from 01 to 02 558 1. Fixed the XML schema and the XML examples based on validating 559 them. 561 2. Added James Gould as co-author. 563 3. Updated the language to apply to any EPP object mapping and to 564 use the EPP contact mapping as an example. 566 4. Updated the structure of document to be consistent with the other 567 Command-Response Extensions. 569 5. Replaced the use of "eppEAI" in the XML namespace and the XML 570 namespace prefix with "eai". 572 6. Changed to use a pointed XML namespace with "0.1" instead of 573 "1.0". 575 Authors' Addresses 577 Dmitry Belyavskiy 578 8 marta st. 579 Moscow 580 127083 581 Russian Federation 583 Phone: +7 916 262 5593 584 Email: beldmit@gmail.com 586 James Gould 587 VeriSign, Inc. 588 12061 Bluemont Way 589 Reston, VA 20190 590 United States of America 592 Email: jgould@verisign.com 593 URI: http://www.verisigninc.com