Re: [regext] Internationalized Email Addresses and EPP

Patrick Mevzek <> Tue, 24 November 2020 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 782DA3A126C for <>; Tue, 24 Nov 2020 09:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.22
X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=IZm4Abs1; dkim=pass (2048-bit key) header.b=Q4DUHzIp
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D5vycyJB00me for <>; Tue, 24 Nov 2020 09:57:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CB533A121D for <>; Tue, 24 Nov 2020 09:57:03 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 689A2D9C for <>; Tue, 24 Nov 2020 12:57:03 -0500 (EST)
Received: from imap22 ([]) by compute3.internal (MEProxy); Tue, 24 Nov 2020 12:57:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=GHDCAtpJR25ewCWCtSHhMaF8quAfWBw /Uw1k4yX/mSM=; b=IZm4Abs1RQOGngdbrUi/tw92Eu6i89A/wDJnt11h7NSk35p r6iNaLmG0hv0i0WA0Foa7uN0H1PCsZ/omxF0gXGVPicAl0IxGrrlNtAMxCJ7fafC coDKZb7+aee0pX0lPOLa+d7qfEmBehBnLx8KFIp4aJlcyoxC5CtNTIahr09ex9ye tSuarMCWFdeApIjkyLYW80Vv04omvfwIKEMTt/daSsX+N7s+09xqV/dYHsSGmMzh 1ky+qI8HDhmm2rsEJFTqxTDparNu/AWXlhRyAGUhYSbqtixhXWxbEmLt8ufEBvMo LP/IxzuaKr1ENSuf4aoRlkuUlQ/QOCUntVqK0Jg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=GHDCAt pJR25ewCWCtSHhMaF8quAfWBw/Uw1k4yX/mSM=; b=Q4DUHzIpiBTKt+EoFvnOK9 DHaXF3iqFiyjcy9YgtYmhd9am1mr/ydnoTVOhT0/szwtO3zjcWfgB9A/Loq1Qbvb Zjz/TKbgGN8fFVwSBGe3csLIIoyhg+O+UwPNZ9LPrfIDWJQ6DXHvURZeU/EefP5Z UmN+s7upPkxAXPjJ6mtk/lZC9kcpoxKm1Jeoy5Xp+ewMI4/uMtBMf/nRwOBnqDRQ ERHqrMsZim/f0EvyIXJUwidpbHpPHA4c6N+fXKBKLxs14VVxkhEQiDfYu2glQo1a 0y/gub8IolbM7C2lrR3KQ1vVJb4YO9IDzRpyUCelHmd55gXReEPD7XziSAJoAhxA ==
X-ME-Sender: <xms:bkm9X4kNgqMrfZDJNkH6Z_LlTfQEH0wvbFfPa1yuFOYHuTp2yown4Hw8AaM> <xme:bkm9X331ygYc4Zgxke_pGIEgJBvPG-l3kY8mDDFcvTbo_DdZFENVijMrzyG1EVFrw NQ3vD2A7r0uYmhH7g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegkedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdfrrghtrhhitghkucfovghviigvkhdfuceophhmsegu ohhtrghnuggtohdrtghomheqnecuggftrfgrthhtvghrnhepudfgffeiheffjeekudfhvd ekveffudefueeikeehueffjeefjeeiteeihedugfeknecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepphhmseguohhtrghnuggtohdrtghomh
X-ME-Proxy: <xmx:bkm9X2oslelvgcvA4FwSIS8G49lAjhVM9ck6EO6JFUtHNRrYC7jKpg> <xmx:bkm9X0mRBp0tnBHPjcmBdjnAyxUBpuTfAvVtqLFgstAKAke8gvwOYw> <xmx:bkm9X2024zv9JmEgaITpjqtwVFqUwYJbWA8hyJKZ5hm_5BXKbjnX-g> <xmx:b0m9X3BASXK-XF16PqXw3WYgDcS2jamM_OCAj7g8hlh-4ayr_IwXPw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6F53A668007A; Tue, 24 Nov 2020 12:57:02 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <20201123205504.4A58627C7661@ary.qy> <> <> <> <> <> <> <> <>
Date: Tue, 24 Nov 2020 12:56:39 -0500
From: Patrick Mevzek <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [regext] Internationalized Email Addresses and EPP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2020 17:57:06 -0000

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