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

Dmitry Belyavsky <> Thu, 18 August 2022 11:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DE9FC15270C; Thu, 18 Aug 2022 04:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=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] 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 MItpogaCPIag; Thu, 18 Aug 2022 04:53:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::112f]) (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 51454C15270D; Thu, 18 Aug 2022 04:53:15 -0700 (PDT)
Received: by with SMTP id 00721157ae682-335624d1e26so34226367b3.4; Thu, 18 Aug 2022 04:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=zTPbbAM165VDVqTqO60Xa9JSEegOmaUoSX964U+QN9U=; b=a+1F26jfPmdmevL3SWZDMpFooylnqjh7zwD/F0sENzo4tX5E1BA++hHqhqX5eD6Q4f vNp9eCepPg/jQz3oWdCxmTYfyfsHVzfTNELyRDvoPJMXALrmtqGrFq4h7Wm5xuLchahc +zqEpTMlrSPAJLe5fXSveeUBtwwH79WISnBNLKRRFTCkJpDXI4EUjfjBdZ1N6OsJI7be gBquhzXVJ6g7UbB0GlHSIync13gIRfqhWgh6fGjg5BIZ8W69nGVMP0Wn6k/8Wz8Y89zb K6sCQXGP8JwFkjZV8g/yN8J03za2memfBDdLeJgVRs21ZdeB6NnJ8js77OObWLzwue7r EXrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=zTPbbAM165VDVqTqO60Xa9JSEegOmaUoSX964U+QN9U=; b=hGM3rROZKaQB512bP2KNvwRJlDGfjl/WID2moELujEYQTsJeEkgl0v8aSRwEQq6C+3 U0auxF0xznCJSTG4lQ2hcZsnE4lvIqgQ2Zja6c48Z5Jv1fQCVzzkZZGw5AN0fu8PkAqA ufiLtB/zeoA7Pge60ybV/P5pJn164XRbedY7m/KXYMbrBfdLTyJ+fU//iynXkfRBoyCJ w2GkOZ5AjI7mX9+f+1lQALQIjjUKVQzvgu+hatcIWsun8sV9prqCj25SMhZ2womk2lSx LYmVJV47no1TEUCiySuCDANpgG3gx1HS4qzdNo5g4qubU2YeTTaV6/qQ0BAFlcSq2Jyx ukwQ==
X-Gm-Message-State: ACgBeo09ntC/HwABTUhcn0ES00MKbmatbiErTuZUxF4w0CQHslX56gA0 V6otD9YQTnD39HkYYK0NyUC4TjGMo5z4Qt26wrs/jj7ukC0=
X-Google-Smtp-Source: AA6agR52GBMGSlYI+FK9Vj/5JsBWDw+g99IzwDzETNNTbxk5IvxFhfBJdWLsy63/AiuGAM083f6jYOXbTgrf78AX5H0=
X-Received: by 2002:a25:7e42:0:b0:670:9c92:d1ab with SMTP id z63-20020a257e42000000b006709c92d1abmr2507541ybc.638.1660823594343; Thu, 18 Aug 2022 04:53:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <8510291CFDD59E597396E0A4@PSB>
In-Reply-To: <8510291CFDD59E597396E0A4@PSB>
From: Dmitry Belyavsky <>
Date: Thu, 18 Aug 2022 13:53:02 +0200
Message-ID: <>
To: John C Klensin <>
Cc: "Gould, James" <>,,,, regext <>,,
Content-Type: multipart/alternative; boundary="00000000000060236d05e682a08e"
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 11:53:40 -0000

Dear John,
Many thanks for your letter!

See my response below.

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

> James,
> 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
> here:
> (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.

> best,
>    john
> --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