Re: [regext] Internationalized Email Addresses and EPP

Klaus Malorny <> Fri, 20 November 2020 08:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF15B3A1A9D for <>; Fri, 20 Nov 2020 00:47:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hjsn8qMEDFMM for <>; Fri, 20 Nov 2020 00:47:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 200733A1A99 for <>; Fri, 20 Nov 2020 00:47:31 -0800 (PST)
Received: from ( [IPv6:2a01:5b0:0:25::36]) by (Postfix) with ESMTP id 4CcqtS5jbHz4vDj; Fri, 20 Nov 2020 09:47:28 +0100 (CET)
Received: from [IPv6:2a01:5b0:0:25::1b] (unknown [IPv6:2a01:5b0:0:25::1b]) by (Postfix) with ESMTP id 85CBA70FF7; Fri, 20 Nov 2020 09:47:28 +0100 (MEZ)
Message-ID: <>
Date: Fri, 20 Nov 2020 09:47:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Thunderbird/85.0a1
Content-Language: en-US
References: <>
From: Klaus Malorny <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spamd-Bar: /
X-Rspamd-Server: v1117
X-Rspamd-Queue-Id: 4CcqtS5jbHz4vDj
Authentication-Results:; none
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:2a01:5b0::/32, country:DE]; LOCAL_WL_IP(0.00)[2a01:5b0:0:25::36]
Archived-At: <>
Subject: Re: [regext] Internationalized Email Addresses and EPP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2020 08:47:34 -0000

On 19.11.20 19:14, Gould, James wrote:
> Klaus,
> The EAI support goes beyond RFC 5733 and is a perfect example of the use of the extensibility built into EPP.  Revising the RFCs and EPP extensions that use email addresses for EAI with new XML namespaces and potentially other changes is much more impactful than creating an EPP extension that specifically addresses the issue with applicability across any EPP object.  I was involved with revising RFC 4310 to RFC 5910, which was needed to address significant implementation issues with RFC 4310, so I see it as a different use case.  The intent is to make the EPP extension as lightweight as possible, to apply across multiple EPP objects, and to include an appropriate level of signaling (e.g., session-level, object-level, element-level).  Any feedback is welcome.
> Thanks,

Hi James,

I chose DNSSEC as an example as I know that you took the major part in 
writing the update. At the very end, it is a matter of taste, and one 
cannot argue about. So I respect your position.

As you might know, my company is developing software both for the 
registry side (our TANGO software) and for the registrar side (for 
customers and our own purpose). And for the latter, dealing with all the 
slightly different implementations of the EPP, within the limits of the 
specifications and beyond, and dealing with the flood of extensions, 
including different versions of them, is really anything but fun.

As I understand it, the original idea of EPP was to have a common 
protocol for all registries, and it "failed by the wayside" (hopefully 
the right idiom). It is not about blaming anyone for this, maybe the 
idea was just too ambitious. So IMHO with every proposed change to the 
EPP ecosystem one should ask oneself whether it increases or decreases 
the overall complexity and the need for case differentiation, 
specifically in the long run. I do not remember who said this, but there 
is a proverb which goes like the following: If you design a protocol, 
don't ask what you can add to it, but what you can remove from it. While 
this is likely idealistic, I'll try to keep this in my mind.

Coming back to the issue, I see internationalized e-mail addresses 
coming to stay, like IPv6 did and IDN. So make it an integral part of 
the protocol, not an optional one, in the long run. But hey, that's only 
my taste.

Just my two cents.