+1, I support cardinality of one.
From: regext <regext-boun...@ietf.org> on behalf of Jody Kolker <jkolker=40godaddy....@dmarc.ietf.org> Date: Thursday, March 2, 2023 at 7:19 AM To: Rick Wilhelm <rwilh...@pir.org>, Roger D Carney <rcarney=40godaddy....@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org> Subject: [Ext] Re: [regext] draft-ietf-regext-epp-eai Path Forward I also support cardinality of one. Thanks, Jody. From: regext <regext-boun...@ietf.org> On Behalf Of Rick Wilhelm Sent: Thursday, March 2, 2023 8:26 AM To: Roger D Carney <rcarney=40godaddy....@dmarc.ietf.org>; regext@ietf.org Subject: Re: [regext] draft-ietf-regext-epp-eai Path Forward Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. Agreed… +1 on cardinality of one Thx Rick From: regext <regext-boun...@ietf.org> on behalf of Roger D Carney <rcarney=40godaddy....@dmarc.ietf.org> Date: Thursday, March 2, 2023 at 8:10 AM To: regext@ietf.org <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-epp-eai Path Forward CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting. +1 on cardinality of one From: regext <regext-boun...@ietf.org> on behalf of Dmitry Belyavsky <beld...@gmail.com> Sent: Thursday, March 2, 2023 7:03 AM To: Gould, James <jgould=40verisign....@dmarc.ietf.org> Cc: regext@ietf.org <regext@ietf.org> Subject: Re: [regext] draft-ietf-regext-epp-eai Path Forward Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. Dear colleagues, I also support the cardinality of one. On Thu, Mar 2, 2023 at 1:50 PM 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 [nam10.safelinks.protection.outlook.com] _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext [nam10.safelinks.protection.outlook.com] -- SY, Dmitry Belyavsky
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
