John, The signal would be handled via support for an EPP extension XML namespace in option 2, an operational practice XML namespace in what I would call 2b, or most likely a new contact XML namespace (contact-1.1) in option 1 for RFC 5733. The XML namespace would be reflected in the EPP greeting services and login services.
-- 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 10/19/20, 2:28 PM, "John Levine" <jo...@taugh.com> wrote: In article <5f5d3bae-b38c-4663-800b-3f5918990...@verisign.com> you write: > >The registry can support the receipt of UTF-8 addresses based on the EPP RFCs, but full support comes down to the validation of the >email addresses, how the email addresses are stored, and what the email addresses are used for. I would expect an EPP error (2004 >"Parameter value range error" or 2306 "Parameter value policy error") if an internationalized email address is received when the >registry does not support it. That makes sense, but it also seems needlessly cruel. I expect registrars would build ad-hoc lists of who handles EAI and who doesn't, to provide better reports to their users, which would then inevitably get out of date. If we do this it really would be nice if there were a signal for who handles EAI and who doesn't. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
