I agree with James and here is why... First, at least in my operational experience, modifying a data model is much more complex than just software upgrades.
Second, these email addresses are not only used for display in RDAP/Whois, sometimes they are used for operational purposes (e.g., as in domain transfers). Adding a second email address to the same contact will complicate these scenarios. Third, IMHO most registrants when faced with needing to provide an all-ASCII address when desiring to use a non-ASCII address are going to do the least effort thing and provide only the all-ASCII address (and I don’t blame them, I would too). Fourth, as I understand the arguments of the unconstrained Unicode in the local-part of an SMTPUTF8 compatible address, policy would be needed regardless of the presence of the fallback, all-ASCII address. That is, the issues here don’t go away just because an alternative is provided. Therefore, I believe we should go back to one email address, stay in the technical realm and mitigate going into topics that the policy realm appears to be a more appropriate place to define. To be more specific, in the Security Considerations we should note that unconstrained Unicode in local-parts can sometimes yield addresses that are useless or malicious and that, as a MUST, usage of the EAI mechanism should be done with policy that mitigates these issues. We can even point to a potential policy solution of scoping local-parts to Unicode Annex 31, as was mentioned during the IETF LC on this draft. -andy On Thu, Mar 2, 2023 at 7:50 AM Gould, James <jgould=40verisign....@dmarc.ietf.org> wrote: > > I’ve discussed the path forward for draft-ietf-regext-epp-eai with some > working group participates and I have concern of the current path that the > draft is taking with the support for an alternate e-mail address, whether it > be either ASCII, SMTPUTF8, or either. There are system and policy impacts > associated with the requirement to collect and transmit an additional e-mail > address across EPP RFCs (e.g., RFC 5733, RFC 7848, RFC 8543), where the end > goal of draft-ietf-regext-epp-eai was to support the use of SMTPUTF8 e-mail > values with the appropriate signaling by the server and client. I realize > that the term “cardinality” was not popular with some, but the inclusion of > an alternative e-mail across all EPP extensions that include an e-mail > address does make a crosscutting cardinality change from one to two. The > registry needs to support either ASCII or SMTPUTF8 addresses to enable the > registrars, which have the relationship with the registrant, to make the > decision what form of e-mail to accept. In hindsight, I believe the “Change > of Cardinality to One or Two (ASCII or SMTPUTF8)” recommendation from the > IETF-115 REGEXT meeting that was incorporated into > draft-ietf-regext-epp-eai-17 is the wrong option. We should keep the > cardinality of one to provide the needed support for SMTPUTF8 in the registry > for the registrars to make the decision what to collect and pass to the > registry. I provide the options below for consideration by the working group: > > Cardinality of One – The approach taken in draft-ietf-regext-epp-eai-16, > where the server (registry) supports either SMTPUTF8 or ASCII addresses for a > decision by the client (registrar). > Cardinality of Two – The approach taken in draft-ietf-regext-epp-eai-17, > where the server (registry) supports an alternative email element during a > transition period that requires one email element to be ASCII. There are two > sub-options based on the recent discussion: > > Alternative Email can be ASCII or SMTPUTF8 > Alternative Email is only ASCII > > My preference is Cardinality of One that would roll back to > draft-ietf-regext-epp-eai-16. Please respond to the mailing list with your > preference or any other options that should be considered. > > Thanks, > > > > -- > > > > JG > > > > > James Gould > Fellow Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
