IETF Logo Mail Archive

Re: [regext] Internationalized Email Addresses and EPP

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 20 October 2020 11:44 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 582313A11A6 for <regext@ietfa.amsl.com>; Tue, 20 Oct 2020 04:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 8Iz5rmSdK-8T for <regext@ietfa.amsl.com>; Tue, 20 Oct 2020 04:44:15 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 7FF003A0B3A for <regext@ietf.org>; Tue, 20 Oct 2020 04:44:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9984; q=dns/txt; s=VRSN; t=1603194256; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=vSEAXOXLTU18Cu2ECXqrgXdKpcLXc8YSmkoVoG4aOPc=; b=Xokdge7+XtTaop5n0kBPmj715dh3gWQ5jE55uGf9E2UZntS02rZcUrjv /MJAj9qzSpw5/0zYDserajoI62Kc1jPBvgq5ApFVOeMrcKcbSYvQZ2dEj +B1+PH6ualxqB4Ev9lWtZQDXLgxBDkPQgd3s8gIHJEA1L6GL9SqctlghJ 2yKciCa5ha+ZFgqV18rajKRgMHBp/ixkwGbfWfpX6VngVfNWhitCYoReW 2lQ10elpeMPSuFnKc86hrYAOByYE/BbyqEyhWU1j+JW3OV6oGT7lAWWeG StdAh8FgtH1LGBIDTzSIiAwG4SXJ8wioZJibvaIPsi84x6p0I8fOipWcJ g==;
IronPort-SDR: 6sTy0sz25nrVqllSXkyOX257NRKvJZIu1chnmcOB7KuouchTfZQAPw5WRReC6/OeO6WoCEqCDo XFBbCkXxMBFMrC1zaRg2nYB0lSPKODmpaUN/EaWqFaXkTQ1nfujcRgmBPbc2M0izt5V5h3iH1C o9c12gf5U6oaZ1mmu7xHBSr92NS17u6UkJgdk9Huof43TGtTww/gxMFNG8BnjwSOGZBFPjgWlP WOs7RPYiaEDFyEJEfMxK2pB/13jyTqEmkNgNUB+3TZm5w+C8X44yLyFvk6st3jpVU+DshuIMKm eXg=
X-IronPort-AV: E=Sophos;i="5.77,396,1596499200"; d="scan'208,217";a="2854811"
IronPort-PHdr: 9a23:d2j6PBxiVVNfWd3XCy+O+j09IxM/srCxBDY+r6Qd0uoSKPad9pjvdHbS+e9qxAeQG9mCtLQb0KGP6+jJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fcbglVhjexe7F/IRu5oQnMqsUdnJdvJLs2xhbVuHVDZv5YxXlvJVKdnhb84tm/8Zt++ClOuPwv6tBNX7zic6s3UbJXAjImM3so5MLwrhnMURGP5noHXWoIlBdDHhXI4wv7Xpf1tSv6q/Z91SyHNsD4Ubw4RTKv5LpwRRT2lCkIKSI28GDPisxxkq1bpg6hpwdiyILQeY2ZKeZycr/Ycd4cWGFPXNteVzZZD428cYUBEvYBM+hboYnzpVQOrAexCga3Cez11jNIhGX70bEm3+kjFwzNwQwuH8gJsHTRtNj5OqUcUeexzKnM0zrDaehZ1inh54jLahwqvOyCUq53ccrN1UkjGR7Og1KLqYzlODOV0uANvHad7+V7S+2gl20nphpvojex3Mcsi5LJhoMaylDC7yl23IE1JdihRUN9fNWrH4deuTuAOItqXsMtXXtouCAix7AYpZO3YSYExZclyhLDavGLb4qF7BzsWuuTIjp1inxoda6jihqs8UWtzuLyW8i73VtKsydLnMTAuH8C2RHR98WKTOZ28ES52TuXygzf9vtILV02mKfVMZIt3749m5QJvUnMGiL6gFj6gLOMekk5+OWk9/7rbqjpq5KfLYN4lwLzP6IzkcKlG+s4KBIBX22D9OS5073s4FP2Ta1Rjv0zjqnZqJfaJdkHpqKhAw9azIIj6xGnAjq7zNoWhWQLI1JddhyIjoflJ0/CLOrmDfijhFSsii9ry+rcMbL8GJnNMGLDkKznfbpn90Fczw8zwche55JSFL4BPOr+VlLtuNDCExM0MQK5z/z6BNh92I4SQ22CD6uBPKPXq1CI5+YvI+eWZI8SvTbwM+Ml5/7pjX89nV8SY6+p0oAJZ3+kHfRrOFuZbmT2gtcACmcKvwU+TOrwhFKeVj5TYm6+X7gg6TEjFIKmEYDDS5i2j7Of2Ce0A5hWZmFaCl2XHnfocp+LW/YIaC6IPsBhlTkEX6C7S4A9zRGuqBP6y71/I+rW/S0YtZTj1Nxu6u3Pjx4y6DN0D8SH326RSGF0m3sCRyUq06BnvUx91lCD3LBig/NGGtxc+fxIUhshOJ7d0eN6F97yVhjGfteTR1b1CumhVHs7Q9Y9xt4SS0l4EtSmyBvE2mDiV7UYk7COBYAc/afV3ny3LMF4nSXozq4k2hMGRc9LOGusi6V8s0DoDInVjw/Rw72qcqAY0SjH+WyA5XSDpkBDUQF2F67CWCZMNQPtsd3l6xaaHPeVArM9P14EkJbaJw==
X-IPAS-Result: A2E0CgCwzI5f/zGZrQoZAkUeAQELEgyCEYEhgXeBNAqEM5EfihCKaIVEgWkLAQEBAQEBAQEBCAEvBAEBhEoCF4FwJjgTAgMBAQsBAQEFAQEBAQEGAwEBAQKGSwuCNykBg2oBAQEBAyMKTAwEAgEIEQQBARcBEAMCAgIfERQJCAIEDgUIgx+Bfk0DjWGhI3aBMog4DYIkgTgBhmGGcYFCPoQhPoIaQgSBKAERAgFWEgKCTYJfBJApgyeHEZxLVAMHgmqUXYEKhQQrgxaeRJM5gXyLZZJTAgQCBAUCFYFrgQtwcIM5UBcCDZxmdAI2AgYBCQEBAwmMBA+BJIERAQE
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; Tue, 20 Oct 2020 07:44:13 -0400
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; Tue, 20 Oct 2020 07:44:13 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "beldmit@gmail.com" <beldmit@gmail.com>
CC: "Gould, James" <jgould@verisign.com>, "johnl@taugh.com" <johnl@taugh.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
Thread-Index: AQHWpj4mizpUIt/GiUuxf0IdgZQS+6mfdWOAgAAGNgCAAAZeAIAABgAA//+/iECAAFdpgIAAv/+w
Date: Tue, 20 Oct 2020 11:44:13 +0000
Message-ID: <80a04ff6c5284e2cb40a0a4483bacd5c@verisign.com>
References: <5F5D3BAE-B38C-4663-800B-3F591899086B@verisign.com> <20201019182855.978EB23AA539@ary.qy> <4841F38A-3127-4DBA-B7DA-951D359D0E96@verisign.com> <4b96a47ea53d409abb18bc65976d9300@verisign.com> <CADqLbzJKHJFRYQctdC5B=pFqvqF-T2muTEyzgBKA2WFFQ3_LFw@mail.gmail.com>
In-Reply-To: <CADqLbzJKHJFRYQctdC5B=pFqvqF-T2muTEyzgBKA2WFFQ3_LFw@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_80a04ff6c5284e2cb40a0a4483bacd5cverisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/K1YmISM77-iPN0T3svHNqka30v4>
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: Tue, 20 Oct 2020 11:44:17 -0000

From: Dmitry Belyavsky <beldmit@gmail.com>
Sent: Monday, October 19, 2020 4:12 PM
To: Hollenbeck, Scott <shollenbeck@verisign.com>
Cc: Gould, James <jgould@verisign.com>; johnl@taugh.com; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP







On Mon, Oct 19, 2020 at 10:03 PM Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org<mailto:40verisign.com@dmarc.ietf.org>> wrote:

   > -----Original Message-----
   > From: regext <regext-bounces@ietf.org<mailto:regext-bounces@ietf.org>> On Behalf Of Gould, James
   > Sent: Monday, October 19, 2020 2:50 PM
   > To: johnl@taugh.com<mailto:johnl@taugh.com>; regext@ietf.org<mailto:regext@ietf.org>
   > Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
   >
   > John,
   >
   > The signal would be handled via support for an EPP extension XML
   > namespace in option 2, an operational practice XML namespace in what I
   > would call 2b, or most likely a new contact XML namespace (contact-1.1) in
   > option 1 for RFC 5733.  The XML namespace would be reflected in the EPP
   > greeting services and login services.

   I'm more a fan of using an extension with a new namespace than I am a fan of trying to update 5733. An extension would be more easily consumed by other extensions that use email addresses vs. having to also update all existing extensions that use email addresses.



   Adding support of an extension is harder than just allowing EAI email addresses, both for registries and registrars.

   Also, we get some fuzziness on implementation level. E.g., can we set ASCII email via this extension?

   [SAH] I disagree on both points. Extensions are, by definition, opt-in. Registries and registrars can add support for them as they see fit. By changing the core protocol we impose a mandate for implementation. I’d rather not do that until we know that all elements of the underlying mail system (SMTP servers, mail stores, etc) support EAI email addresses. Extensions are additive, so yes, it’ll be possible to support both the legacy email addresses and the extended addresses if the extension is done properly.



   Scott

v2.23.0 | Report a Bug | By Email