Andy, Yes, that is correct.
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/27/23, 1:58 PM, "Andrew Newton" <a...@hxr.us <mailto:a...@hxr.us>> wrote: 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. In other words, if the SMTPUTF8 email fails there are other types of communication (postal mail, phone) available. In practical terms, an all-ASCII email can fail as well, so this should not change business practices. This sounds good to me, James. -andy On Thu, Jul 27, 2023 at 9:48 AM Gould, James <jgould=40verisign....@dmarc.ietf.org <mailto:40verisign....@dmarc.ietf.org>> wrote: > > Based on the discussion that occurred at the IETF-117 REGEXT meeting, I took > the action item to cover the topic of the alternate ASCII e-mail. To address > this, I defined a new “Alternate Communication Considerations” section with > the following content for consideration: > > > > RFC 6530 [RFC6530] specifies "message-originating systems SHOULD be prepared > to either send conventional envelopes and message headers or to return the > message to the originating user so the message may be manually downgraded to > the traditional form" along with "Of course, such transformations imply that > the originating user or system must have ASCII-only addresses available for > all senders and recipients. Mechanisms by which such addresses may be found > or identified are outside the scope of these specifications as are decisions > about the design of originating systems". This implies that adding support > for SMTPUTF8 in EPP includes the need for an alternate form of communication > in event of SMTPUTF8 communication errors. Having alternate forms of > communication is the responsibility of server policy on a per EPP extension > basis. The two known EPP extension RFCs that have email addresses, that > include RFC 5733 [RFC5733] and RFC 8543[RFC8543], support alternate forms of > communication in the form of postal address, voice telephone number, and > facsimile telephone number. Use of an alternate ASCII email address can be > used by an EPP extension. Servers that do support this extension SHOULD > ensure that there are available alternate communication methods for supported > EPP extensions with email addresses. > > > > Please review and provide your feedback. If this section addresses the action > item, -19 will be posted with it. > > > > Thanks, > > > > -- > > > > JG > > > > > James Gould > Fellow Engineer > jgo...@verisign.com <mailto:jgo...@verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > > _______________________________________________ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> > https://secure-web.cisco.com/17k43P_vTaXwOm0fyYEeJE4oVdYuUnstkdfTRHX7AR7mAypGNOMfwTS-2IQ0KyHmvz9gn-wgBvNkslioPhuh1AiyUn3ml22cnRIhOaC2yau8Rn0lcVjLITOPbAsedfBIe7fHQvA4ejutQgFVnzKuXOnTDyFXZA0IHW49iFickqMaofup9Dz1tEpBd0BP9REz0qMf2792wqonI08GuRZDfZfzfBmDe7mfingZAoHKR_dl9m7Tjw8Uq355gWGlcBdEVBn_6YmAk4ZgMVzoHeEbv_CpZ90EzQAW3iC2rkjX0vjM/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > <https://secure-web.cisco.com/17k43P_vTaXwOm0fyYEeJE4oVdYuUnstkdfTRHX7AR7mAypGNOMfwTS-2IQ0KyHmvz9gn-wgBvNkslioPhuh1AiyUn3ml22cnRIhOaC2yau8Rn0lcVjLITOPbAsedfBIe7fHQvA4ejutQgFVnzKuXOnTDyFXZA0IHW49iFickqMaofup9Dz1tEpBd0BP9REz0qMf2792wqonI08GuRZDfZfzfBmDe7mfingZAoHKR_dl9m7Tjw8Uq355gWGlcBdEVBn_6YmAk4ZgMVzoHeEbv_CpZ90EzQAW3iC2rkjX0vjM/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
