I see the value in supporting multiple email addresses from a protocol perspective. If, however, the purpose of this draft is narrowly scoped such that the goal is to support either a single SMTPUTF8 or ASCII address, I can support option #1. That probably means that we need to think about future work to support multiple email addresses.
Scott From: regext <[email protected]> On Behalf Of Gould, James Sent: Thursday, March 2, 2023 7:50 AM To: [email protected] Subject: [EXTERNAL] [regext] draft-ietf-regext-epp-eai Path Forward 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. 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: 1. 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). 2. 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: a. Alternative Email can be ASCII or SMTPUTF8 b. 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 <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 <http://secure-web.cisco.com/1uHOgbOPNDGUvD3ZorOMn6hZeuW9LN6cRlBG6qycMBQPoXUAjgJFhgZ_kwB10KrOWWnDSs98HPIsB4mgBxgGqi32ye1r_4yV3mvW4d-tfYhBlUxtVH5voOdRMwl13gzQd_bNXxSUxKSOdM8_5laalmcURpkEwFjdHIxMnLHOnP7giDutEa5s2Lz3rkQQbOJqThfm8tvN6yRcKiG1BI7yCEVVL9ZCGQhlNQ8JpIGlPg7t-veMiYAtl2f5Hhw8cuw_b48aeVRzJIs3cxsKOEmupY756kHqbEd-jPAz-PTRgBz4/http%3A%2F%2Fverisigninc.com%2F> Verisign.com
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
