Arnt wrote: Much later, if someone sends you mail, they may or may not be able to accept your reply. Replying to email is however outside the scope of EPP. There's an interop problem, but no single RFC and no single actor is unambiguously at fault. And in consequence, no requirement in this extension can solve this satisfactorily.
James Wrote: I still prefer the simplicity of the -10 approach. This is the key interoperability issue that I am still struggling to understand. I tend to also prefer the simplicity of -10, and as Arnt wrote, perhaps the interoperability challenge is not solvable in this draft. I am still struggling to understand what is interoperable with respect to SMTPUTF8 email addresses in the context of this draft. I appreciate your patience in explaining this to me. Regards, OS On Wed, Jun 12, 2024 at 7:41 AM Gould, James <jgo...@verisign.com> wrote: > Orie, > > > > The draft has implemented multiple approaches to address the feedback from > John Klensin, related to the desire to have an all-ASCII email address. I > include the approaches below for summary. I believe the protocol should > support either an ASCII email address or an SMTPUTF9 email address, which > was the original purpose of creating draft-ietf-regext-epp-eai. RFC 5733 > and RFC 8543 supports SMTPUTF8 email addresses on the wire, but not based > on the reference to RFC 5322 in the specification. What is supported can > be left to server policy and not restricted by the protocol itself. The > latest version -20 provides the base set of features that a server can use > to implement their policy (one ASCII, two ASCII, one ASCII or SMTPUTF8, one > or two ASCII or SMTPUTF8). > > > > 1. -10 (IETF LC) > 1. Supported one ASCII or SMTPUTF8 email address > 2. -17 > 1. Supported one or two ASCII or SMTPUTF8 email addresses with a > transition period > 3. -19 > 1. Supported one or two ASCII or SMTPUTF8 email addresses without a > transition period > > > > Scott has proposed another approach with one ASCII email address with an > optional ASCII or SMPTUTF8 alternate email address, and a primary email > address marker. > > > > I still prefer the simplicity of the -10 approach, but if there is the > need for an alternative email address to address the feedback, then my > recommendation is -19 (-20 is the same approach). > > > > Thanks, > > > > -- > > > > JG > > > [image: cid87442*image001.png@01D960C5.C631DA40] > > > *James Gould *Fellow Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Orie Steele <orie@transmute.industries> > *Date: *Tuesday, June 11, 2024 at 3:46 PM > *To: *"Hollenbeck, Scott" <shollenb...@verisign.com> > *Cc: *"regext@ietf.org" <regext@ietf.org>, "regext-cha...@ietf.org" < > regext-cha...@ietf.org> > *Subject: *[EXTERNAL] [regext] Re: 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. > > Thanks for your comments. > > I think you have identified the key issue: > > Is an "all-ASCII" email address always a requirement even when SMTPUTF8 is > supported, is there a "transition period"? > > See: > https://author-tools.ietf.org/iddiff?url1=draft-ietf-regext-epp-eai-17&url2=draft-ietf-regext-epp-eai-20&difftype=--hwdiff > <https://secure-web.cisco.com/1bhG0QhJCV9zllCZd7nwR4ZuXdlLmwntWraMLSMtJiQpYK163qP6WvECuGBw0PDEWogXLWLAZYCL1mTKlwDAo9313rti8Ok5SihU4dLNWmJlRXyDip6UN6CT2SpN8QafPDiVNTCRdJwzI-OffJbDqScooOpbnQo1oCtnuca4AexESOEPp0GSTsrlaHTmQlnoF5nUTe4V7c49rEDk0w1gAAYITqTy-Ej_PJq7DMU_HNHJpSB3V-zRX6XUXdZcfQPEnk-zSXZUrb516ZTopLnDMFKNCnkAubt2z2ZEAPw8m0KU/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-regext-epp-eai-17%26url2%3Ddraft-ietf-regext-epp-eai-20%26difftype%3D--hwdiff> > > Current reading is that an alternate email address is the only email > address which can be an SMTPUTF8. > > There is no transition period, see the normative language which was added > and removed during reviews under the section: > > "SMTPUTF8 Transition Considerations" > > It sounds to me like there is no requirement to have any "all-ASCII" email > addresses. > > In the update in Figure 8, an example to unset the alternate email address > is provided. > > If only SMTPUTF8 is supported, is there an email address that is > "all-ASCII" associated after this point? > > If it helps I can do a full early AD review of the document. > > Regards, > > OS > > > > On Tue, Jun 11, 2024 at 10:43 AM Hollenbeck, Scott < > shollenb...@verisign.com> wrote: > > *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> 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 > <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> > > 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 > *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 > > [image: Image removed by sender.] > <https://secure-web.cisco.com/1gcOynwJagiMwVL1VTrNg1kv8TN8U3R4hKtTm_dbM-KNNbvQDLWCyAFd30zbYJIzSlOe-XdCOm1rVBpo4JuiSFxViKRRnXfza63APzw5JUWjmQ5HpVsFrFatxM7TsK0XTyJ0dNPzpLMVw5gZIF8B1fF_zE_PzUg9cmzGbpwEPrQMBevrkDiCv_e3IMnElbiBwOS9GBgIUZO_OWyhlfyURRs9ssoNnchIU6ZbK1RUDZOUbr3VSeVLWatQKoCbetXUgEcZxeOWwgpclkt-c5_dsnJItLmmk9yMrkvfxMagn9IE/https%3A%2F%2Ftransmute.industries> > > > > > -- > > > > > *ORIE STEELE *Chief Technology Officer > www.transmute.industries > > [image: Image removed by sender.] > <https://secure-web.cisco.com/1K-_LWoGtR8AHqfkUr2LBwVRzWrtPtk5i7_s-XNNSZYIVPubYDuuuDlK6Mrx9lpsPyK0EWoQa1ct2kq173sh4Y_5onxcXMwgqn80L_wRuyhzSatrg8NKTcmVjDVKqJGu4aE_sr1xC_hdBsKJcx6ZcEpUWaNhPTm1YIcCL8zEZmaiJQbEdvsi5vYYpkalWV8oUNbGNAfdaPQeWfszZINliBiuPORf9_j7i2tOT4VAOiChgMbkzNISZkgK8xTbBsy7XRO5MZuhlD3_KTPkEri5V-8ptoFALwcH_Q7GsrCRrLS4/https%3A%2F%2Ftransmute.industries> > -- 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
