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> 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 > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
