Pawel, I agree that the protocol should not venture into policy decisions. The draft could add an alternate email that can be either an ASCII or an SMTPUTP8 along with allowing the existing email to be an ASCII or an SMTUPUTF8. With this, the protocol can support the desired server policy with the ability to have an alternate email attribute. This is pretty much what was in -17 without a transition period or the requirement to have an ASCII email, which is a policy decision and not a protocol decision.
Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/4/23, 1:29 PM, "regext on behalf of Pawel Kowalik" <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of kowa...@denic.de <mailto:kowa...@denic.de>> wrote: Hi, Reading the feedback from John Klensin again, the main problem seems to be that only 1 address does not leave any room for policy choices by all actors in the chain (mainly registries and registrars) whether to support a "backup" all-ASCII address or not. This is a fair point. Now, if we are at the point of adding a "backup" email address - what is the difference between all-ASCII backup and just any backup? SMTPUTF8 address may be vulnerable to some compatibility issues due to transition period, so can be just any other kind of mailbox due to other kind of incompatibilities or issues. On the practical side, the party trying to use the address with a backup, may also define the handling as they see fit - either re-send the message if SMTP transaction fails, or when non-delivery message comes back, or use both addresses directly upfront. Again here - no difference whether the cause of the failure is non-ASCII address or any other issue. In this context I would argument for support of more than one email address on the protocol level, with no restriction and cross-relation if it is all-ASCII or non-ASCII and let the policies then define how to use it in a particular context. The mention of transition period would not be needed in this case. Kind Regards, Pawel Am 03.08.23 um 20:14 schrieb Andrew Newton: > On Thu, Aug 3, 2023 at 1:23 PM Gould, James <jgo...@verisign.com > <mailto:jgo...@verisign.com>> wrote: >> So, rollback to draft-ietf-regext-epp-eai-17 with the concept of a >> transition period removed and inclusion of "at least one of the email values >> MUST be an ASCII address"? > Doesn't that put us back to requiring two email addresses to support EAI? > > I was thinking that "if more than one email value is provided, one > MUST be an ASCII address". Therefore the options are: > 1) provide an ASCII email address. > 2) provide an SMTPUTF8 email address. > 3) provide both > > The draft will still need text such as provided by Arnt to justify option 2. > > And I agree with removing the transition period. > > -andy > > _______________________________________________ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> > https://secure-web.cisco.com/17JZXiFsknqdyW6ZV4mbuuls_QcV0VIZT4b3IcpLP-1XUaF0UFBm8gPSqC1YCgPRGdznIpTgj-0mXH0_Cx3S1a3OSQMVYKvTR33vK2Mzr7LyoifaRwGIIm70EXYEoxhjYZBwaDDLQKd_kROVRP-e0xI6Q7UkVbhgl6AJ9NL_2ZGNo_KQXcUHZbGCZ2bL6x2mgNwaynGyH3a4LZNCjGelaLjnCNuYBRaHClVKpQjjXnOClFY1jbcJMPd0c5gu3LgT8xBq5LIXaa8bk6tatG3Dw-c_UeNO71K3TH-vFiDZLCTQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > <https://secure-web.cisco.com/17JZXiFsknqdyW6ZV4mbuuls_QcV0VIZT4b3IcpLP-1XUaF0UFBm8gPSqC1YCgPRGdznIpTgj-0mXH0_Cx3S1a3OSQMVYKvTR33vK2Mzr7LyoifaRwGIIm70EXYEoxhjYZBwaDDLQKd_kROVRP-e0xI6Q7UkVbhgl6AJ9NL_2ZGNo_KQXcUHZbGCZ2bL6x2mgNwaynGyH3a4LZNCjGelaLjnCNuYBRaHClVKpQjjXnOClFY1jbcJMPd0c5gu3LgT8xBq5LIXaa8bk6tatG3Dw-c_UeNO71K3TH-vFiDZLCTQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
