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

"Gould, James" <> Wed, 31 August 2022 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B18DC159481; Wed, 31 Aug 2022 10:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.407
X-Spam-Status: No, score=-4.407 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, RCVD_IN_DNSWL_MED=-2.3, 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 OIx82y6-k97d; Wed, 31 Aug 2022 10:27:03 -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 948B3C1524A5; Wed, 31 Aug 2022 10:26:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; l=16274; q=dns/txt; s=VRSN; t=1661966822; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=HZ0KE2RmGYtDuOLS3DXjy6gZKEOsy2D6jyGxQsj/0VQ=; b=iBehs9A8IeSvapb5ijIeEwpOx8FRK2m3Z+eL/lKZubBO/KT5Iz45YZ0k vgVqFVsE0/MT5kqZEKrc/PNm4ZuL8Ut0Y1AgG6SjiIc3vbUNw4byCC8+k GCWdhOtjAVRQFixq9LHlFO5cUDqYHfab0iFftBd664K8jD11o1bWp88tP 7sGlTI904OU6VOf/60Sdzo8rNE5TK1Wp18D6w8NWlZaJbSZaMUfCYYCX2 Aj+T3FabRwlIOv/UC5+VrkawA2LjPh61OzYswD5mPIuqvauDkS2dZiJww yIgntFzIlTTbXdj3g7bzkCnTCZmXx+6NC/YnE4uVVSFp6rISNL6z/wCPI A==;
IronPort-Data: A9a23:bC/yQ6kf14ikCW0eY/MZM3zo5gxyJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xIYWWqOa/2DN2qhKdhxPNi29kJUvsCHzoAxHVdpqi9kES4T+ZvOCOrCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZmgH+a6UqicUsxIbVcMYD87jh5+kPIOjIdtgNyoayuAo tqaT/f3YTdJ4BYpdDNPg06/gEk35q6q6GhB5gZWic1j5zcyqVFEVPrzGonsdxMUcqEMdsamS uDKyq2O/2+x13/B3fv8z94X2mVTKlLjFVDmZkh+AsBOsTAbzsAG6ZvXAdJHAatho27Qw40uk oUlWauYEm/FNoWU8AgUe0cAT3EmZcWq8pefSZS0mZT7I0Er7xIAahihZa07FdRwxwp5PY1B3 cwANwsVaRXSvcOR2bS7ErIwj5Uda8a+aevzulk4pd3YJdwcZ8n8ZYj6vYUewjw3nNgIFPqYe dACb3xkaxGojx9nYw9RUc1l2r713T+jIlW0q3rMzUYzy2rcyxF13JDzPcDUYd2FQ4NemUPwS mfupjWpU0BAZYz3JTytrVKzucLShnPAR8EiDoTk3NRF33G+2TlGYPERfR7hyRWjsWa8XNJZb k0Z5iQGr6MxskesS7HVVRC8rHuFojYTXtNRF6sx7wTl4rLd7S6BD2YYQzVBLscr3Oc/XyAC1 1KVkZXuHzMHmLGPQHyBs7aZsT33IyUaIH8eICIcVU4I6tilqYU3phPCUtglF7S65vXxECrsh juDqCwWhrgPg4gMzarT1UrKjD+8urDIQxI7oALNUQqN71opYoKkfaSp5ETVq/FaI+6xQVSH+ XEeh+Cf4fwAS5aXm0SwrP4lFquvvumDPS2E2xt0AYNn8jW2vnSkO4pK5mg4Ol1yNIAPfjqBj FLvhD69LaR7ZBOCBZKbqaroYyj25cAMzejYa80=
IronPort-HdrOrdr: A9a23:D93o16s1Exfnd9LuzBJylZgR7skDq9V00zEX/kB9WHVpm6uj5q WTdZUgpH3JYVkqOE3I9ervBEDiexzhHPdOiOEs1NyZLWrbUQWTTb1K3M/NzzrtACXi+uMY/r cIScRDIey1KVRhl8717E2bH8ZI+rO62ZHtoevF1X9iQUVRdqd6425CZzqzCEFsWwVcP5Y/Ga ed4sYvnVGdRUg=
X-IronPort-AV: E=Sophos;i="5.93,278,1654560000"; d="scan'208";a="19899298"
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.31; Wed, 31 Aug 2022 13:26:41 -0400
Received: from ([]) by ([]) with mapi id 15.01.2375.031; Wed, 31 Aug 2022 13:26:41 -0400
From: "Gould, James" <>
To: "" <>, "" <>
CC: "" <>, "" <>, "" <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: Re: Re: [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)
Thread-Index: AQHYvV7VIere/8io9E+86Yb5YPYk3w==
Date: Wed, 31 Aug 2022 17:26:40 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.62.22061100
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
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: Wed, 31 Aug 2022 17:27:07 -0000


draft-ietf-regext-epp-eai-16 was posted that addresses two of the issues that you raised, by changing to use a command-response extension, and to replace the EAI references with SMTPUTF8.  I believe the remaining issue of the e-mail cardinality needs to be brought back to the REGEXT working group for discussion.  I've requested an agenda item at IETF-115 for it and I encourage you to participate in the meeting to discuss it first-hand if the agenda item is accepted.

Thank you for all your detailed feedback and discussion!


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

12061 Bluemont Way
Reston, VA 20190 <>

On 8/30/22, 4:11 PM, "Gould, James" <> wrote:


    To clarify the "we" in the statement "Based on your feedback, we agree to revise the draft to be a command-response extension and to refer to an SMTPUTF8 address instead of an EAI address." are the co-editors (me and Dmitry).  We (co-editors) are attempting to address your feedback based on the scope of the draft that was discussed in the WG.  Changing of the cardinality (one to many) to support an SMTPUFT8 address in addition to an ASCII address was first brought up by you during the IETF last call.  It sounds like you agree that an ASCII address is not required, which is good.  Where we (co-editors) and you disagree is your proposal of changing the cardinality of the e-mail addresses in EPP, which is a material change that we (co-editors)  don't believe is warranted.  If there is the need to change the cardinality of e-mail addresses in EPP, then a new EPP extension can be created for that purpose.  That is not intended to do handwaving, but to state how things are handled in EPP.  My point around the FOA and RFC 9154 was meant to show that the concern you raised is not a current issue and should not be an issue in the future.  

    We can agree to disagree on the cardinality proposal.  I would like to hear from others on this topic. 




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

    12061 Bluemont Way
    Reston, VA 20190 <>

    On 8/30/22, 3:44 PM, "John C Klensin" <> wrote:

        (TL;DR summary at end)

        --On Tuesday, August 30, 2022 12:18 +0000 "Gould, James"
        <> wrote:

        > John,
        > You claim that the registrant's e-mail address in the registry
        > is critical to the transfer process and therefore an ASCII
        > address must always be provided.

        That is not what I said and I have explained, several times now,
        that I have not said or claimed it.  What I have said is that,
        if a non-ASCII email address is to be supported, there should be
        provision --as part of this change, not some handwaving about
        future possible extensions-- for an all-ASCII alternative to be

        >  The EPP credential used to
        > authorize a transfer is not the e-mail address, but the
        > Authorization Information.  I'm aware of the Form of
        > Authorization (FOA) that relies on the registrant's e-mail
        > address, which is currently deferred for the gaining registrar
        > (registrar ABC in your example).  RFC 9154 "EPP Secure
        > Authorization Information for Transfer" was created to enhance
        > the security of the Authorization Information, which should
        > result in reducing or removing the dependency on the FOA from
        > the gaining registrar and the use case that you're concerned
        > with.  

        This is all wonderful.  But unless you are prepared to show that
        RFC 9154 has been universally adopted, all the above does is to
        strengthen the case for allowing for (again, I did not say
        "requiring in practice") an all-ASCII alternative address when a
        non-ASCII one is supplied.  And, even if you could show that
        level of adoption, it would have nothing to do with all of the
        other uses of information that might reasonably be expected to
        be in registry databases.

        > You also claim that if the draft does not change the
        > cardinality of the e-mail address in EPP that it's not a
        > proper candidate for processing as an IETF standards track
        > document.  Adding support for EAI addresses as a first-class
        > alternative to ASCII addresses in EPP is an important change
        > that warrants an IETF standards track document.  

        I didn't say that either.  I'm not even convinced that
        "cardinality of the e-mail address" is relevant.   I believe it
        was you who claimed that, since that cardinality was not
        changed, there was no need to show this document as updating
        5730.    What I have tried to say on that subject, several
        times, is that draft-ietf-regext-epp-eai is either making a
        substantive change to 5730 or it is purely supplemental to it.
        If it is making a substantive change, then it must be identified
        as updating 5730.

        It is fairly clear to me that, if a document said "there are
        three ways" and one adds a fourth, that it is a change
        ("update").  Contrary to an earlier claim from you about what I
        said, I never claimed that the document said "there can be only

        Of course, if you are dropping the "functional extension" idea
        and moving to one of the extension types specified in 5730, that
        issue is, of course, moot.

        > For an EAI address to be stored in the registry database, it
        > needs to pass through 3 levels of policy.  The registry policy
        > needs to support receiving either an ASCII address or an EAI
        > address.  The registrar policy needs to support collecting an
        > EAI address as an alternative to or in additional to an ASCII
        > address, and support passing the EAI address to an EAI-enabled
        > registry.  The registrant decides, according to their policy,
        > to provide an EAI address to the registrar.  The protocol
        > should not override these policy decisions by mandating an
        > ASCII address always be provided.

        Ok.  Really interesting.  And almost completely irrelevant to
        this particular specification and protocol, as you have
        indicated in the past.  You have left several actors whom I
        consider important out of your explanation, but that is almost
        completely irrelevant as well.  I even agree about the last
        sentence but, while I will again point out that the experience
        with SMTPUTF8 addresses (outside narrowly defined contexts)
        would recommend providing such addresses, neither I (nor, as far
        as I can remember), anyone else has recommended "mandating"
        them, much less overriding any policy decisions.  Instead, the
        recommendation has, consistently, been that the protocol for
        passing along non-ASCII addresses (I note that you continue to
        use "EAI address" above) if the relevant actors decide to do
        that also make provision for passing along all-ASCII ones should
        those actors make that decision.

        If I try to rephrase that into the language of your paragraph
        above, if any of the relevant actors, including those I believe
        you have omitted, decide that a non-ASCII email address is not
        acceptable unless an ASCII alternative is supplied, the protocol
        should not override that policy decision by making it impossible
        to provide such an address, at least without going back to the
        IETF and trying to initiate additional work that, because it was
        not designed when the protocol specification was approved, might
        turn out to be more kludge-like than desirable.

        > In line with Universal Acceptance (UA), what
        > draft-ietf-regext-epp-eai does is to enable the servers
        > (registries) and clients (registrars) to pass EAI addresses as
        > first-class citizens to ASCII addresses in EPP, with the
        > appropriate signaling and behavior obligations.

        I was not aware that the IETF had accepted the efforts of the UA
        effort as binding technical judgments rather than, e.g.,
        promotional efforts from another community.   References to that
        work and its conclusions are notably missing from the document.
        I recommend that we not go there.

        > Based on your feedback, we agree to revise the draft to be a
        > command-response extension and to refer to an SMTPUTF8 address
        > instead of an EAI address.  Changing the cardinality of the
        > e-mail addresses in EPP to continue to support an ASCII
        > address is required policy is not in line with the purpose
        > this draft.

        Could you, or the WG Chairs, please explain "we" as used in the
        paragraph above?  I just took a quick look at the REGEXT mailing
        list archive and there is no evidence of any discussion in the
        WG -- the only relevant messages are those copied from this list
        discussion.   I also note that the minutes of the REGEXT meeting
        from IETF 114 say, in part, 

        	"This document has quite some discussion in the
        	IETF-wide last call, and issues reported from: i18ndir,
        	secdir and artart LC.

        	"No in-meeting comments beyond the above."

        So, whomever "we" is, it presumably is not the WG who forwarded
        this document to the IESG for publication approval and that has
        tracked it closely since, approving of each change.   I also
        note that, despite the changes you outline above, the Shepherd's
        report has not been updated since April.

        TL;DR summary, as promised...

        I appreciate the changes you have outlined above.  I should
        perhaps wait for a new draft, and perhaps a new Shepherd report,
        before commenting further, but, assuming those changes will be
        as I am assuming, there is only one remaining
        technical/substantive issue and that is whether, if you are
        going to provide for transmitting a non-ASCII email address in
        the protocol, you should also make provision for supplying a
        non-ASCII alternative in the protocol as well.   Such provision
        would be consistent with the recommendations and experience of
        the EAI WG as well as several of the examples I have tried to
        supply; not providing it is inconsistent with both.  You will
        please note that the previous sentence does not say "required to
        use" -- that is clearly a policy matter -- only that the
        provision should be there.

        At this point, there is a separate issue, which is whether,
        given almost no evidence of WG discussion of this document after
        it was adopted (converted from draft-belyavskiy-epp-eai) and
        certainly not after external reviews started to be requested,
        this is properly processed as a WG document with the strong
        assumption of consensus within the WG rather than as an
        individual submission by the authors, perhaps one that the WG
        decided was a good idea in principle.