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

Василий Долматов <> Thu, 15 September 2022 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DE75C152580; Thu, 15 Sep 2022 07:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vHSBI5uZcYCK; Thu, 15 Sep 2022 07:55:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 2D4A1C1522CF; Thu, 15 Sep 2022 07:55:34 -0700 (PDT)
Received: by with SMTP id f14so29842961lfg.5; Thu, 15 Sep 2022 07:55:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date; bh=RSddMy4BbGtq9fh996EhRKxsjNVyKBAXQsDrMaM/+L8=; b=F0y3MteNXUnEqARVvWuZVSLW8DFsgQudMvBeqBOdFSGMkXBga7xDIq6Zn/0I5jT4Ay XIZfUXvrFwfRM3xbYa1zx8k+KaMtF3i6vSlvqfU6IO7ZsyJGmDg0I23EQFm3oanc0pI9 rOvk5PL3y04YGoSew6oQxGaEGy3pSb1Cr4zxijQUdm8bUEKd2F8YncwgIKs3QcVSSWsj May/MuuJsnpM85bQsJ4OLUIcAWq0Q+gr1Luhs1rcgg6I5ndabXJ5+LJ5CQViaF8pFWdB Lva0Hh9hRwUfTO4i1XT63fMwjwA9MGL1QdhgswyCCZ6AAHbMM5+nPj62sKYSXqT1qYZg PK2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=RSddMy4BbGtq9fh996EhRKxsjNVyKBAXQsDrMaM/+L8=; b=MDyxS/8KETBEqRuLMlZRAJS3eOFrwtyhrV/SKjHEWU21wne+Gi6rwmf9JQ3YUuSSPt dmDoLOfP4dUVBvGUtmhWWQ8L6LC0THdq+SMc/GOP0tAtpUQUHSNY/bcrD3ZO9QtIZ5zW yVOOMyfsexhIJYCIEstKPkK/LlY3RrRlNM7RFBoeIBTYuO3jrXmwDpU8oTra22BiBHAh VnQDh0WIVkH2CtYZxg1mqG8Q+XVwJMcFvwbP0J+ovCKc0WD/Y9H00Vvymhw2ZT3cC29s E9+qWZdkVR9FDYTaEVyOaOQh54m6HmPqa2tCz6rjS2QoQDrRTlLBkCTDxGVbdPMm3ELb qMaA==
X-Gm-Message-State: ACrzQf0Ww/wbDLbcQgVm2NPzRmLgU4Ng6wzBKCcKjFsilrJBhl+tKIE2 0wwBozOKU/Hir4ClRzsvOrs=
X-Google-Smtp-Source: AMsMyM6DONZOwkGzCV0/kLqnj4gBcl8MKKz04Cqk3QSLySkTSbb9bckyc3OixcKtw387L8ryPpd0bg==
X-Received: by 2002:a05:6512:3182:b0:499:edbc:d23c with SMTP id i2-20020a056512318200b00499edbcd23cmr92964lfe.675.1663253732263; Thu, 15 Sep 2022 07:55:32 -0700 (PDT)
Received: from ( []) by with ESMTPSA id v16-20020a05651203b000b00492ca820e15sm3002569lfp.270.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Sep 2022 07:55:31 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Василий Долматов <>
In-Reply-To: <4ACF0279061CC0B6C78E0E8C@PSB>
Date: Thu, 15 Sep 2022 17:55:29 +0300
Cc: Dmitry Belyavsky <>, "Gould, James" <>, Patrik Fältström <>,,,, regext <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <1C6C85AAF7DA5EFEDCED0BB0@PSB> <> <4ACF0279061CC0B6C78E0E8C@PSB>
To: John C Klensin <>
X-Mailer: Apple Mail (2.3608.
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 14:55:38 -0000


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.

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

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.



> 14 сент. 2022 г., в 04:13, John C Klensin <> написал(а):
> --On Tuesday, September 13, 2022 22:17 +0200 Dmitry Belyavsky
> <> wrote:
>> Dear John,
>> Thank you for your clarification!
>> Let me explain my understanding.
>> First, SMTPUTF8 MUAs already exist.
> But are typically limited to a relative handful (compared to the
> total) of scripts.  See below
>> Second, if the registry provides this support, it implies that
>> it can deal with such addresses.
> To take an really extreme example, I think it would be seriously
> dumb for a registrar to allow an email address with the local
> part consisting of the Unicode code points, U+1F438 U+200D
> U+1F445 U+1F438 [1].  It might be bad news for a registry to
> access such an address.  I can't even guess how many of those
> SMTPUTF8 MUAs would render that in a reasonable way, much less
> allow users to type it without Unicode escapes.  Similar
> comments might apply to one consisting of U+0460 U+030E U+1CF50
> which I assume you will agree makes no sense (and I wonder how
> your favorite MUA would render it or how you could input it from
> anything resembling a "normal" keyboard).  But the SMPTUTF8
> specs allow both of those things (see Section 3.1(9) and 3.2 of
> RFC 6531 and Section 3.2 of RFC 6532) and, arguably, worse.
> Now, that suggests that it is very important that registrars and
> registries get some serious guidance, perhaps less about
> accepting non-ASCII email address local parts but about what
> restrictions they should impose.  You (and James) will probably
> suggest that is not a job for REGEXT or the IETF and I agree
> but, if the guidance does not come from somewhere, some
> registry-registrar pair will come along who are expert in areas
> other than Unicode and writing system issues, decide that they
> _really_ want to be supportive of internationalization and
> non-Latin writing systems and allow anything the SMTPUTF8 specs
> allow.  Noting that, for example,
> \u1F438\u200D\u1F445\ is, syntactically, a
> perfectly valid email address (but an all-ASCII one, not some
> sort of Unicode escape), someone is likely to be looking for an
> ASCII form in a hurry.  Or not, but that is where I think our
> more fundamental disagreement lies (see below).
>> Third, it shouldn't be a big deal for the Registrar to use
>> such MUA. 
> But you are effectively assuming that SMTPUTF8 MUAs, maybe all
> of them, can handle, in a reasonable way, handle any email
> address that is valid under SMTPUTF8 syntax.  That is just not
> the case.  Again, see below.
>> Fourth, the Registrant using SMTPUTF8 address also
>> is capable of dealing with it.
>> Sorry, I don't see where the chain is broken and communication
>> becomes impossible.
> And here is where we are making very different assumptions. As I
> understand it, you see this as EPP, and anything it might
> affect, being entirely a private-use registrar-registry protocol
> with, of course, registrant needs in there somewhere.  If one
> completely accepts that model, then a reasonable answer to my
> concerns is that they should be smart enough to not allow/accept
> addresses that they cannot deal with, manage, etc.  If they
> can't, they will find out soon enough, work it out somehow, and
> adjust their rules and procedures as needed.
>> From my perspective, the IETF is about the Internet and we have
> no more business standardizing a protocol for private use
> between a pair of commercial parties in the domain name sales
> and management space than we would, for example, standardizing
> peering agreements among ISPs.  Various protocols for
> communication across that peering boundary -- protocols that we
> expect will be used, or at least considered, by anyone involved
> in those arrangements -- certainly, but the agreements
> themselves and how commercial peers exchange, e.g., non-routing
> information or information about their clients are things we
> don't touch.
> So, again from my point of view, but with the understanding that
> I believe that the boundaries involved are a very big deal, I'm
> concerned about the data involved, whether it could end up in
> registry databases or be (legally) accessed by other parties who
> need to contact registrants, interactions with registrants who
> might want to change registrars, and so on.  From one
> perspective, all of those are ICANN issues, not IETF ones.  But
> the IETF should not be making protocols that constrain ICANN
> discussions or decisions in those areas unless they are
> absolutely, critically, necessary from a technical point of
> view.  The "transmit a non-ASCII email address only because this
> is a private protocol among about buddies and business partners"
> idea just does not work with those considerations.  So, to
> repeat what I said some time ago, I see your alternatives as
> providing for all-ASCII alternate email addresses along with
> allowing non-ASCII ones in a standards track specification that
> is about the Internet or dropping the idea of IETF
> standardization, treating the effort as a private extension for
> use by any registrar-registry pair who choose to use it, and
> moving the effort toward Informational registration by you,
> Verisign, or some other combination.
> We may need to agree to disagree about that, but I hope we are
> getting closer to clarity about each other's positions and
> concerns.
> best,
>   john
> [1] That is frog face, ZWJ, tongue, frog face: something that
> some systems would ignore and display as those three emoji
> graphemes and that others would interpret as two graphemes, the
> first as a frog with its tongue extended.
> [2] Cyrillic Capital Omega, Combining Double Vertical Line
> Above, U+1CF50.
> -- 
> last-call mailing list