Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

John C Klensin <> Thu, 15 September 2022 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB7C8C1594BA; Thu, 15 Sep 2022 14:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ja-ALuQ0xp2d; Thu, 15 Sep 2022 14:19:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7705DC1594A5; Thu, 15 Sep 2022 14:18:57 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1oYwG7-000CIR-6s; Thu, 15 Sep 2022 17:18:55 -0400
Date: Thu, 15 Sep 2022 17:18:49 -0400
From: John C Klensin <>
To: Василий Долматов <>
cc: Dmitry Belyavsky <>, "Gould, James" <>, Patrik Fältström <>,,,, regext <>,,
Message-ID: <2B590763A2B4B2106F9330F8@PSB>
In-Reply-To: <>
References: <> <1C6C85AAF7DA5EFEDCED0BB0@PSB> <> <4ACF0279061CC0B6C78E0E8C@PSB> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
X-Mailman-Approved-At: Sun, 18 Sep 2022 07:08:35 -0700
Subject: Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Sep 2022 21:19:02 -0000

Vasily (just guessing at the Anglicization of your name;
apologies if I got it wrong, but that could illustrate part of
the underlying issue),

Our differing experiences may be leading us to somewhat
different conclusions even though we agree on the objective.
Inline below...

--On Thursday, September 15, 2022 17:55 +0300 Василий
Долматов <> wrote:

> Hello!
> I understand your concern, that if this content in e-mail
> addresses will be standardised, then at least for some period
> of time (very lengthy one, indeed) some «unreachable»
> address domain could be created. at least for some time, while
> all MUAs will be upgraded.

Actually, that is not quite the concern.  I am trying to find a
way to allow an effective, safe, way for people to transition
into the use of non-ASCII email addresses.  I recognize that it
may take some (long) time before all MUAs are updated but, in a
way, that is exactly the point -- not to wait, but to be sure
that a smooth transition is possible.

Also, if "all MUAs will be upgraded" implies that all such MUAs
should be able to handle (as input and in consistent displays)
any local part that is valid under SMTPUTF8, the time before
that occurs is likely to be "forever".  Around 6000 years of
history with writing systems and some issues in the design of
Unicode are against a quick result.

> from the other side, if this will not be standardised - there
> will never be move forward in technology.

And, if it is standardized in a way that demonstrably will not
work in situations that might be encountered, that is likely to
result in a much longer delay before there is general adoption
and possibly even regulatory pressure to avoid non-ASCII

While we have been talking about MUAs, presumably standalone
ones, I was reminded this morning that the HTML specs for the
email input type do not allow anything but ASCII text in the
local part.  Changing that is under discussion, but that
discussion does not involve the IETF, much less REGEXT.  Would a
change make this EPP extension easier to deploy?  Most likely.
But, until it is made and widely adopted, these addresses cannot
even be input to an HTML page that uses the "email" input type
for validation.  Again, that is not in any way an argument
against allowing non-ASCII email addresses in EPP.  It is an
argument for being sure that all-ASCII alternatives are
available when needed.

> I think, that the proper way forward is to standardise new,
> extended approach, whereas note that these addresses could not
> be for some time  be globally accessible (until software
> refreshment cycle will occur) and should be used for official
> and/or critical purposes with caution.

First, I agree with the cautionary note ... and recall that
there has been some resistance so far to incorporating such
things into the spec, with the position taken so far (as I
understand it) being that this a strictly a matter between
registrar and registry on which the IETF should not take a

However, I suggest that anything that is used in conjunction
with the registration of a domain name, especially part of
contact information has the potential to become something used
for or associated with official and/or critical purposes, is a
potential problem.   That suggests that, if your suggested
caution were taken seriously, no one should actually use the
approach in the spec until the time comes when the addresses are
globally accessible and meaningful (however that is defined,
which is, itself, a tricky question).

So, what I am suggesting is that an extension be adopted to EPP
(presumably a modification to the current spec) that allows, and
to the extent possible, encourages, the use of non-ASCII email
addresses, the local parts included.   I am also suggesting that
the best way to facilitate that, in the world that I think we
agree exists, is to allow for the addition of an all-ASCII
fallback email address for situations in which it might be
appropriate and/or necessary.  I still do not suggest that be a
requirement but, if a registry or, e.g., ICANN, asked me for
advice, you may be able to guess what I would tell them.   For
situations in which someone needing to use an email address,
tries to use or encounters a non-ASCII one, and hits some sort
of roadblock (MUA, HTML, or official and/or critical problems)
it will be possible to have the all-ASCII address available and
smoothly fall back to it.  The alternative, in terms of
encouraging deployment, is that when (and I believe that is not
"if", but it doesn't make much difference) those roadblocks are
encountered, those encountering them have two options -- (i)
some sort of per-situation out of band solution that may require
use of the non-ASCII email address in order to obtain an
alternative to it (sometimes known as a "chicken and egg"
problem) or (ii) deciding that non-ASCII addresses are just not
ready yet.  The latter is a guaranteed setback to any desires or
plans for early deployment, especially if the party encountering
the problem is in a position to make official /regulatory rules
about what is allowed.

That view suggests something else: one alternative to having an
all-ASCII alternative address available is to spell out, in the
specification, exactly what one should do to proceed if a
non-ASCII address is encountered and cannot be handled.
However, the authors seem determined (and, fwiw, I mostly agree
with them) to keep such explanations or guidelines out of the
spec.  In addition, I suspect that, if it were spelled out, it
would either be the end of this extension in the IETF or the
foundation for an argument that organizations with regulatory
authority (or who, for example, pay attention to the needs of
law enforcement agencies) should ban the use of those addresses

best regards,