Re: [regext] Internationalized Email Addresses and EPP

[Patrick Mevzek <[e-mail]>]

On Mon, Nov 23, 2020, at 15:55, John Levine wrote:
> In article <[e-mail]> you write:
> >   [SAH] I’m not talking about rejecting a transfer. I’m talking about what a registrar that does not support EAI would/should do if
> >it is the receiving registrar of a domain that includes contacts using internationalized email addresses and those addresses aren’t
> >supported by the registrar. How should this work?
> 
> Reject the transfer -- you get what you pay for.
> 
> Transfers only happen when a registrant asks for them. If registrars
> find that they're losing customers due to inability to handle EAI
> addresses, they can decide that it's an acceptable cost or they can
> upgrade their software, either to handle EAI, or to ask the registrant
> to change her e-mail address to an ASCII one and try again.

A bit harsh/unrealistic: the new registrar may have 0 way to know, before
the transfer succeeds that it has this problem to handle.

Because:
- contact:info commands can be refused by registry on contacts not owned
(so new registrar can not see email addresses of current contacts owned by current
registrar), or the result be filtered
- data may not show at all in whois/RDAP

Hence what will happen:
- the registrar starts the transfer
- it succeeds after some time
- NOW and only NOW can he by surprise discover he has a problem if
he tries to synchronize the contact data from registry to its own systems.
(he won't have problems if he just creates new contacts and update the domain,
as many/some/the majority of registrar do).

That defeats the "do not surprise" law and creates harm for no reason.

Either the registry has to mandate outside of protocol (ex: technical accreditation
test) that every registrar knows how to handle any possible email address, including
EAI case, OR there should be a way for a registrar to dynamically signal the registry
it wants/do not want to handle this case, OR the registry has to provide something
that is forward compatible (hence: 1) not breaking current software but 2) allows
updated software to enjoy more features)

-- 
  Patrick Mevzek
  [e-mail]