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)
* Supported one ASCII or SMTPUTF8 email address
2. -17
* Supported one or two ASCII or SMTPUTF8 email addresses with a
transition period
3. -19
* 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
[cid87442*[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: Orie Steele <[email protected]>
Date: Tuesday, June 11, 2024 at 3:46 PM
To: "Hollenbeck, Scott" <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
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
<[email protected]<mailto:[email protected]>> wrote:
From: Orie Steele <[email protected]>
Sent: Monday, June 10, 2024 4:44 PM
To: Hollenbeck, Scott
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>> 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 <[email protected]>
Sent: Monday, June 3, 2024 11:49 AM
To: [email protected]<mailto:[email protected]>
Cc: REGEXT Chairs <[email protected]<mailto:[email protected]>>
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 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 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>
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
