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<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#RFC6530>
 
[RFC6530<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#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<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#RFC5733>
 
[RFC5733<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#RFC5733>]
 and RFC 
8543<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#RFC8543>[RFC8543<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#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

[cid87442*[email protected]]

James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext

Reply via email to