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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/regext
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
