Re: [regext] Internationalized Email Addresses and EPP

"Gould, James" <jgould@verisign.com> Thu, 19 November 2020 18:14 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 4C9973A0ECA for <regext@ietfa.amsl.com>; Thu, 19 Nov 2020 10:14:34 -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=unavailable 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 MYZTBL7y44Kt for <regext@ietfa.amsl.com>; Thu, 19 Nov 2020 10:14:32 -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 8F6543A0B10 for <regext@ietf.org>; Thu, 19 Nov 2020 10:14:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=5916; q=dns/txt; s=VRSN; t=1605809673; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=0/vgwNekYY7gVmteyW6G/Wsz51eU8kezFKTW97KH4Fs=; b=B2qZO5NDP2ZS3qcGh4dJD1ZndcDi7EUF65npNQz9JU59cNGo4I3UKjzI 0ObpWLwc5Coiqd+z17/eI9tpYEAiBUhKMitE2Fd3xx50X7o+5CiM3nZbP ZC54y6GDY9IuoHUUgqpTDhx/OivUVe/Ap0hVmrsPkNS+LFcRyg3mgBJf6 W/tdyG3hyPvH/4zPAx4la3XAmvBV3n7iYN2EcT25Z/JxPoMK4Bb1W3yXX LR4XNUCU1eUwTkjZkrtkTmr7kt+xAhW4V+y6JT/ElomiomJq77O9MrmQ7 vg3i8e85zsktyFwl6h08olu8HtbCVj+T5HIpw/I9Erq/Y19v8x7fPGqs6 Q==;
IronPort-SDR: mYc7U+sURFtBZFVuC9zraXOmV3O+34mGyVHC6Gl1Rjjr1PRbey1WmMx2bOGmPVdEFhPfrhJD1G EXDYSexqdfA0aLMxx2It/TzSFLdVFWx//J9VrKfFi54858w6j6rm+AaBnx0FuuK30O8vh2EEjq L7UKyLIQ7wcQg5MYDfHfxW8qHu6VZKg/CTIpwAE2ND2niHGnQv4/fmAs5PDIJOsJMHX+hhrBrr TceAK1dNb7vWp8SkWFE89j6clu/BKDL7HI2j6SEJN8IB6pb0D+dG8z0gSx31wadA0Nuxc7NZnh uXg=
X-IronPort-AV: E=Sophos;i="5.78,354,1599537600"; d="scan'208";a="3811643"
IronPort-PHdr: =?us-ascii?q?9a23=3ASfUc/hBjj8xjIivGLOHDUyQJP3N1i/DPJgcQr6?= =?us-ascii?q?AfoPdwSP35psiwAkXT6L1XgUPTWs2DsrQY0rWQ6vu/EjVYsd6oizMrSNR0TR?= =?us-ascii?q?gLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ?= =?us-ascii?q?/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vLhi6txjdu8cUjIdtN6o91h?= =?us-ascii?q?jEqWZUdupLwm9lOUidlAvm6Meq+55j/SVQu/Y/+MNFTK73Yac2Q6FGATo/K2?= =?us-ascii?q?w669HluhfFTQuU+3sTSX4WnQZSAwjE9x71QJH8uTbnu+Vn2SmaOcr2Ta0oWT?= =?us-ascii?q?mn8qxmRgPkhDsBOjUk9mzcl85+g79BoB+5pxJx3ZPaYJ2bOvR9cKzdfM8VS2?= =?us-ascii?q?VOUctKSyxOGYa8Y5cTA+cbP+tVqZT2qVsUrRu5AAmhHO3jxD5Phn/r2a01zv?= =?us-ascii?q?wtGhzC0gM6GtIBrm/UoNvoP6oVU+C1w67IzSjHb/xLwjr99pbHcgogofGXXL?= =?us-ascii?q?JwfszRxVMzGAPCi1WdsIroNC6a2eoRqWaU9fZgVf6xhG49rQF8uiWjy9sxh4?= =?us-ascii?q?TIm48bxF/J+Dh9zYs2JNC2R0B2bcKrHpZMty+XOIp7Tt8iTmxrpis3xbMItI?= =?us-ascii?q?KncCQWxpoqxh3SZv2BfoOV7BzjU+ORLi15hHJjYL+/mQi98VKhyu3nV8m031?= =?us-ascii?q?BKritDktbQrHwCyxvT6s2fRvRh/0ehwiqA1wfJ5u5YJkA0kLLXK587zb42jJ?= =?us-ascii?q?Ufq0PDHjX5mEjwkaSYdV0k9/C15+j7eLnqu52ROoFuhg3jMqkjlNazDOs8Pw?= =?us-ascii?q?QWQmSX5f6w2KDh8EHlWrlGk/I7n6rDvJzHJskWoLOyDRVP3YY58Rm/Ci+r0N?= =?us-ascii?q?EfnXYaMl1IYAmHj431O1HWJ/D4EOu/j0yskDh1w/DGOaXsD4jRIHbbjbvufa?= =?us-ascii?q?5z5UFdxwYv09xT/YxUBa0GIPLpQk/9rsbXAQIjPwyq2ebnE9N92pkCVmKIB6?= =?us-ascii?q?+VKKLSsVmW6eIzO+SAeZMZtCzgJ/Un6fPil2I1lF8TcKWz0pYabGi0HvF8LE?= =?us-ascii?q?WYZXrsjM0BEWAPvgcmTuzqh1qCUSNXZ3mvRK88+C80CJinDYfYR4Ctj7qB0D?= =?us-ascii?q?2nEZ1RY2BKEkqMHmvwd4WYR/cMbzqfLMplkjMeSLihUJUt2xa0uw/+zLpnNO?= =?us-ascii?q?zU+y0DuJLg0th15vXTlQko+TNpEcuXy3uNQH1snmMUWz8227hyoVd9yleE1a?= =?us-ascii?q?h4h+JXFdpI6PxXTgg6NobRwuNmB9DsRA3BZNaJSE2nQtWpBzE9VM4+w9gLY0?= =?us-ascii?q?tmBtqiiwrM3zC2DLMPlryEGoA08qzG03j2PcZ9xG7M1LM9gFk+XstPKWqmi7?= =?us-ascii?q?Zl9wfNCI7GjUqYl7qxeKQdwiHN6GmDwXCJvEFCXw4jGZnCCDo8YkLLtpLc70?= =?us-ascii?q?fFVbm/IbchMxNZj8KPYOMeSdngkE4AYf7nP87YckqynWaoHVCEy+XIJMDxe2?= =?us-ascii?q?IZ2CjbAkUPkFVPpWiLLwklByin5WnZCRRiEFv1aAXt/PVw7nShQQV8mxqKaE?= =?us-ascii?q?ll2ry/9xUW0KDEVf4J36kFtyFnoDJxNFq41sjdTduNuwQne79TN4AT+lBCgC?= =?us-ascii?q?j2sBF5MtjoDalni0VUO1B1sETz0xlfFIhakNMro3Vsxw13f/HLmGhdfi+ViM?= =?us-ascii?q?ijcobcLXP/qUii?=
X-IPAS-Result: =?us-ascii?q?A2FxBQCPtbZf/zGZrQpfA4EJg0SBKYE2CoQzkSmDfJEEh?= =?us-ascii?q?UWBLDwLAQEBAQEBAQEBCAEfEAQBAQKESBmCFCY4EwIDAQELAQEBBQEBAQEBB?= =?us-ascii?q?gMBAQEChiEBBiYMgjciez0NPQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQUCCAdNB0cBHgEBAgIBIxFFEgEIGAICEgETAgQwFRIEAQkEB?= =?us-ascii?q?YMmAYJmrxd2gTKKU4EOKoZphnKBQj6BESccgVF+PoQJARIBBwIYDAsKGQ0BA?= =?us-ascii?q?oJNM4IsBJNokniQR4ENAweCbYkSi2aGJR+DGoEqihqHL4tvk1SCAYcJEoFll?= =?us-ascii?q?VgCBAIEBQIVgWuBC3BwFWUBgj4JRxcCDYQEgjuHbBeDTopYdA4mAwIGAQkBA?= =?us-ascii?q?QMJjAQPgSQyXwEB?=
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 13:14:30 -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 13:14:30 -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: AQHWvp/TexwqtXirWE2oFBnYkTlU8g==
Date: Thu, 19 Nov 2020 18:14:30 +0000
Message-ID: <AB832A1D-083B-40E4-9F45-B03DB7452B70@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: text/plain; charset="utf-8"
Content-ID: <5952D4B5EFBCEA489ACD94F75A20C5E7@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/3buP_xfABpO9DpOaLWm7ect62Ss>
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 18:14:34 -0000

Klaus,

The EAI support goes beyond RFC 5733 and is a perfect example of the use of the extensibility built into EPP.  Revising the RFCs and EPP extensions that use email addresses for EAI with new XML namespaces and potentially other changes is much more impactful than creating an EPP extension that specifically addresses the issue with applicability across any EPP object.  I was involved with revising RFC 4310 to RFC 5910, which was needed to address significant implementation issues with RFC 4310, so I see it as a different use case.  The intent is to make the EPP extension as lightweight as possible, to apply across multiple EPP objects, and to include an appropriate level of signaling (e.g., session-level, object-level, element-level).  Any feedback is welcome.     

Thanks,

-- 
 
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, 11:56 AM, "Klaus Malorny" <Klaus.Malorny@knipp.de> wrote:


    On 19.11.20 16:37, Gould, James wrote:
    > Klaus,
    > 
    > [...]

    >  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.
    > [...]

    > 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://secure-web.cisco.com/10F-1HgkEVNjFP0QgeBKhNA6sGTSD5RdZNJB4QHkoLDH8IHBYRs1ltUZiJPQNpihXZRKqZnlZfft8YypQmOjFdKnT6xD8VWe0qoyaI66wv8KLgW6NwVw9yKxur_9mPHqImn2NdED0DulgXSONcHFsSXPwjOjo3dhdmXS99AEu06iPQ5SdWh4mxRpqQezq22KmHdnz6i3MjgIFVSjk61bkmmkGv4OfN2faHghwaNVLCO1PszPa1O3Xv8qnay5A_HfRelkpzXwgtVWks1yBkwNPtw/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fepp-extensions%2Fepp-extensions.xhtml).
    > 

    Hi James,

    you are right, my proposal matches option 2. I didn't know that this was 
    discussed already. In respect to option 3 I really think that if EAI 
    support shall be specific to object types then it would be better to 
    release updated specifications of these objects, maybe with new URIs if 
    necessary. This would be my general preference, as I noted in my 
    previous e-mail.

    Having extensions that influence the interpretation of certain elements 
    in objects or other extensions has the problem that it increases the 
    complexity over time, makes it less understandable and makes it more 
    difficult to get rid of old stuff. The DNSSEC extensions (1.0 and 1.1) 
    are a good counter example for how it should work. I guess that nowadays 
    no active EPP server or client is unable to use version 1.1, thus 1.0 
    support could be theoretically removed from the implementations.

    Maybe one could find additional improvements to the contact object to 
    justify an update. For example, fixing the disclosure settings. While 
    their use have become questionable in the context of data protection 
    regulations like the GDPR anyway, they have the slight design problem 
    that one cannot set and remove specific disclosure settings at the same 
    time. Or one could consider to add a language field, which could be 
    helpful when sending e-mails to registrants, e.g. WDRP e-mails, transfer 
    related e-mails. Maybe there are other aspects with which registrars, 
    resellers and end users are unhappy.

    Regards,

    Klaus