Re: [regext] Internationalized Email Addresses and EPP

[Taras Heichenko <[e-mail]>]

> On 24 Nov 2020, at 19:56, Patrick Mevzek <[e-mail]> wrote:
> 
> 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).

You ask strange questions. There are DB with data that my interface does not support.
How can I work with the DB under such circumstances? Really I do not have an answer
to this question. It looks like "I wand use email but I do not want my software to correspond
RFC 5322. What should I do?"

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

I know what is IETF. But I dislike the approach: we made some standard from our
heads and now you can do with it whatever you want. And I saw here thoughts that
differ from yours from the people that are working in this area. What are we going to do?

Maybe it is too early to adopt such a standard and we should wait until usage of non-ASCII
email on the Internet would be more defined.

From my point of view, the extension does not give any advantages. It makes the protocol
more complicated and gives nothing back.


> 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]
> 
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

--
Taras Heichenko
[e-mail]