> On 24 Nov 2020, at 19:56, Patrick Mevzek <[email protected]> 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
> [email protected]
>
> _______________________________________________
> regext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/regext
--
Taras Heichenko
[email protected]
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
