Re: [regext] Internationalized Email Addresses and EPP
"Gould, James" <jgould@verisign.com> Mon, 23 November 2020 17:03 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 2F2093A0B0A for <regext@ietfa.amsl.com>; Mon, 23 Nov 2020 09:03:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 I3NjzBVA0CvR for <regext@ietfa.amsl.com>; Mon, 23 Nov 2020 09:03:07 -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 1A2713A0B04 for <regext@ietf.org>; Mon, 23 Nov 2020 09:03:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=6336; q=dns/txt; s=VRSN; t=1606150988; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2Dm4n90Os6KZXQA5MSMZbhmD+9KD7fdsbuywPLjdZRs=; b=nKyZiW42ofRKB4urUG/nJd+6svjdObaUAnoSqDvZ68k9afWGO3sv8+S6 eXd8QAz62Qu3J9HMe+cgRHCErJDrdLSNAAejOCvKw+VJK9Nq66EosYXNI 1mwtoSe9Ao3qcq50XdrbdTKsp4JelgPnzTTHc06UP74YausfHljpvDFVk 2+5eHBhl5dTpaHU982Zbghh1JEFc65DI4/Da5PwYc8Rdb1eHWZVy+Vdli ubezuA72Vd+vwmBWNj/LQHWXNdaKbFb09jXu8uojxaJPdSm1AVAk0GyUy +D4zI4gMzqF2LvXfsw3eCCu0CptJzLM9gZKIfEZxmTMrz2WeLwSBHdnLe Q==;
IronPort-SDR: 4RLxhMc/w8TCYei+tk9crInlG6Uwp3YuVc9MfhcK4QB4vq/j2+Apk4JhvjEsPoQdxVUMZkZLQu Op7sGrHkcQ6kzq/NokyAPZRzPEDdLUh/Z1H4xoS4EmDvOby6D7wmojomwbrt49j00/qFfqaZLQ WbySF4fQ6H4eCoXIldxgoOc4fC45hJq7ySOG7OaFd7fhFRmSngZkUxFGbxfknXKG+iy5KJK81S yfFaVFE97cq4/djxzo6fiU0L0qrFCB4FeHidHsb9C0JItI0JRcWY00GsSygLYn3j1CLjQhJ2Em 2Wo=
X-IronPort-AV: E=Sophos;i="5.78,363,1599537600"; d="scan'208";a="3772094"
IronPort-PHdr: 9a23:vpUjQxNHZyUVEOI17Hgl6mtUPXoX/o7sNwtQ0KIMzox0K/36osbcNUDSrc9gkEXOFd2Cra4d1KyP7/6rCDBIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+KPjrFY7OlcS30P2594HObwlSizexfLF/IA+roQjet8Qajo9vJ6kswRbVv3VEfPhby3l1LlyJhRb84cmw/J9n8ytOvv8q6tBNX6bncakmVLJUFDspPXw7683trhnDUBCA5mAAXWUMkxpHGBbK4RfnVZrsqCT6t+592C6HPc3qSL0/RDqv47t3RBLulSwKLCAy/n3JhcNsjaJbuBOhqAJ5w47Ie4GeKf5ycrrAcd8GWWZNW8BcXDFDDIyhdYsCF+oPM/hFoYnhqVUArhWxBQiwC+3gxTBFnWP20rY/0+g9DQ3Lxg4tEtQTu3rUttX1M6ISXPi7wKfJyjXDcvdW1irl5IPVdh4uu/SMUqxrccbf1EIiEAHFjlqXqYz4OzOay/8As3aF4Op6VOKvkG8nqw53ojS12sgsjYzJi5sTx1vZ+ip33Jw7KsekSE5nf9GkCp1QujmGOoZyTc0vQWVltSQmx7Eau5O1cisHxIooyRPQb/GJc4eG7xzhWeqNPzp1mG5odbaxiRqs70WtxO3yWtSq3FhKqCdOj9fCtncI1xPJ68iHTONw/lm/1jaV1gDT8eBEIU8ylaraLZ4u3qQ8mYYUsUTGGCL9hUb4jLeOe0k55uSk8fnrb7foq5OGKoN5ig/zPr4hl8G8Geg0LxQCU3KG9em+yLHv51D1TbpJg/Esj6XUs5bXLtkBqKGjGQ9ayIMj5g66DzehzdsXg2EKLElAeBKbl4jpPEzOIOzgAfe/nVuslDBryujbM7P9GpvBM3jMnq/uc7l890JQ1RA/zc5D6JJTELEBOOj/VVXsu9DCEB85KRe0w+D9BNph0YMeXHqDAq6fMKzMrV+F/v8jL/WWaIMIujvwJeIp6+PugHI3g1MQcqqk0YMSaH+iH/RmJ0uZYWDrgtcECWoKvAU+TOv3iF2GTDFefGiyULwm5jE6E4KmDIjDRoa3jLOd2ye7G4VaZnpaBVCUDXfoa4KEVu8WZyKWPMBgnSYIVb27RI4hzxGutAj6y7R5IerO4CEYtIzs1MR75+DImhEy8CZ7D8WZ022XU250mWYITScs3K9juUx91kuD0a9gjvJdEdxc/e5JUhwgOZDb1eN6D9fyWhjHftaJU1umQdOmATApTtIp2dMBflhyEc24jh/fxyqqH6MVl7uTCZwu7K3c0Gb+Jslhy3vd1akukUUmQsVVOW2hnK5/+FubO4mc2UydmrbscK0Nxi7K+mqZi2uDoE9wXwt5UKGDVncaLAOCpND09gXHRq60CbMpPxEHyMOeJINFb9ToiRNNQ/K1a/rEZGfk0Ui3GBKEgvuuZY/nYC9ViCfSD1UAnygN8GyHLgkxAGGqpGeIX28mLk7mf065qbo2k3i8VEJhiljSN0A=
X-IPAS-Result: A2EdBwBx6rtf/zCZrQpfAx0BATwBBQUBAgEJARWBUYFzgSmBNgqEM5EmgQWCd4YZimyFRYEsPAsBAQEBAQEBAQEIAR8QBAEBAoRIGYIWJjgTAgMBAQsBAQEFAQEBAQEGAwEBAQKGTgELgjcpAXM9DT0BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHTQdHAR8BBAEjEUUSAQgaAiYCBB8RFRIEDgUUgxIBglUDDrA+gTKIGA2CJIEOKgGGaIZygUI+gREnHIIaNT6CG0IEgSgBEgEJAhYMCwomglAzgiwEkDwGgyuKTJkAOFUDB4JuiROMeIUWH4MagSqdQZNcggGHCxKBZoJvkm0CBAIEBQIVgWuBC3BwFWUBgj4JRxcCDY4rF4NOilh0AgwmAwIGAQkBAQMJjAMBLYEGgREBAQ
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) 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; Mon, 23 Nov 2020 12:03:05 -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; Mon, 23 Nov 2020 12:03:05 -0500
From: "Gould, James" <jgould@verisign.com>
To: "alex.mayrhofer.ietf@gmail.com" <alex.mayrhofer.ietf@gmail.com>
CC: "Klaus.Malorny@knipp.de" <Klaus.Malorny@knipp.de>, "Hollenbeck, Scott" <shollenbeck@verisign.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: Re: [regext] Internationalized Email Addresses and EPP
Thread-Index: AQHWwbqC41T06dpeIUqqYAL26C2W5Q==
Date: Mon, 23 Nov 2020 17:03:05 +0000
Message-ID: <446CBF6F-8AE7-4C35-B590-8D2CE436DC7D@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: <24D29D1876A9FA4EA86DED1D547460D5@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/NPsLpaPVyr439q1Zhxssw-r5Rh4>
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 17:03:09 -0000
Alex, How to handle input EAI values (create or update) can result in an error (e.g., 2306) based on server policy independent of the use of the extension. The extension provides for signaling by the client of the EAI support, which enables the server to fast-fail when it's not allowed. The EPP extension options (session-level, object-level, element-level) provide different levels of fast-fail support, where the session-level really doesn't enable the server to fast-fail on a per-TLD, per-object, or per-element basis. The object-level and element-level options using the marker extension does enable for the server to fast-fail on create or update. What happens to old clients that don't support the EAI extension is an unhandled namespaces issue. Section 5 "Usage with General EPP Responses" of draft-ietf-regext-unhandled-namespaces defines an approach for a typical EPP extension (e.g., DNSSEC extension); although the question is what to do about the email element in the base object (e.g., return the EAI value, don't return the EAI if it's optional, return a placeholder value). The email element is required in RFC 5733, optional in RFC 8543, and can be either in non-RFC EPP extensions. What harm is there in returning an EAI value to a client that may not support it? It would not result in an XML parsing issue, but it could result in a processing issue, such as storage and use of value. Based on the potential for processing errors, I would choose to use to include an indication of the lack of EAI support using draft-ietf-regext-unhandled-namespaces, and I would not return the email element in the base object if it's optional and would be forced to use a pre-defined placeholder value in the base object if it's required. The pre-defined placeholder value should fast-fail as opposed to returning an EAI value that may result with non-deterministic results. I believe how to handle the email value in the base object is consistent with any of the EPP extension options (session-level, object-level, or element-level). The use of a placeholder value currently only applies to the element-level option, but may need to be defined for the session-level and object-level options for this use case. The server implementation considerations can be covered in the draft. 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/23/20, 1:04 AM, "Alexander Mayrhofer" <alex.mayrhofer.ietf@gmail.com> wrote: Jumping into this discussion quite late, but... On Thu, Nov 19, 2020 at 4:39 PM Gould, James <jgould=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. For example, what would an "old" client do that doesn't understand a potential EAI extension? Would they be deprived of email addresses completely, and receive non-sensical placeholders which they'd unwittingly hand over to their email system (even if that email system would perfectly understand EAIs?). Does sound like a failed opportunity to me! best, Alex
- [regext] Internationalized Email Addresses and EPP Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Barry Leiba
- Re: [regext] Internationalized Email Addresses an… Gould, James
- Re: [regext] Internationalized Email Addresses an… Dmitry Belyavsky
- Re: [regext] Internationalized Email Addresses an… Mario Loffredo
- Re: [regext] Internationalized Email Addresses an… Gould, James
- Re: [regext] Internationalized Email Addresses an… John Levine
- Re: [regext] Internationalized Email Addresses an… Gould, James
- Re: [regext] Internationalized Email Addresses an… John Levine
- Re: [regext] Internationalized Email Addresses an… Gould, James
- Re: [regext] Internationalized Email Addresses an… Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Dmitry Belyavsky
- Re: [regext] Internationalized Email Addresses an… Mario Loffredo
- Re: [regext] Internationalized Email Addresses an… Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Jiankang Yao
- Re: [regext] Internationalized Email Addresses an… Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Klaus Malorny
- Re: [regext] Internationalized Email Addresses an… Gould, James
- Re: [regext] Internationalized Email Addresses an… Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Klaus Malorny
- Re: [regext] Internationalized Email Addresses an… Gould, James
- Re: [regext] Internationalized Email Addresses an… Klaus Malorny
- Re: [regext] Internationalized Email Addresses an… Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Taras Heichenko
- Re: [regext] Internationalized Email Addresses an… Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Dmitry Belyavsky
- Re: [regext] Internationalized Email Addresses an… Mario Loffredo
- Re: [regext] Internationalized Email Addresses an… Alexander Mayrhofer
- Re: [regext] Internationalized Email Addresses an… Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Matthias Pfeifer
- Re: [regext] Internationalized Email Addresses an… Dmitry Belyavsky
- Re: [regext] Internationalized Email Addresses an… Gould, James
- Re: [regext] Internationalized Email Addresses an… Patrick Mevzek
- Re: [regext] Internationalized Email Addresses an… Taras Heichenko
- Re: [regext] Internationalized Email Addresses an… Patrick Mevzek
- Re: [regext] Internationalized Email Addresses an… Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Patrick Mevzek
- Re: [regext] Internationalized Email Addresses an… Patrick Mevzek
- Re: [regext] Internationalized Email Addresses an… John Levine
- Re: [regext] Internationalized Email Addresses an… Dmitry Belyavsky
- Re: [regext] Internationalized Email Addresses an… Taras Heichenko
- Re: [regext] Internationalized Email Addresses an… Patrick Mevzek
- Re: [regext] Internationalized Email Addresses an… Taras Heichenko
- Re: [regext] Internationalized Email Addresses an… Taras Heichenko
- Re: [regext] Internationalized Email Addresses an… Patrick Mevzek
- Re: [regext] Internationalized Email Addresses an… Taras Heichenko
- Re: [regext] Internationalized Email Addresses an… Patrick Mevzek
- Re: [regext] Internationalized Email Addresses an… Taras Heichenko
- Re: [regext] Internationalized Email Addresses an… Patrick Mevzek
- Re: [regext] Internationalized Email Addresses an… Hollenbeck, Scott
- Re: [regext] Internationalized Email Addresses an… Patrick Mevzek
- Re: [regext] Internationalized Email Addresses an… Taras Heichenko
- Re: [regext] Internationalized Email Addresses an… Taras Heichenko
- Re: [regext] Internationalized Email Addresses an… Gould, James