> -----Original Message----- > From: last-call <last-call-boun...@ietf.org> On Behalf Of John C Klensin > Sent: Monday, August 22, 2022 10:27 PM > To: Gould, James <jgo...@verisign.com>; beld...@gmail.com; > p...@paftech.se; jgould=40verisign....@dmarc.ietf.org > Cc: a...@ietf.org; draft-ietf-regext-epp-eai....@ietf.org; last-c...@ietf.org; > reg...@ietf.org; i18n...@ietf.org; gen-art@ietf.org > 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" > <jgo...@verisign.com> 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 _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
