Re: [regext] Internationalized Email Addresses and EPP

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Alexander Mayrhofer <[e-mail]>
> Sent: Monday, November 23, 2020 1:04 AM
> To: Gould, James <[e-mail]>
> Cc: [e-mail]; Hollenbeck, Scott
> <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
>
> 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.
>
> 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.

This may be the path of least resistance. I'm still trying to think through hat would happen if a registry returns an internationalized email address to a registrar that doesn't expect one. This could happen after a domain transfer, for example. Is this a problem? If not, maybe we could just get by without any other protocol changes or extensions.

> 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!

See question above.

Scott