On Mon, Nov 23, 2020, at 15:55, John Levine wrote: > In article <f57ec7e59aed47ce96f747f10c746...@verisign.com> 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 p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
