> -----Original Message----- > From: last-call <last-call-bounces@xxxxxxxx> On Behalf Of John C Klensin > Sent: Monday, August 22, 2022 10:27 PM > To: Gould, James <jgould@xxxxxxxxxxxx>; beldmit@xxxxxxxxx; > paf@xxxxxxxxxx; jgould=40verisign.com@xxxxxxxxxxxxxx > Cc: art@xxxxxxxx; draft-ietf-regext-epp-eai.all@xxxxxxxx; last-call@xxxxxxxx; > regext@xxxxxxxx; i18ndir@xxxxxxxx; gen-art@xxxxxxxx > Subject: [EXTERNAL] Re: [Last-Call] last call reviews of draft-ietf-regext-epp- > eai-12 (and -15) > > 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. > > > --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. [SAH] A thought: the traditional command-response extension would preserve the ability to provision an all-ASCII address using the data structures defined in RFC 5733. A contact <create> command (for example) could be extended to add support for provisioning an additional SMTPUTF8 address. Would that approach address your concern, John? Scott -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
