> -----Original Message----- > From: last-call <[email protected]> On Behalf Of John C Klensin > Sent: Monday, August 22, 2022 10:27 PM > To: Gould, James <[email protected]>; [email protected]; > [email protected]; [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > 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" > <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
