Re: [regext] Internationalized Email Addresses and EPP

[Alexander Mayrhofer <[e-mail]>]

Jumping into this discussion quite late, but...

On Thu, Nov 19, 2020 at 4:39 PM Gould, James
<jgould=[e-mail]> wrote:

> The 3 options presented and discussed at the REGEXT meeting included three extension options, which all include an namespace URI in the greeting and logic services:

I'd really like to understand why there's not option (4), which, as i
mentioned, would be:

- Accept EAI addresses like any other email address in the standard
EPP field (if the registry supports this). I don't see why the current
RFC 5730 ff schema would not support this.
- If a registry doesn't want to accept EAI addresses, return a 2306.
This is inline with many other elements of registry policies - eg.
when a registry validates the pc element of contacts against local
policy, it would also 2306 - and nobody has yet discussed an extension
for the purpose of announcing that the registry only supports a
certain set of pc values (nooooo, no i've planted ideas in all of our
brains!)
- I don't see an issue with RDAP. RDAP can perfectly display non-ASCII
characters
- Creating an extension like this will never make EAI's "first class
citizens". Accepting EAIs in standard "<email>" elements will.

Maybe I'm failing to see the point.  And, as Klaus said, we're making
EPP based registries a super complicated beast, implemented by a very
small community. Introducing "yet another switch" into the protocol
won't make it easier.

For example, what would an "old" client do that doesn't understand a
potential EAI extension? Would they be deprived of email addresses
completely, and receive non-sensical placeholders which they'd
unwittingly hand over to their email system (even if that email system
would perfectly understand EAIs?). Does sound like a failed
opportunity to me!

best,
Alex