Re: [regext] [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12

"Gould, James" <> Thu, 18 August 2022 12:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EB76C15270F; Thu, 18 Aug 2022 05:16:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.405
X-Spam-Status: No, score=-4.405 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5wOLiaKG6CvU; Thu, 18 Aug 2022 05:16:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00C26C14CE2C; Thu, 18 Aug 2022 05:16:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; l=31982; q=dns/txt; s=VRSN; t=1660825011; h=from:to:cc:subject:date:message-id:mime-version; bh=GtkW/q9qO9RGjXcn6NnXQI7lItET7ry94nI+FLB9tyE=; b=qolHaqK31hPIDoZn0S2ByS3nZpiqrxQ5VQVa+jGzv7iTHz+PbRHASchZ WKb0rZU2LDzQmEbAQPjiL0ApVExSzLjb9a5nBOI0zIBWJWx6U3CWiLnL9 ZTpTD7Pinq+WMXS+RVrcVRW2dyB/nOMHrSfd58kQfP1J2nxLpte4dPTKg e+X7RekoDPhi+JqZomr02APGeSAR/wnKEkwqI9RcxNZjK5LLgUYVCA6HZ pO/CoEesqmGr4k633yfH6eoJ4E6JVeuMHrtF9CPBrxwXT7f6zQk7aFms7 VX0D6BMZGXwCuxNbqeGUhfbEKPyJPcmuk7Hzic5zpMe1X7t9ODI/k3j6N Q==;
IronPort-Data: A9a23:9Lq8oaqibgbHdyyo0x3i9ruxOO9eBmJmZRIvgKrLsJaIsI4StFGz/ 9Ym7Vv2Y6LbNTf1e9hoKNPhxf41yZ+Gm9YwGwBtqyA2RC9AoMDJVY7GIkn8Zy7JIJSTHBM2s pRAO9TJdZ5qECDXrEynYui/oHN33v3SH+OtA+WUZ3AZqWOIKcsEoUsLd7kR3tcx3bBVej+wh O4eg/EzGXf8gzR6bTlE4P7Zo0Mzt/6stT0RsAZmOPtB4wWGnCFNBs5GdfC6IkWjT9gPFIZWZ QphIJKRpTqFokh3WrtJtp6hLyXml5aLZVDmZkJ+AvTk2F4azsAL+v5THOIGbktKgCm+kdl0y dFc3bS9Ug5B0pfkwYzxaDEFVXAlVUF60OWfeyLn4ZXDlxeun0bEmJ2CMmlnZeX0xc4qWQmix dRAQBgRYxaKgf6Bwb7TYoGAUex6caEHlKtG0p1R5Wmx4cQOGPgvcI2TjTNs5wrcs+gVdRroT 5FANWcwNkSojypnYT/7ALpm9AuhrienL20A8Dp5r4Jvi4TY5FQZPLQArLM50zFFLClYth/wm 47Iw4j2KkoVNoeVwDOqyEmxqPX1rAOqcoAiTrLto5aGgHXLroASIDcscwKEh9SJ0hT4RdlYM VRS8yZos7Ip8gqgSdyVsx+Q+SbC50FHHYMNSKtmuWlhyYKNi+qdLmoLSSNFZPQ4udU3Xj0l0 BmCmNaB6TlH6e3OESLHre38QTWaYTEMJz9BQgY/bTA45fPh+qAJlRzXUYM2eEKyppivcd3q+ BiAoSwygrQPpcEO3qS/u1vAhlqEpJ/JSEs06xnZdmCu7UVyY4vNT46n7kXf4aMcdJiUVFiav XcC3cOZ6cgCCJiXn2qMTfkDWraz6J6tOSfAqV9iA5dn8C6ik1avZ4le/HR/KVtnd9wJdjL5f AreoRsU6ZZSenKuaYd2bp6/TcMwwsDIEd3+SrXfZ95KSpl8aAHB+zthDWaK0m/ggFQEkKwjN 9Gca8nEJXdDWaJrzSCeRuoB3/ks3C9W7WzeQ9Xy1QiP0LeCajiSU7htDbeVRuoj6vqbpgjFq 4waLNWQjRBeS6j0ZW/d64hKa04QNn59DpfzwyBKStO+zsNdMDlJI5fsLXkJIeSJQ4w9ej/0w 0yA
IronPort-HdrOrdr: A9a23:Gnhcja0LT2kPJSBMsv4IeAqjBG8kLtp133Aq2lEZdPUzSL38qy nOpoV46faaslYssR0b9+xoW5PufZq0z/cc3WB7B8bAYOCJggqVBbAnw4fkzybpBiHyssVMvJ 0NT4FOTPn9F0Jzg8q/wgWpeuxL/PC3tISln/3XwXsodxxtcK0I1WpEIxyWCVJ7XzNLApcFFJ 6Rj/Atmwad
X-IronPort-AV: E=Sophos;i="5.93,246,1654560000"; d="png'150?scan'150,208,217,150";a="18308232"
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.31; Thu, 18 Aug 2022 08:16:40 -0400
Received: from ([]) by ([]) with mapi id 15.01.2375.031; Thu, 18 Aug 2022 08:16:40 -0400
From: "Gould, James" <>
To: "" <>, "" <>
CC: "" <>, "" <>, "" <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: Re: [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12
Thread-Index: AQHYsvxeNC9lKCPT9UOqWqv1ocACWg==
Date: Thu, 18 Aug 2022 12:16:40 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/16.62.22061100
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_B122AE2F7DA149BFB399C6D6C34B6864verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [regext] [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12
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, 18 Aug 2022 12:16:56 -0000

+1, I agree with the points that Dmitry has made.  I will add that we need to ensure that draft-ietf-regext-epp-eai is strictly focused on the interaction between the registrar and the registry, which is why the statements in question needed to be removed.  EPP is the IETF standard protocol used between the registrars and registries, so adding support for EAI to EPP is certainly a legitimate topic for IETF standardization.





James Gould
Fellow Engineer<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/>

12061 Bluemont Way
Reston, VA 20190<>

From: Dmitry Belyavsky <>
Date: Thursday, August 18, 2022 at 7:53 AM
To: John C Klensin <>
Cc: "Gould, James" <>, "" <>, "" <>, "" <>, regext <>, "" <>, "" <>
Subject: [EXTERNAL] Re: [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12
Resent-From: <>
Resent-To: James Gould <>, <>, <>, Jody Kolker <>, <>, <>, <>
Resent-Date: Thursday, August 18, 2022 at 7:53 AM

Dear John,
Many thanks for your letter!

See my response below.

On Thu, Aug 18, 2022 at 7:59 AM John C Klensin <<>> wrote:

Replying to this note rather that several of the others because
it most clearly identifies what is being done.  I am copying, I
hope, the relevant review teams.

There are, I believe, three separate but closely-related issues

(1) The document, through the -14 draft, contained some language
about an "extra" all-ASCII address when an SMTPUTF8 address was
supplied.  It failed to indicate how that was to be transmitted,
what function it served, where it might appear in data
structures, etc.  You now propose to solve that problem by
eliminating the discussion of such addresses, presumably because
it is strictly a registrar <-> registrant issues.   That would
be fine, except...

(2) Whether we like it or not, when non-ASCII email addresses,
especially ones using scripts very different from European and
other so-called GLC-related one are used in arbitrary ways, they
don't work smoothly and globally.  They are fine for, e.g.,
ccTLDs where communications, as well as domain name labels are
confined to a script or two and known providers, but not for
generalized communications or registries handling arbitrary
scripts.    If the purpose of this protocol is ultimately to
populate registry databases -- databases whose contents are
expected to provide reliable contact and identify information
for registrants even if that information is only accessible
under court order or the equivalent -- then all-ASCII
alternative addresses are a necessity.  It would remain a
necessity if the relevant registrar (or, for that matter, some
of its agents) goes out of business, taking any data with them
that are not part of the registry database.   Provision for the
alternate names should be part of the protocol, part of the data
structure, and part of the databases.  There may be cases where
they are not needed, but that does not reduce the requirement to
be able to carry and process them.

(3) Or if, as I believe one of your recent notes suggested,
those alternative addresses are strictly a matter between the
registrar and registrant, that raises two other questions.
First, if a registrar is in need of the information to
adequately communicate with the registrant, why isn't the
registry and those with legitimate access to registry databases?
Second, if the information covered by this draft is strictly a
matter of data supporting business relationships -- either
registrant-registrar or even registrar-registry -- and not the
operation of the public Internet -- the document does not make
the case that it is a legitimate topic for IETF standardization
any more than elements of service contracts between ISPs and end
users would be.

I strongly consider those alternative addresses as a part of registrar business processes not affecting the EPP protocol.

Answering your sub-questions:
First, the registrar has direct obligations to the registrant (and needs more contact information).
Registry normally doesn't have direct contract to a registrant until smth urgent happens to the registrar.

Second, this draft doesn't specify any new data that differs from those currently collected by the registry.
But this collection/transfer is managed by IETF standardized protocols,
and any amendments to this protocol is definitely a legitimate topic for IETF standardization.

Also, as these data are available (at least partially, for some categories of registrants, etc)
via RDAP, it is part of operations of the public Internet.


--On Wednesday, August 17, 2022 13:20 +0000 "Gould, James"
<<>> wrote:

> Nemo,
> In the -15 draft, we will be removing the following two
> statements in section 5.3.2 and fix the nit "allow:ed" in
> section 8.  I believe this addresses your issues.  Can you
> clear your "Ready with Issues" status in the tracker?
> 1.    Delete "It can be an extra ASCII email address collected by
> registrar or registrar-provided proxy email address." from the
> fifth bullet in section 5.3.2. 2.     Delete "The provided
> address can be an extra ASCII email address collected by
> registrar or registrar-provided proxy email address." from the
> last bullet in section 5.3.2.

SY, Dmitry Belyavsky