From: Orie Steele <orie@transmute.industries> Sent: Monday, June 10, 2024 4:44 PM To: Hollenbeck, Scott <shollenb...@verisign.com> Cc: regext@ietf.org; regext-cha...@ietf.org Subject: [EXTERNAL] Re: [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. Inline: On Mon, Jun 10, 2024 at 10:21 AM Hollenbeck, Scott <shollenb...@verisign.com <mailto: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 <https://secure-web.cisco.com/17UAZDmI6G030TbCbNxJJOaujFZjftY_Jr2okatVVksh-jIDlmlDET-b3X4Hkb1ES63dmQnPIn0RKbtXj_RfZNDobxRfezeHjgV1u5-l1BqSMh3CXNz3xQgIG46KCOV42iU10lNPsZTbjBAoUBsWYj74mWh_TGhGe5TYTJoc3mtTXmoz1QgyrRuhIPO_bAjFUH8MXmOatPoPyg36ecUi8PvkN-hOOE332c_e2OLlZ7YtPu-VaEu6p-YsxrHcng2bQEct0Lhop7uUj4ENbuvfBO6zmO_H7T6V7AcoPdV9quMM/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-regext-epp-eai-15%26url2%3Ddraft-ietf-regext-epp-eai-20%26difftype%3D--hwdiff> &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. [SAH] I’m pretty sure the remaining issue(s) are less about working group consensus and more about feedback received from reviewers. I think it would be helpful for *someone* would provide a definitive summary of the blocking issue(s). >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. [SAH] EPP handles 1 and 2 above. I agree with 3. 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. [SAH] Confusion can be addressed with text once we understand what’s holding the draft up. At some point, it was suggested that an all-ASCII address must be available if an SMTPUTF8 address were also provisioned. I don’t know if that is still the case, but it’s another one of those things for which clarification is required. 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 <mailto:regext@ietf.org> Cc: REGEXT Chairs <regext-cha...@ietf.org <mailto: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://secure-web.cisco.com/1gcOynwJagiMwVL1VTrNg1kv8TN8U3R4hKtTm_dbM-KNNbvQDLWCyAFd30zbYJIzSlOe-XdCOm1rVBpo4JuiSFxViKRRnXfza63APzw5JUWjmQ5HpVsFrFatxM7TsK0XTyJ0dNPzpLMVw5gZIF8B1fF_zE_PzUg9cmzGbpwEPrQMBevrkDiCv_e3IMnElbiBwOS9GBgIUZO_OWyhlfyURRs9ssoNnchIU6ZbK1RUDZOUbr3VSeVLWatQKoCbetXUgEcZxeOWwgpclkt-c5_dsnJItLmmk9yMrkvfxMagn9IE/https%3A%2F%2Ftransmute.industries>
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
