Orie, would you or someone else please provide a description of the needed changes that you described below? The IESG evaluation record isn’t visible in the Datatracker, so that doesn’t help.
From what I recall, the goal of this draft is to define an EPP extension that adds support for SMTPUTF8 email addresses. The RFC5733 XML schema already supports UTF8, but we have an issue because this text exists in 5733: “Email address syntax is defined in [RFC5322].” 5322 isn’t being updated to include support for SMTPUTF8 email addresses, so 5733 is stuck with the current ASCII-only syntax specification. The current draft is very focused on EAI and i18n. If that’s where the issues are, would it help if the draft were less about EAI and more about adding support for a second email address that could be either an all-ASCII address or an SMTPUTF8 address? This would ensure that there’s always an all-ASCII address specified in the associated contact object if an SMTPUTF8 address appears in the extension. It could also be used to capture a second all-ASCII address might be useful in account recovery, for example, if the primary address becomes unreachable. The extension schema could be as simple as something like this: <CODE BEGINS> <?xml version="1.0" encoding="UTF-8"?> <schema xmlns=http://www.w3.org/2001/XMLSchema xmlns:altEmail="urn:ietf:params:xml:ns:epp:altEmail-1.0" targetNamespace="urn:ietf:params:xml:ns:epp:altEmail-1.0" elementFormDefault="qualified"> <annotation> <documentation>Extensible Provisioning Protocol v1.0 alternative email address schema.</documentation> </annotation> <!-- Create, Update, and Info Response extension element --> <element name="altEmail" type="altEmail:altEmailType" /> <!-- Single email element that can be empty --> <complexType name="altEmailType"> <attribute name="primary" type="boolean" default="false"/> <sequence> <element name="email" type="token"/> </sequence> </complexType> <!-- End of schema. --> </schema> <CODE ENDS> The “altEmail” element can be used to provision a second email address that can be either all-ASCII or SMPUTF8. The “primary” attribute could be used to identify the extension address as the primary address for contact purposes. This could be used to mark an SMTPUTF8 address as primary. Is this worth exploring? Scott From: Orie Steele <orie@transmute.industries> Sent: Monday, June 3, 2024 11:49 AM To: regext@ietf.org Cc: REGEXT Chairs <regext-cha...@ietf.org> Subject: [EXTERNAL] [regext] draft-ietf-regext-epp-eai update Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/<https://secure-web.cisco.com/1L9IEHAcZBCB67r1r37qJqg1NnDjdFRCh-fzxdrEFG65g1fXXEkgzxVC4SusImF2bLUGTs7-bcCafkZz2WsjI0otx3bzFifhjwa1opylcM-sn_SVtjIGq1zwr-4Z4eTc9teZg5LcHB9tG6ky-hyTJjE-O2g8wDft8ZkJ62bEjFFoiCeisZOdUvxKYVRj_S8_zT6ppqo5mir0vaNJ_NfGGvxVnkYZbcjNtHL-AG26ISrVgobAci0TkJnDXFe09oSvkMVBW8jUzizoQJqXZGFGpOYZ8igOx8PCqS4nw2gEV7uwremToG5th5THsrX4To0VA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-eai%2F> I am moving the document back to the working group. Thanks to all who provided feedback and reviews on this draft, and for your patience and support for our process. This document has been stuck in AD Followup, but the changes discussed are substantial enough that I believe the working group needs to address them, and then WG consensus needs to be re-established. I suggest requesting an early review from ART ART, with a focus on i18n. I'd like to see that review addressed before the document shepherd writeup is revised, and the document is submitted for AD Evaluation. Chairs, please add a milestone to submit a revised "Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)", to the IESG before 2025. I'll work with you all to ensure that the document, and the associated i18n issues are addressed in a timely manner. Regards, OS, ART AD
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
