| < draft-ietf-regext-epp-eai-07.txt | draft-ietf-regext-epp-eai-08.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: 25 July 2022 VeriSign, Inc. | Expires: 5 October 2022 VeriSign, Inc. | |||
| 21 January 2022 | 3 April 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-07 | draft-ietf-regext-epp-eai-08 | |||
| 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 25 July 2022. | This Internet-Draft will expire on 5 October 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 28 ¶ | skipping to change at page 2, line 28 ¶ | |||
| 2. Migrating to Newer Versions of This Extension . . . . . . . . 3 | 2. Migrating to Newer Versions of This Extension . . . . . . . . 3 | |||
| 3. Email Address Specification . . . . . . . . . . . . . . . . . 4 | 3. Email Address Specification . . . . . . . . . . . . . . . . . 4 | |||
| 4. Functional Extension . . . . . . . . . . . . . . . . . . . . 4 | 4. Functional Extension . . . . . . . . . . . . . . . . . . . . 4 | |||
| 5. Internationalized Email Addresses (EAI) Functional | 5. Internationalized Email Addresses (EAI) Functional | |||
| Extension . . . . . . . . . . . . . . . . . . . . . . . . 5 | Extension . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5.1. Scope of Functional Extension . . . . . . . . . . . . . . 5 | 5.1. Scope of Functional Extension . . . . . . . . . . . . . . 5 | |||
| 5.2. Signaling Client and Server Support . . . . . . . . . . . 5 | 5.2. Signaling Client and Server Support . . . . . . . . . . . 5 | |||
| 5.3. Functional Extension Behavior . . . . . . . . . . . . . . 5 | 5.3. Functional Extension Behavior . . . . . . . . . . . . . . 5 | |||
| 5.3.1. EAI Functional Extension Negotiated . . . . . . . . . 5 | 5.3.1. EAI Functional Extension Negotiated . . . . . . . . . 5 | |||
| 5.3.2. EAI Functional Extension Not Negotiated . . . . . . . 6 | 5.3.2. EAI Functional Extension Not Negotiated . . . . . . . 6 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 7 | 6.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 7 | |||
| 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 8 | 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 7.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 9 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| Appendix A. Change History . . . . . . . . . . . . . . . . . . . 9 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 9 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
| A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 9 | 10.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
| A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 10 | Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10 | |||
| A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 10 | A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 11 | |||
| A.5. Change from 04 to the regext 01 version . . . . . . . . . 10 | A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 11 | |||
| A.6. Change from the regext 01 to regext 02 version . . . . . 10 | A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 11 | |||
| A.7. Change from the regext 02 to regext 03 version . . . . . 10 | A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 11 | |||
| A.8. Change from the regext 03 to regext 04 version . . . . . 10 | A.5. Change from 04 to the regext 01 version . . . . . . . . . 11 | |||
| A.9. Change from the regext 04 to regext 05 version . . . . . 10 | A.6. Change from the regext 01 to regext 02 version . . . . . 11 | |||
| A.10. Change from the regext 05 to regext 06 version . . . . . 11 | A.7. Change from the regext 02 to regext 03 version . . . . . 11 | |||
| A.11. Change from the regext 06 to regext 07 version . . . . . 11 | A.8. Change from the regext 03 to regext 04 version . . . . . 12 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | 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.11. Change from the regext 06 to regext 07 version . . . . . 12 | ||||
| A.12. Change from the regext 07 to regext 08 version . . . . . 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 | |||
| the EPP protocol and specifies the terms when it can be used by EPP | the EPP protocol and specifies the terms when it can be used by EPP | |||
| skipping to change at page 7, line 27 ¶ | skipping to change at page 7, line 27 ¶ | |||
| or registrar-provided proxy email address. | or registrar-provided proxy email address. | |||
| * When the email property is optional in the EPP command 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. If the email | address, the client SHOULD omit the email property. If the email | |||
| property is provided, the client MUST provide an ASCII email | property is provided, the client MUST provide an ASCII email | |||
| address. The provided email address should provide a way to | address. The provided email address should provide a way to | |||
| contact the registrant. It can be a secondary ASCII email address | contact the registrant. It can be a secondary ASCII email address | |||
| or registrar-provided proxy email address. | or registrar-provided proxy email address. | |||
| 6. Security Considerations | 6. IANA Considerations | |||
| Registries SHOULD validate the domain names syntax in the provided | ||||
| email addresses to reduce the risk of future usability errors. It is | ||||
| RECOMMENDED to validate all code points in the domain names according | ||||
| to IDNA2008 [RFC5892]. | ||||
| 7. IANA Considerations | ||||
| 7.1. XML Namespace | 6.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-1.0 | URI: urn:ietf:params:xml:ns:epp:eai-1.0 | |||
| 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-1.0 | URI: urn:ietf:params:xml:schema:epp:eai-1.0 | |||
| 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 | 6.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: | |||
| Name of Extension: Use of Internationalized Email Addresses | Name of Extension: Use of Internationalized Email Addresses | |||
| in EPP protocol | in EPP protocol | |||
| Document status: Standards Track | Document status: Standards Track | |||
| Reference: TBA | Reference: TBA | |||
| Registrant Name and Email Address: IESG, <iesg@ietf.org> | Registrant Name and Email Address: IESG, <iesg@ietf.org> | |||
| Top-Level Domains(TLDs): Any | Top-Level Domains(TLDs): Any | |||
| IPR Disclosure: None | IPR Disclosure: None | |||
| Status: Active | Status: Active | |||
| Notes: None | Notes: None | |||
| 8. References | 7. Implementation Status | |||
| 8.1. Normative References | Note to RFC Editor: Please remove this section and the reference to | |||
| RFC 7942 [RFC7942] before publication. | ||||
| This section records the status of known implementations of the | ||||
| protocol defined by this specification at the time of posting of this | ||||
| Internet-Draft, and is based on a proposal described in RFC 7942 | ||||
| [RFC7942]. The description of implementations in this section is | ||||
| intended to assist the IETF in its decision processes in progressing | ||||
| drafts to RFCs. Please note that the listing of any individual | ||||
| implementation here does not imply endorsement by the IETF. | ||||
| Furthermore, no effort has been spent to verify the information | ||||
| presented here that was supplied by IETF contributors. This is not | ||||
| intended as, and must not be construed to be, a catalog of available | ||||
| implementations or their features. Readers are advised to note that | ||||
| other implementations may exist. | ||||
| According to RFC 7942 [RFC7942], "this will allow reviewers and | ||||
| working groups to assign due consideration to documents that have the | ||||
| benefit of running code, which may serve as evidence of valuable | ||||
| experimentation and feedback that have made the implemented protocols | ||||
| more mature. It is up to the individual working groups to use this | ||||
| information as they see fit". | ||||
| 7.1. Verisign EPP SDK | ||||
| Organization: Verisign Inc. | ||||
| Name: Verisign EPP SDK | ||||
| Description: The Verisign EPP SDK includes both a full client | ||||
| implementation and a full server stub implementation of draft-ietf- | ||||
| regext-epp-eai. | ||||
| Level of maturity: Development | ||||
| Coverage: All aspects of the protocol are implemented. | ||||
| Licensing: GNU Lesser General Public License | ||||
| Contact: jgould@verisign.com | ||||
| URL: https://www.verisign.com/en_US/channel-resources/domain- | ||||
| registry-products/epp-sdks | ||||
| 8. Security Considerations | ||||
| Registries SHOULD validate the domain names syntax in the provided | ||||
| email addresses to reduce the risk of future usability errors. It is | ||||
| RECOMMENDED to validate all code points in the domain names according | ||||
| to IDNA2008 [RFC5892]. | ||||
| 9. Acknowledgments | ||||
| The authors would like to thank Alexander Mayrhofer, Gustavo Lozano, | ||||
| Jody Kolker, John Levine, Klaus Malorny, Marco Schrieck, Mario | ||||
| Loffredo, Patrick Mevzek, Scott Hollenbeck, Taras Heichenko, and | ||||
| Thomas Corte for their careful review and valuable comments. | ||||
| 10. 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>. | |||
| [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
| DOI 10.27487/RFC3688, January 2004, | DOI 10.27487/RFC3688, January 2004, | |||
| <https://www.rfc-editor.org/info/rfc3688>. | <https://www.rfc-editor.org/info/rfc3688>. | |||
| skipping to change at page 9, line 22 ¶ | skipping to change at page 10, line 26 ¶ | |||
| 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>. | |||
| [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible | [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | |||
| Provisioning Protocol", RFC 7451, DOI 10.27487/RFC7451, | Code: The Implementation Status Section", BCP 205, | |||
| February 2015, <https://www.rfc-editor.org/info/rfc7451>. | RFC 7942, DOI 10.17487/RFC7942, July 2016, | |||
| <https://www.rfc-editor.org/info/rfc7942>. | ||||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.27487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.27487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| 8.2. Informative References | 10.2. Informative References | |||
| [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and | [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and | |||
| Internationalized Domain Names for Applications (IDNA)", | Internationalized Domain Names for Applications (IDNA)", | |||
| RFC 5892, DOI 10.27487/RFC5892, August 2010, | RFC 5892, DOI 10.27487/RFC5892, August 2010, | |||
| <https://www.rfc-editor.org/info/rfc5892>. | <https://www.rfc-editor.org/info/rfc5892>. | |||
| [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible | ||||
| Provisioning Protocol", RFC 7451, DOI 10.27487/RFC7451, | ||||
| February 2015, <https://www.rfc-editor.org/info/rfc7451>. | ||||
| [RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou, | [RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou, | |||
| "Extensible Provisioning Protocol (EPP) Organization | "Extensible Provisioning Protocol (EPP) Organization | |||
| Mapping", RFC 8543, DOI 10.27487/RFC8543, March 2019, | Mapping", RFC 8543, DOI 10.27487/RFC8543, March 2019, | |||
| <https://www.rfc-editor.org/info/rfc8543>. | <https://www.rfc-editor.org/info/rfc8543>. | |||
| Appendix A. Change History | Appendix A. Change History | |||
| A.1. Change from 00 to 01 | A.1. Change from 00 to 01 | |||
| 1. Changed from update of RFC 5733 to use the "Placeholder Text and | 1. Changed from update of RFC 5733 to use the "Placeholder Text and | |||
| a New Email Element" EPP Extension approach. | a New Email Element" EPP Extension approach. | |||
| A.2. Change from 01 to 02 | A.2. Change from 01 to 02 | |||
| 1. Fixed the XML schema and the XML examples based on validating | 1. Fixed the XML schema and the XML examples based on validating | |||
| them. | them. | |||
| skipping to change at page 11, line 4 ¶ | skipping to change at page 12, line 14 ¶ | |||
| 1. Changed to use a pointed XML namespace with "0.3" instead of | 1. Changed to use a pointed XML namespace with "0.3" instead of | |||
| "0.2". | "0.2". | |||
| 2. Some wording improvements | 2. Some wording improvements | |||
| A.8. Change from the regext 03 to regext 04 version | A.8. Change from the regext 03 to regext 04 version | |||
| 1. Some nitpicking | 1. Some nitpicking | |||
| A.9. Change from the regext 04 to regext 05 version | A.9. Change from the regext 04 to regext 05 version | |||
| 1. Some nitpicking | 1. Some nitpicking | |||
| 2. The "Implementation considerations" section is removed | 2. The "Implementation considerations" section is removed | |||
| A.10. Change from the regext 05 to regext 06 version | A.10. Change from the regext 05 to regext 06 version | |||
| 1. Some nitpicking | 1. Some nitpicking | |||
| A.11. Change from the regext 06 to regext 07 version | A.11. Change from the regext 06 to regext 07 version | |||
| 1. Namespace version set to 1.0 | 1. Namespace version set to 1.0 | |||
| A.12. Change from the regext 07 to regext 08 version | ||||
| 1. Information about implementations is provided. | ||||
| 2. Acknowledgments section is added. | ||||
| 3. Reference to RFC 7451 is moved to Informative. | ||||
| 4. IPR information is provided | ||||
| 5. Sections are reordered to align with the other regext documents | ||||
| 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 | |||
| 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. | ||||
| 44 lines changed or deleted | 115 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/ | ||||