Re: [regext] Internationalized Email Addresses and EPP

[Patrick Mevzek <[e-mail]>]

On Tue, Nov 24, 2020, at 12:35, Taras Heichenko wrote:
> First of all, registry does not force anything. It gives the 
> possibility that registrars
> can use. 

... which then forces all other registrars to have to support that possibility,
except if the registry offers a way for registrars not wanting it to be able
to opt-out from it.
A registry is a shared data storage, in one simplified view. If registrar X
has the "possibility" to enter data there that registrar Y has no way to handle,
this means pretty much everyone is forced to upgrade in order to handle the new data.
Or just stop using that shared datastore.

Again, I think the purpose is to find a solution that could work
for any registry (so trying not to just create things for the benefit
of a sole actor, even if that happens too often to my taste), and any registrar,
including those that do not want to support that new feature, even if you personally
believe that all registrars should support it.

We can talk endlessly about a specific registry and a specific problem.
But I guess that if ones wants to have something akin to an RFC at least some
work is needed to include other actors in the play even if finally the specification
won't be used by more than one actor. Otherwise it can just be published as an I-D
or Informational RFC I guess, for just notification, and there is a little for the
working group to discuss (if the initial specification is not open to changes).

> But if there are users that want to use non-ASCII email then 
> registrars
> and registries should give the ability to use such addresses to the 
> users. (At least
> if we say about universal acceptance). So whether EAI would be 
> implemented by
> extension or in the main <email> field it will bring all registrars to 
> the EAI implementation.

That "either" might need only a couple of electrons in an email, but both options need
a non trivial amount of work: either designing a proper extension (without plays
on placeholders or things like that), or just doing "EPP v2" if you want to change
the "email" definition, and then good luck to make everyone switch to that.
(and if there is anytime a work towards EPP v2 there are other problems far
more pressing to fix there than just email).

> "it will bring all registrars to the EAI implementation."

I will let you believe that then, but 1) the IETF is not the protocol or policy police
even if the perfect solution is designed there is no guarantee anyone will use it
and 2) a non technical problem can not be solved by a technical solution, no matter what
you will do here, each registrar has its own business case and can decide, from its
own point of view, if he wants to do that or not (and hence go up to not carrying the
TLD at all if there is no other solution). Which means that the registry has
to force by non technical means (aka: contracts) if it wants that behavior
(exactly like ICANN contracts mandates implementation of specific RFCs by registries
and registrars) or offer proper solutions for registrars not wanting to do it.
We can discuss here only the second part, if there is a change in current specifications
that allows nicely registrars wanting the feature and registrars not wanting the feature
to continue to work.

(also, you might be slightly forgetting the "transition" period. Even if registry X
says "ok in 6 months all email is EAI compatible, go fix your systems dear registrars",
and no matter what delay you give, it will be too short for some)

Look at DNSSEC and IPv6 for similar cases of "but everyone should be doing that,
it is even mandated by contracts" vs the sore reality of "yeah it kinda works at
some places but certainly not everywhere".

I think it is better to stick to proposal and see how they work.
Another options is to first document the problem and constraints space, and then
in a separate document offer a solution.
Making everyone first agreeing exactly on what problems need to be solved
can frame discussions efficiently.

-- 
  Patrick Mevzek
  [e-mail]