Re: [regext] Internationalized Email Addresses and EPP

Alexander Mayrhofer <> Mon, 23 November 2020 06:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7862D3A13EB for <>; Sun, 22 Nov 2020 22:04:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3qIzDDZ_2oFk for <>; Sun, 22 Nov 2020 22:04:14 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44E273A13E6 for <>; Sun, 22 Nov 2020 22:04:14 -0800 (PST)
Received: by with SMTP id s9so16656636ljo.11 for <>; Sun, 22 Nov 2020 22:04:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tYBcK+hAqnzlcUtShzBbap6UU+HdtTDNCK6SgyfctZw=; b=o+ARJrq2lqrET9hMUAcGx8ZwmYAqMiJzQAuuUF90IekFze2BYFiO/cTMiVlHvsg8gQ hLzs8H1VX7KnWsr6BwG5vA+A3tcKcQY/75Kov+xKLy0IdxGA49JsZAxZCV4at+4pQ6YR OIaG5EpOIuoI73nrsSrb64scXlzlHvKV6OU1ZokLBg5JTxBPbmggA9KcjZVyBVgLy8RC ZYXSnCA84ZiCl/Re3qji2bMNnTTa/2DOxnZLIjlWPy29tPi1N4Nora/XrYdLdGXwR5D8 ROt1Id1JUIr5c2jYslqmi0BZ/ku11IuJm9YeWQDhvOdSw9AP5pEzHG5YrfKzzC2KgT5X t+3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tYBcK+hAqnzlcUtShzBbap6UU+HdtTDNCK6SgyfctZw=; b=IXtnd7+OA9N70SuM6NMsGPHBaPwKNHtuEujHv3EtN1QMpLmv9yO+XoFU+rnWzm4ks8 AcV4D3LTB3mIEufO3wFZZsgDICnqQnHm6GFdn9sy6mOz1wIQ3tuOotxd6fU/ITPpQCh7 gRJFYY23yg+TvuAx0Q9E9k4rZd7OQ5fzGvgc5Br5f+9MAk772b2Zoq8YYXDdwea0BF+6 0X2EdIMeJdh9M6xCGnit07jnGdEj8sx27CUX8H52qlYO5jg/VjPhStFkxdzIJVV+ttQl C61N8kIPaOZB0RdCpGbXZ8X5mC3P3c24FuIcjaZAR7Nfuuph5SQlzbG4IXWMMSKtK64J ArDQ==
X-Gm-Message-State: AOAM5324SrDml1Q9YmwLfrrRL9cHj1zHpWCKhH2qJqN58AS/EQKvO+lj dLM1xiFtt4/j8L+7crVj/BBhrbcCdkkNjICLWVI=
X-Google-Smtp-Source: ABdhPJx16sDocFYvPbTeOPxarFi6EHff7T83SwvL8v4PiirLw0Ye4yIBfEGSILCuYW8YnHqDCOqeAcYtlQqHLBF5e54=
X-Received: by 2002:a2e:780d:: with SMTP id t13mr13358894ljc.470.1606111452044; Sun, 22 Nov 2020 22:04:12 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Alexander Mayrhofer <>
Date: Mon, 23 Nov 2020 07:04:01 +0100
Message-ID: <>
To: "Gould, James" <>
Cc: "" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
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: Mon, 23 Nov 2020 06:04:15 -0000

Jumping into this discussion quite late, but...

On Thu, Nov 19, 2020 at 4:39 PM Gould, James
<> wrote:

> The 3 options presented and discussed at the REGEXT meeting included three extension options, which all include an namespace URI in the greeting and logic services:

I'd really like to understand why there's not option (4), which, as i
mentioned, would be:

- Accept EAI addresses like any other email address in the standard
EPP field (if the registry supports this). I don't see why the current
RFC 5730 ff schema would not support this.
- If a registry doesn't want to accept EAI addresses, return a 2306.
This is inline with many other elements of registry policies - eg.
when a registry validates the pc element of contacts against local
policy, it would also 2306 - and nobody has yet discussed an extension
for the purpose of announcing that the registry only supports a
certain set of pc values (nooooo, no i've planted ideas in all of our
- I don't see an issue with RDAP. RDAP can perfectly display non-ASCII
- Creating an extension like this will never make EAI's "first class
citizens". Accepting EAIs in standard "<email>" elements will.

Maybe I'm failing to see the point.  And, as Klaus said, we're making
EPP based registries a super complicated beast, implemented by a very
small community. Introducing "yet another switch" into the protocol
won't make it easier.

For example, what would an "old" client do that doesn't understand a
potential EAI extension? Would they be deprived of email addresses
completely, and receive non-sensical placeholders which they'd
unwittingly hand over to their email system (even if that email system
would perfectly understand EAIs?). Does sound like a failed
opportunity to me!