Re: [regext] Internationalized Email Addresses and EPP

"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 19 November 2020 16:00 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 41F903A0D47 for <regext@ietfa.amsl.com>; Thu, 19 Nov 2020 08:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 CL8Ud-XUUMf2 for <regext@ietfa.amsl.com>; Thu, 19 Nov 2020 08:00:31 -0800 (PST)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 9A98A3A0D42 for <regext@ietf.org>; Thu, 19 Nov 2020 08:00:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2912; q=dns/txt; s=VRSN; t=1605801630; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=7mpO0g+6ru88MOLzCPd4OKisabKMY+473nhMTqwgLjM=; b=eVFM4y4qIVKjbkmlFqCJZNMjOuWY+WScNrjVqQEEcHMy8OpADIMGsWv1 dhqUCljyOyjDiFJlGg2QHr66en0SJQy/gpy2zWTCzh4yS4+GxbdWle4yP PU81hn/lZvWn+1qjOQrPKyyrEdgS4jktv4B7+EXXaak8QrHq57nySL48P G58AHb+N1So/qn59yCUgu1TEtDvvgJbJuAYle+zhVJ6pK8NKiTsTA4A3J jAKOGQJMOhtN3tG+NAeSMvrw/KxmoiyNLZ/KsK31w3NrqMhvCMhmpVTl+ vg9HTmGdegFwcHTiqFo7d7mr1ZnAsi6S5HFIZ/g8TnhRAQSvkD7cL+oLr g==;
IronPort-SDR: TVLKW5C1tjK/m5NTXum1SIebIsoEgXUeM33AAl/wQ4vf+GK28MXSLghECwnQ4c4DBPxP+dK/TN MM/CwxzXujDCMEW9Hz2wiyEsnEDZ7or7gmldiKLEpz1dVAG/j+7JQ0XC8R8LBFfylZM1ha8/Un VWMAiyj8Lkn1BHCOp2fOFiv8YllLVHshmw+KaiINN+eScOO5Q5K1sXc4b4xhUe1397PRBGLTZJ gecOLkzEGPIznz6vBp74Bxm7IRT66ytLXNSUrWrNvt2eyYUOORywe44mBE1yXjqs6fLOm/NEoC 0SY=
X-IronPort-AV: E=Sophos;i="5.78,353,1599537600"; d="scan'208";a="3808449"
IronPort-PHdr: =?us-ascii?q?9a23=3A8agYjBTR3dIsu9dz4oAUg6Phktpsv+yvbD5Q0Y?= =?us-ascii?q?Iujvd0So/mwa6zbBSN2/xhgRfzUJnB7Loc0qyK6v+mADdfqsnR+Fk5M7V0Hy?= =?us-ascii?q?cfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFR?= =?us-ascii?q?rwLxd6KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAi0oAnLq8Ubj4lvJqkzxx?= =?us-ascii?q?bKv3BFZ/lYyWR0KFyJgh3y/N2w/Jlt8yRRv/Iu6ctNWrjkcqo7ULJVEi0oP3?= =?us-ascii?q?g668P3uxbDSxCP5mYHXWUNjhVIGQnF4wrkUZr3ryD3q/By2CiePc3xULA0RT?= =?us-ascii?q?Gv5LplRRP0lCsKMSMy/WfKgcJyka1bugqsqRxhzYDJfIGbOvlwfq3fctMbWW?= =?us-ascii?q?VPUcleWjddAoynbYsDE/YNMfpaooT7ulAArQG+BQ6pBO73xDNGhHj23ak+0+?= =?us-ascii?q?s/FwHJxxIvEM4NsHjMsd77KbsdUeepzKnUwznIcvRb2Sz96IjPdhAhpe+DXb?= =?us-ascii?q?RrfsXP1UYvFBjIjkuOpoz/PjOVzeUNs2ed7+Z6Se2vjGsnphh3rzOyycgilp?= =?us-ascii?q?PHiZgJylDY6yp52oA1KMW3RkNnfdOoDYdduS6HOodrTM4vX25ltSQmx7AYpZ?= =?us-ascii?q?K3YSkHxIonyRPQZPKLbYqF7g/9WeuMLjp2hHNodbyhihuz90Wr1+7yVtGs3V?= =?us-ascii?q?pXsiZJiMTAu3ID2hDJ98SKSvVw8l2u1DuMzwzf9/1ILVopmafZN5It2KM8m5?= =?us-ascii?q?UQvEjZAyP7m0P7h7KMeEo+4Oin8eHnb63jpp+bKoB7lBnzMr8rmsyjGeQ4NR?= =?us-ascii?q?UOX3SD9eS8yrLj+Ur5Ta1Xg/MqiqfVrZDVK9wUqKG4HwNZz5wv6wijADehyt?= =?us-ascii?q?QYhWMLI0hYdx6dkYjpIUrOIPbiAfijhFSslS9nx/HAPrL/HpXANmXPnKv7cb?= =?us-ascii?q?pg6UNRxhA/wc1f6p9aEL0ML/H+Vlf0tNPCDx85NwK0w/zgCNV4zo4eQmKPAq?= =?us-ascii?q?idMKPWr1CI4PkgLPeQa48Wozv9NeYq5+TvjX8imF8dcq+p0YELZ3C/G/RqO1?= =?us-ascii?q?+Zbmb0gtcdDWcKuRIzQunuiFKYTD5TfGy+UaUm6TE/D4KmF4HDR4C2jbyC2i?= =?us-ascii?q?e7H4VWZnhcBl+RD3jib5+EVOsUaCKOPs9hlSQJVaK/RI8uyx6vuxP6xqFmLu?= =?us-ascii?q?XK5i0Yu4jv1N9v5+3cxlkO8mk+LMCUznrLamhwmXkOVhc12qFnuQpxxx3LhY?= =?us-ascii?q?t8iuFDU/la4/RTVBYSNpjd1/Q8B92kCSzbedLcAnahRtGrBzs8RdF1i+QFZF?= =?us-ascii?q?phUZ32lRDE2y6nBbUYnL+jGpEu87nd0H63LMF4nSWVnJI9hkUrF5McfVatgb?= =?us-ascii?q?RyolDe?=
X-IPAS-Result: =?us-ascii?q?A2EhBQDllbZf/zCZrQpigQmGIwqEM5EplQCFRYFoCwEBA?= =?us-ascii?q?QEBAQEBAQgBLwQBAYRKAheCFCY4EwIDAQELAQEBBQEBAQEBBgMBAQEChk8Lg?= =?us-ascii?q?jcig3YBAQEBAyMRRQwEAgEIEQQBAQMCEgETAgICMBUICAIEDgUItEQ8doEyh?= =?us-ascii?q?VeEc4EOKoZphnKBQj6EIz6DfwoBEQIBJxAjDgKCTYJfBJNopEwDB4JtlHiGG?= =?us-ascii?q?SuDGp5ik1SCAZoXhEECBAIEBQIVgWuBC3BwUIJpUBcCDZxodDcCBgEJAQEDC?= =?us-ascii?q?YwED4EkgREBAQ?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 19 Nov 2020 11:00:28 -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; Thu, 19 Nov 2020 11:00:28 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "Klaus.Malorny@knipp.de" <Klaus.Malorny@knipp.de>
CC: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
Thread-Index: AQHWvoeQbu7Hy8AiLUqOvn9i07++wqnPnHvg
Date: Thu, 19 Nov 2020 16:00:27 +0000
Message-ID: <cd21af55e5b74551a42573563e8aac09@verisign.com>
References: <a1d3bd0c2dce4b1c9c7a0355be22e9b5@verisign.com> <15dc0fa3-82a3-e031-5dd9-54371b99cf13@knipp.de>
In-Reply-To: <15dc0fa3-82a3-e031-5dd9-54371b99cf13@knipp.de>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/4-U_kDGeOEYDob4E6ID-Sc4fBdI>
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: Thu, 19 Nov 2020 16:00:39 -0000

> -----Original Message-----
> From: Klaus Malorny <Klaus.Malorny@knipp.de>
> Sent: Thursday, November 19, 2020 10:21 AM
> To: Hollenbeck, Scott <shollenbeck@verisign.com>
> Cc: 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.
>
> Hi Scott et al.,
>
> sorry for proposing the following so late in the discussion. Due to other
> duties, my visits to the list were less frequent in the recent time. Looking at
> the two options - update of RFC 5733 or an extension -, I probably would
> tend to the first option, but I understand the problems with it.
>
> What I regard as suboptimal in respect to the proposed EPP extension [1] is
> the big effort for the little issue (RFC-wise and implementation-wise), and
> also using this dummy placeholder [EAI-DUMMY] in the original <email> XML
> element (while I know that this has been done before). For a non-supporting
> registrar the latter is probably similarly confusing as an updated RFC 5733.
> Well, you could argue that the registry can distinguish supporting and non-
> supporting clients upon extensions specified at the login and behave
> differently. And here comes my proposal:
>
> As the original email XML element could transport the internationalized e-
> mail address XML schema-wise, as mentioned before, why not reduce the
> whole extension to a single extension URI without any real EPP extension in
> the <extension> section? No schema, no extra data. The presence in the
> login would simply indicate: "yes, I can deal with internationalized e-mail
> addresses in the <email> element in the contact object", like a flag. Well, I
> know that would be a novel way of using extensions, but it would reduce the
> implementation effort a lot on the other hand.

It could certainly be done that way, Klaus. An extension doesn’t have to require a lot of overhead if there's a simpler way to make it work.

Scott