Inline: On Mon, Jun 10, 2024 at 10:21 AM Hollenbeck, Scott <shollenb...@verisign.com> wrote:
> 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. > Based on the revisions and context I have been able to gather, substantial changes have been made since the document was sent to the IESG: https://author-tools.ietf.org/iddiff?url1=draft-ietf-regext-epp-eai-15&url2=draft-ietf-regext-epp-eai-20&difftype=--hwdiff This is the diff since the last version which received an i18ndir review, the last art art review was for -12. I'm not sure if there are any changes that need to be made, but I am also not sure that the current document reflects the working group consensus. > > 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? > I'm not an implementer, but for a standards track document, the focus should be on establishing clear interoperability. It seems like the purpose of this draft is to describe: 1. How to negotiate support for SMTPUTF8. 2. Describe how to support SMTPUTF8 when it's negotiated. 3. Describe how to support multiple email addresses which could be "all-ASCII" or "SMTPUTF8" or a mix. > 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. > I find this part confusing, at least how it's expressed in the draft today. I would expect there to be no requirement to have an "all-ASCII" email in cases where "SMTPUTF8" is supported. I also find it confusing to conflate backup or recovery email addresses with "SMTPUTF8 email addresses". The recent document history contains changes which were made and reverted related to this. 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. > I would expect SMTPUTF8 to be negotiated, and if it was supported to be able to add many email addresses, including ones that were all-ASCII. I would expect that if SMTPUTF8 failed to be negotiated, all email addresses would be all-ASCII. > 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? > I think so, implementations should be able to tell if SMTPUTF8 is supported, and in cases where multiple emails are allowed, which ones are preferred, and how "preferred or primary" email addresses are treated. Managing email address preferences seems like a separate issue from supporting international email addresses. > > 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 > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
