The requirement of draft-ietf-regext-epp-eai is to add support for
SMTPUTF8 email addresses in EPP. Changing the cardinality (one to two or one to many) for e-mail addresses in EPP extensions, such as RFC 5733 and RFC 8543, is a different requirement that can be addressed with a different EPP extension, and the decision
of whether to require an all-ASCII e-mail address would be up to server policy and not the protocol itself.
From:
Dmitry Belyavsky <beldmit@xxxxxxxxx>
Date: Tuesday, August 23, 2022 at 2:43 AM
To: John C Klensin <john-ietf@xxxxxxx>
Cc: James Gould <jgould@xxxxxxxxxxxx>, Patrik Fältström <paf@xxxxxxxxxx>, "Gould, James" <jgould=40verisign.com@xxxxxxxxxxxxxx>, "art@xxxxxxxx" <art@xxxxxxxx>, "draft-ietf-regext-epp-eai.all@xxxxxxxx" <draft-ietf-regext-epp-eai.all@xxxxxxxx>, "last-call@xxxxxxxx"
<last-call@xxxxxxxx>, regext <regext@xxxxxxxx>, "i18ndir@xxxxxxxx" <i18ndir@xxxxxxxx>, "gen-art@xxxxxxxx" <gen-art@xxxxxxxx>
Subject: [EXTERNAL] Re: Re: Re: [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)
Dear John
--On Monday, August 22, 2022 16:01 +0000 "Gould, James"
<jgould@xxxxxxxxxxxx> wrote:
> John,
>
> How about if we change the approach to use the well-understood
> command-response extension?
If things were changed to create an extension type that is
defined in RFC 5730 rather than creating a new type, that would
certainly eliminate the need to update 5730 (or explain clearly
why that was not necessary).
That, of course, leaves the more substantive SMTPUTF8 issues,
particularly the need for a slot for an alternate all-ASCII
address.
No. SMTPUTF8 email address _is_ email address. Otherwise we are stuck with email addresses of first-class and of second-class forever.
We don't need separate slot for all-ASCII addresses.
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
