Re: [regext] Internationalized Email Addresses and EPP

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 23 November 2020 20:12 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BFA3A0CA0 for <regext@ietfa.amsl.com>; Mon, 23 Nov 2020 12:12:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5YKggdZRfBz for <regext@ietfa.amsl.com>; Mon, 23 Nov 2020 12:12:05 -0800 (PST)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08253A0FD3 for <regext@ietf.org>; Mon, 23 Nov 2020 12:10:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=16354; q=dns/txt; s=VRSN; t=1606162229; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=+fS5aUxIpA13npGQ6gQYSiegF2YUUXvSbkGQe1Z0/VU=; b=XG01gyKbcYukqP8Bj6jlcVWE/oNNFoLeRAp8slbvSqkKvQfIkkIKTX/0 s46P7afoaT/ZX0Y7Ld6lmpkdUYAS4A2bf0MPjDYxpq2bmlGxkXVQBtrXS VIKKAx0aGAKjLuyjJM8BZz+VBhHoKLCmWGHMagEZEnL+JE9re9Wul40L+ hEwHybtKawAjSVJ45OkbPh1SbH3OrFu7pLFkV+hoEo+TtZWD4EkXHvRsN z6tkQEy8YS+TwuOrQXaLIiWS8SyQeuzh7EcHl7mi1JcyfHSHm0cKpNX9y m7kYlCl8FFpJHINWWP13gbdPVHA/uRivIKGY0NCe/DlUFyk3UbDdwG03Q A==;
IronPort-SDR: 6Y21T04PYPlEEy8wjQh4vgSEPUxYlV0aX+8UneUKgU7X6HQ4hlHStELC5kRbpRQhwIiE86TVGW ESzbqFawen8060vAl68r33k6/5xXMGQ3gO9eK9mAmFTQfGDl6TircMHskoCECEB/fUdp49Pe4K ChoeuSv/SYEatnziQmwY6hP6SZFiTbCSyGxV3dP9DXRx3Z3u6ikgPDReFBeJ3rMiykr0SVOE5+ PQ0SRv0Vs9bzTmPU+r+7zo8BPbIfgBLnbiMbTXq0wpj/teEbDECWa2c53WgSa8z93AkeG4N9i+ VFk=
X-IronPort-AV: E=Sophos;i="5.78,364,1599537600"; d="scan'208,217";a="3834333"
IronPort-PHdr: 9a23:kmbTJBaF5Vz4hax5exb6bPj/LSx+4OfEezUN459isYplN5qZps29bR7h7PlgxGXEQZ/co6odzbaP7Oa5BTJLuMzf+Fk5M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFRrwLxd6KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAi0oAnLq8UbjopvJqksxhfXo3ZDZvhby35vKV+PhRj3+92+/IRk8yReuvIh89BPXKDndKkmTrJWESorPXkt6MLkqRfMQw2P5mABUmoNiRpHHxLF7BDhUZjvtCbxq/dw1zObPc3ySrA0RCii4qJ2QxLmlCsLKzg0+3zMh8dukKxUvg6upx1nw47Vfo6VMuZ+frjAdt8eXGZNQ9pdWzBEDo66b4cBDOwBPfhZr4nmplsBth++ChexD+LhzT9InGL53bYn2OglDw3KwAksEtQTu3rWsdr1Lr8fX+CrwqfV0TXNYfBY2Tn/54jJbh8uruqBUqhsfcrT00QjCx/Jg1eWpIf4Pz2VzOMNs22D4uZuV+yvjGonqwVvrTip3cgjlJXGhoENxlvZ6Ct23IE1JcGkSEJ1fNWpF4BQtyGdN4tyRsMtXWdotz0kxbIaup62ZzYKx4o9xx7ecPyHcoeI4hT5WOmNJjd4gWtodbSijBm97Uau0PfzVtWo0FlUtCpFlMHBu24R2hDO5MaKSflw8lug1DqT1Q3d5O5KLEI3mKfVJZMs3qI9moQTvEnHESH7mUr7ga+Le0sq5+Sm5Ovpb7f7q5KaKoR6iRn+P7wzlsCjG+g0LwoDUmaB9eih1LDu81f1TbpOg/Euj6XVrIrWKdkZq6KlGQNZz4ku5hWlAzu709kVm2QMIkhfdxKdlYfpPknDIPX/DfiinVuhiCxrx/XaPr35BZXNM2TDnK/hfblj705czxI+wM1D6ZxMF70OIOr9VEDwu9DEEBM1KRK0zPrgCNVnzoMSQ3iADbKDPKPMq1+I/eQvL/OQa48SvTbxM/kl5/jwgn8lgVIRYLWl0YEKZH26EPlqOViVbHrij9sbHmoHuhIyTOnwh12DVT5TaWyyX6U55jwjE4KmDYDDRoSpgLOf2ie0BYNZaXxFCl2XD3fnaZ+EW/YXaCKTLc9hlCYIWqSmS48kzR2urhP1y6J7LurI/S0VrYns28Zx5+LOkBEy9CB0At+S02GIVW50n2cISyUq06B4pEx30k2D3rRgg/xECdxT4OtEXR0+NZHCwO12EdXyVRjBf9eTSFamRdumDi8rTt4rwt8BfVp9G9u5gxDM2iqlGb4Vl7iRCJMo9aLc2mD7J9xhxHbeyKkhk14mT9NVNWK4ia5w6QfSB5LSnkWYiamqaaoc0DTK9GeZwmqEpFtYXxJoUaXZQXAfYVPbo9H95kzYUr+uEq4rPAxbxs6GLatKcNvpjFVdSffgPtTeYnqxm3+qCRmV2LzfJLbtLi8X0SHRDUkYuw8W9HeCcwM5A23p92jTCDBrFE7HbEbl8O04o3S+GBwa1QaPOgdB0L6x9xgfiPefD7so1bUYpG1p/y50G1K50tTcBtGDjxRsZqRHYNw7plxA0DSK5ERGIpW8IvU61RYleANtsharh016
X-IPAS-Result: A2G7AgBaFrxf/zGZrQpiHAEBAQEBAQcBARIBAQQEAQGCD4EjUoEpgTYKhDOOVYJRgQWJEIpshUWBaAsBAQEBAQEBAQEIAS8EAQGESgIXghYmOBMCAwEBCwEBAQUBAQEBAQYDAQEBAoZPC4I3KYNvAQEBAQIBIwpMBQcEAgEIEQQBAQEnAwICAh8RFAkIAgQKBAUIDIMTgX5XAw6vIjx2gTKIKw2CJIE4hmmBBoVsgUI+gRGCXTU+ghtCBIEeBQUBEgE4H4Jhgl8Eky8+hyGcKzhVAweCbpYLhQorogWTXI1zkm0CBAIEBQIVgWuBC3BwgzlQFwINjisXjiZ0AjUCBgEJAQEDCYwELYEGgREBAQ
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 23 Nov 2020 15:10:26 -0500
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.2106.002; Mon, 23 Nov 2020 15:10:26 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "beldmit@gmail.com" <beldmit@gmail.com>
CC: "alex.mayrhofer.ietf@gmail.com" <alex.mayrhofer.ietf@gmail.com>, "Gould, James" <jgould@verisign.com>, "regext@ietf.org" <regext@ietf.org>, "Klaus.Malorny@knipp.de" <Klaus.Malorny@knipp.de>
Thread-Topic: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
Thread-Index: AQHWwalkAXUbxf00tUW+4vL2x8ekVKnWJTcA
Date: Mon, 23 Nov 2020 20:10:26 +0000
Message-ID: <f57ec7e59aed47ce96f747f10c7468f1@verisign.com>
References: <C9EBEF19-55C1-4C5E-87BC-894FBF7439FF@verisign.com> <CAHXf=0p5F1LsUYoeX_mRNvuKNpeOvWufY0tNL9zNn+6Zj0cR1A@mail.gmail.com> <3d6ce5fd7d1e482fb3df168e0d26c0a0@verisign.com> <CADqLbzJC593jbno93Uc2zc1uM65TuN4YXgj5wzeZzhW2GmxDMg@mail.gmail.com>
In-Reply-To: <CADqLbzJC593jbno93Uc2zc1uM65TuN4YXgj5wzeZzhW2GmxDMg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_f57ec7e59aed47ce96f747f10c7468f1verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/HXPmb6UcLeY1zPwRo9t2UqXamaQ>
Subject: Re: [regext] Internationalized Email Addresses and EPP
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Nov 2020 20:12:07 -0000

From: Dmitry Belyavsky <beldmit@gmail.com>
Sent: Monday, November 23, 2020 10:00 AM
To: Hollenbeck, Scott <shollenbeck@verisign.com>
Cc: alex.mayrhofer.ietf@gmail.com; Gould, James <jgould@verisign.com>; regext@ietf.org; Klaus.Malorny@knipp.de
Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP



Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Dear Scott,



On Mon, Nov 23, 2020 at 4:59 PM Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org<mailto:40verisign.com@dmarc.ietf.org>> wrote:

   > -----Original Message-----
   > From: Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com<mailto:alex.mayrhofer.ietf@gmail.com>>
   > Sent: Monday, November 23, 2020 1:04 AM
   > To: Gould, James <jgould@verisign.com<mailto:jgould@verisign.com>>
   > Cc: Klaus.Malorny@knipp.de<mailto:Klaus.Malorny@knipp.de>; Hollenbeck, Scott
   > <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>>; regext@ietf.org<mailto:regext@ietf.org>
   > Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
   >
   > Caution: This email originated from outside the organization. Do not click links
   > or open attachments unless you recognize the sender and know the content
   > is safe.
   >
   > Jumping into this discussion quite late, but...
   >
   > On Thu, Nov 19, 2020 at 4:39 PM Gould, James
   > <jgould=40verisign.com@dmarc.ietf.org<mailto:40verisign.com@dmarc.ietf.org>> 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
   > brains!)
   > - I don't see an issue with RDAP. RDAP can perfectly display non-ASCII
   > characters
   > - 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.

   This may be the path of least resistance. I'm still trying to think through hat would happen if a registry returns an internationalized email address to a registrar that doesn't expect one. This could happen after a domain transfer, for example. Is this a problem? If not, maybe we could just get by without any other protocol changes or extensions.



   From my point of view, if the registry has implemented EAI support, all the registrars will have to do it. They should deal with the clients with such emails _somehow_.

   E.g., they hardly can reject the transfer relying on this reason.



   [SAH] I’m not talking about rejecting a transfer. I’m talking about what a registrar that does not support EAI would/should do if it is the receiving registrar of a domain that includes contacts using internationalized email addresses and those addresses aren’t supported by the registrar. How should this work?



   Scott