Re: [regext] Internationalized Email Addresses and EPP

"Gould, James" <jgould@verisign.com> Thu, 19 November 2020 15:37 UTC

Return-Path: <jgould@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 923143A0E74 for <regext@ietfa.amsl.com>; Thu, 19 Nov 2020 07:37:27 -0800 (PST)
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 vV0g68WLQVI0 for <regext@ietfa.amsl.com>; Thu, 19 Nov 2020 07:37:25 -0800 (PST)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.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 424563A0DC9 for <regext@ietf.org>; Thu, 19 Nov 2020 07:37:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=28583; q=dns/txt; s=VRSN; t=1605800236; h=from:to:cc:subject:date:message-id:mime-version; bh=iRiuBz3kFVWwquoN+uOc5l4psVsRuUi02moUbiiZtfg=; b=Gj+XezX/8rdYC/6+Ya4rf9EBD3QWra9PmNtWxBAbMbSp7gp/tk0lju4p XzMWfEkZf/Q3wbzbvtvuMcuZtBTm8q7dRlfjstV8VUbe1IQublCo5rfy0 U4Z0abwiT3fumM+OsDzHjsKjfLNgDGN1AMKah7GRvjzAtTA7fYHKTGQ/b OIq5HDqitOUUyHyy5NqTlhkZ95pHgI5nfNrht33vXLXYuQN0GIe9gDb0a mtzvexnvaZ7OUxlpI52H/mjjl6lp7nUZiuj8I2jWE+HDQhHx8PKwDm5x+ aF0WElZelJ6Pq52EtcSs+9HAN8tTHpy6E6d/J3EXL3uu2+zOGogXfvME+ w==;
IronPort-SDR: tFrmh65HAcBklYPWbtOVW1fg4zQb6JrVdYmyJEpaM6LpPyIlpEJwOwcem7fuKKnOl0pv6UHKUh ZNa3hMLWoRdVgIgoXmCraCq8FzjVwGaXRWde7G0UD5AmODaVKCgZpUWlYS58SknuFCLu0Q91i7 3r7kGEAi2h3nhD8a7kGOvS1//DrCYzKxnMRgV27Bs6wzCElSXdqYpBQD8KI9gOm1P+aDE8BItp BTBwb4sByxhPDoN9sK1CxbP/oV3+YKadk5ACdnT5ssYa/mQO/BeKq8qNRsm4oqUeSCvt25lNai ORk=
X-IronPort-AV: E=Sophos;i="5.77,490,1596513600"; d="scan'208,217";a="3710907"
IronPort-PHdr: =?us-ascii?q?9a23=3AbdbuDhXTcYb3qXBdC2PDN0RDK1TV8LGtZVwlr6?= =?us-ascii?q?E/grcLSJyIuqrYZRaFuqdThVPEFb/W9+hDw7KP9fy5BipZusnK7ypKWacPfi?= =?us-ascii?q?dNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV?= =?us-ascii?q?3wOgVvO+v6BJPZgdip2OCu4Z3TZBhDiCagbb9oIxi6sAfcutMLjYZsKKs9xR?= =?us-ascii?q?nErmVVcOlK2G1kIk6ekQzh7cmq5p5j9CpQu/Ml98FeVKjxYro1Q79FAjk4Km?= =?us-ascii?q?45/MLkuwXNQguJ/XscT34ZkgFUDAjf7RH1RYn+vy3nvedgwiaaPMn2TbcpWT?= =?us-ascii?q?S+6qpgVRHlhDsbOzM/7WrajNF7gqBGrxK7vxFxw5DabpyJNPRwfa3Sc9IaSn?= =?us-ascii?q?ZOUctKTSNNHoa8YpETA+cbP+tVqZT2qVsUrRu5AAmhHO3jxD5Phn/r2a01zv?= =?us-ascii?q?wtGhzC0gM6GtIBrm/UoNvoP6oVU+C1w67IzSjHb/xLwjr99pbHcgogofGXXL?= =?us-ascii?q?JwfszRxVMzGAPCi1WdsIroNC6a2eoRqWaU9fZgVf6xhG49rQF8ujahy8gyh4?= =?us-ascii?q?THmo4Z10zI+ytnzIooOdG2R0F2bNy5HZVQtiyXNY97T98iTW9ntis3yL8LtY?= =?us-ascii?q?O4cSUE1JkqxADTZv6BfoOV7BzjU+ORLi15hHJjYL+/hgi98VSuyuHmUcm0yl?= =?us-ascii?q?lKojJEktbWsHACzQbf6s+dSvty5kuhxyiA1xrS6uFfIEA0mqzbK58nwrEsjJ?= =?us-ascii?q?YcrUPDHirulErqja+WbVkr+u+y5+v7ZbXmo5mRPJJ3hAHmKqkih9CzDf4lPg?= =?us-ascii?q?UMUWWX4/mw2b3t8EHjT7hHiuU6nrTFvJzAOMgWpLK1DxVI3oss6BuzFSqq3d?= =?us-ascii?q?cekHIaNlxKYgiHgJLsO1zWJfD4CuqwjEq0nTdwwvDGIqXhApLQLnjfiLvhfa?= =?us-ascii?q?hy60pbyAcr0N1R+4paBqwBL/zrVUH+tcDUAgEjPwyq3+nnD8991psEVW2VH6?= =?us-ascii?q?CVKr3SsUWT5uIpOeWDeIgVuDPlJ/gk4f7hk2M5lEcAcaW1x5cbdXK1E/p8L0?= =?us-ascii?q?mEYXfhjM0NHGgOswYmSezlklyCUTpdZ3aoWKI84yk2CICpDYfEW4CthKGO0T?= =?us-ascii?q?ylHpJIfGBGC0uMEXbnd4WCQfsDdCWSIsp5njweSbehU5Mh1Q2ptALizrRnKv?= =?us-ascii?q?Db+jADtZ7509Z6/enTlRYo9TxyD8WQyGKNT2d1nmMQXz86xr1wrlJlwFeZza?= =?us-ascii?q?d4m+BYFcBU5/5RSQc6NZncz+h+C9/sXALOZcmGR0qlQti+Djw9UswxzMEUY0?= =?us-ascii?q?Z8ANWijx/D3yywD7AJkLyLAYc5/b/Z33frPcZy12zK1Kg/gFk6TMtDL2qmhr?= =?us-ascii?q?Rw9wLLHY7Gj12Zl7q2daQbxCPN7nmMzWWQs0BXTA59SqTFUm4DZkvYt9j54V?= =?us-ascii?q?nCT7D9QYggZ0FizcefMe1vY9nul1NXbPTlOczGJW680S/kJhKB26jKSYPufH?= =?us-ascii?q?8bzQ3eDkkci0Yf8CDCfUIlBiClp2/YBjFlFgezO13h6+hlqXy9CEQzyimGak?= =?us-ascii?q?R73Py09wIbw/uGRLlbiqkEvyMlpjN+EV2+io6OFdeaphFgc6MaatQ4yFtC3H?= =?us-ascii?q?jS8Q1wIpLmKLpt0A0waQNy6gnB0AhzBsEIs8EvoWhghF5wJqWF1F9paT6C3I?= =?us-ascii?q?vxNbuRIW73qkP8I5XK003ThY7FspwE7+41/g3u?=
X-IPAS-Result: =?us-ascii?q?A2FvBQDIkLZf/zGZrQpfA4N7UoEpgTYKhDOVJJEEhUWBL?= =?us-ascii?q?BYmCwEBAQEBAQEBAQgBExAMBAEBAoRIGYIUJjgTAgMBAQsBAQEFAQEBAQEGA?= =?us-ascii?q?wEBAQKGIQcmDII3Ins9DT0BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEFAggHIxEZByMSEiAGI0sLEgEILgEJCgIEMCcEAQ0FgyYBgX6BF?= =?us-ascii?q?69KgTKEQgKGCYE4hmmGcoFCPoE4HIJPPoJdAQEDgScBEgEtCwodCQECgk0zg?= =?us-ascii?q?iwEk2iHHowPkR8DB4JtiRKLZoYlH4MagSqdOJNUggGHCRKBZZEXhEECBAIEB?= =?us-ascii?q?QIVgWuBC3BwFTsqAYI+CUcXAg2EBI4MhRSFRHQCDCYDAgYBCQEBAwmMBA+BJ?= =?us-ascii?q?IERAQE?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) 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; Thu, 19 Nov 2020 10:37:13 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2106.002; Thu, 19 Nov 2020 10:37:13 -0500
From: "Gould, James" <jgould@verisign.com>
To: "Klaus.Malorny@knipp.de" <Klaus.Malorny@knipp.de>, "shollenbeck=40verisign.com@dmarc.ietf.org" <shollenbeck=40verisign.com@dmarc.ietf.org>
CC: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: Re: [regext] Internationalized Email Addresses and EPP
Thread-Index: AQHWvonZexwqtXirWE2oFBnYkTlU8g==
Date: Thu, 19 Nov 2020 15:37:12 +0000
Message-ID: <C9EBEF19-55C1-4C5E-87BC-894FBF7439FF@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_C9EBEF1955C14C5E87BC894FBF7439FFverisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/cqyh3mmu3sqiC3VDw3i3cprq1zk>
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 15:37:34 -0000

Klaus,



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:



  1.  Placeholder Text and a New Email Element – This matches https://tools.ietf.org/html/draft-belyavskiy-epp-eai-01 that includes the use of placeholder text and an extra email element in an extension.  This would include the namespace URI in the greeting and login services like any other EPP extension.
  2.  Implicit Replacement Based on Login Services – Inclusion of the namespace URI in the greeting and login services indicate support for EAI addresses implicitly.  This would be treated similar to an EPP extension with the namespace URI in the greeting and login services.
  3.  Replacement Marker Element – Use of an empty marker extension as an implicit indication of support for EAI addresses on a per object-level (e.g., contact, organization, or other EPP objects). This would include the namespace URI in the greeting and login services like any other EPP extension.



It sounds like you’re proposing the use of the second option.  I believe that inclusion in only the greeting and logic services is too course grain, since the registry systems can support many TLDs and many EPP objects, each with different levels of support for EAI addresses.  Option 3 would be a lighter weight method that is an object-level indicator and option 1 would be the most explicit to indicate which email element is replaced by use of the placeholder text with the extension email element.  The use of email addresses apply to multiple EPP RFCs (RFC 5733, RFC 8543) and to at least one non-RFC EPP extension registered in the EPP Extension Registry (https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml).



--



JG







James Gould

Fellow Engineer

jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>



On 11/19/20, 10:20 AM, "regext on behalf of Klaus Malorny" <regext-bounces@ietf.org on behalf of Klaus.Malorny@knipp.de> wrote:



    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.



    Regards,



    Klaus





    [1] https://secure-web.cisco.com/1eSK9wecykl6SY5-nP9QWJmD_sBwN8xHmPwuhDy8P3qDoWGHFh3iYxpmxiQD_0tS1Q-mhyLJrye0W5StyBEhY2CZvkE2rz4hhNpzrfPQxdzkBb1z_M20VSrzr7izEilx_FsSNF6TuH1KfLrS1gQTy7UxsWP1xigU9dFe0uNekRDUvf0t3LA7gJRJSpMxwY7Q9HtwoKUh7fjcU7kWcGDFwn7BwOoEUQx-TvJrPD19EgQ0UVHcR7B9uv08-yXwrkoJWIdKhq2Y-8egnR0IeB80JDdiJPpcFpoo-QxrbEbU08NM/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-belyavskiy-epp-eai-01



    _______________________________________________

    regext mailing list

    regext@ietf.org

    https://secure-web.cisco.com/1-niXPoyAQkNoqJO8euNQWKTc_FepY-88-sGPEYrl-ABochx3Hcq8aIDVMq3yh3qLEXtK4ajzPX_fUs8dvbs4A0g10dcHmvMhRAl2ecqw5ABa4zveZ4GvM0ApXz0sQ_rjCSnE0CD4dbEQB8hDm-rjnCw4QbkocFxym1WTF8tMXrx6DqaS4lfO078yBWxAXcILxZQh0xj7MYFbWYeBodcIe6J3VpzTtOTGWVci2OW96aAxL3aiQP-Lx1EWkAstSEonN0QoW9rGTWmDs2UPyB-TVHx70HQY-ARUvTXaUHG6bvo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext