IETF Logo Mail Archive

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 12 October 2020 12:20 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 7AB953A146E for <regext@ietfa.amsl.com>; Mon, 12 Oct 2020 05:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTTPS_HTTP_MISMATCH=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 2Wu78eurnGi4 for <regext@ietfa.amsl.com>; Mon, 12 Oct 2020 05:20:50 -0700 (PDT)
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 13D0A3A1485 for <regext@ietf.org>; Mon, 12 Oct 2020 05:20:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=11796; q=dns/txt; s=VRSN; t=1602505250; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=BYEgFmSaPcM5ml4P28lpqnz6IvMNF2L3kPZ/MyxAXNU=; b=qgHw/Yt40I0MTTxmHZOFSpdOyHvp63O9MNK0ySkOg8/tN3Z5dlbDzs7/ p9cBP7bhczMe3lerSFNGQsC3u4v5au2pI/5E0DedODncN9W/PHlbGi6gb pS89irQvEvfYP9a0bmjbn3vcQBbNZ28Geoo8z7eGX9af03Ts6dtMAg1p8 k/z83URib/KGenw2q0rQcdvrWRb+79njUrjHGtgqo45vD7YitPZmUKhuR 0wDJsJ5rhARBw46KKRVfoOxnwH9KaBHgzWLmoYOlsEy5dL7cV58SYZSCv ygjz3qE1IFRk8hAgwjtYwooaRbYkiPHHSReEuc1yZWfW+ht45G7lSMuF4 Q==;
IronPort-SDR: xwYUdHefjwhVwNuUKpwy8um8EeB+VkX7lqQSQNftPvPSZMUWoakYJgf3kLGc/iinacuWo1/ee3 DDGdfSI6iYyV5dOrBPEi+M+XSxPjt9L0OTl5cDSp1YNjEqduFXzStHedawxDG1yiqhD9Obpnyn pAIxPdy1rfb9SfZ2PS+Qup64SYmWDOfsSgOSHJJzpH7xHtQ3EE77FcceZ9KAVUciFuoxh1PXm2 /9KZ9EL8XZ+KBeDVWqx4SAiRAs4fxoCKdrE1AWmAlElB1+iodrc8qhqlFfkd6MHUZQ/MIpetFP HyI=
X-IronPort-AV: E=Sophos;i="5.77,366,1596513600"; d="scan'208,217";a="3234684"
IronPort-PHdr: 9a23:Z5E3/BLJ1kOaBzbH39mcpTZWNBhigK39O0sv0rFitYgXK/39rarrMEGX3/hxlliBBdydt6sbzbeJ+PywEUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCe/bL9oLBi7rwrdu8YVjIB/Nqs/1xzFr2dSde9L321oP1WTnxj95se04pFu9jlbtuwi+cBdT6j0Zrw0QrNEAjsoNWA1/9DrugLYTQST/HscU34ZnQRODgPY8Rz1RJbxsi/9tupgxCmXOND9QL4oVTi+6apgVRnlgzoFOTEk6mHaksx+grxGrhK9qRJxwIDUb4OUNPVicazQZskVSXZDXstLSyBNHoGxYo0SBOQBJ+ZYqIz9qkMAoRW8AgmsAOfvxSFOhnDtw6I1z+chHRnb1wI9A90Ot2jUrMn7OKwPVu2116nIzTLHb/NSxzj97pPHfQ49rvGPRr9wb9TeyVMuFwPej1WQporlMymJ2eQKtmiW9uxtXv+ghGA7sQ9+uCSvxtsyhYnTgIIY0k7I+Tl2zYs6ONG1R0F2bMOqHZZTqSyXNpV7T8EsTW9npSs3y78LtJ2mcCQXxpoq2R7RZfOZf4WH/B7uV+mfLDl+iXl4dry/gBOy/lKhyu36TsS00UhFrjZLktXWsXANzRPT5tCbRft85UeuxTGP2xrP5eFDJEA5k7fQJZ05wrMoi5YfrV7PEjL0lUj4lqOaa0Up9+ay5+noYbjqvoKQO5Nuhg3jMKkihtazDfk3PwUNRWSX5Oex2bv+9kPjWrpKlOc5kqzBvZDfIsQUu7C2DhdO0oYm9xa/FzCm0MkEnXUfLFJKZhaHj4/xNlzTPP72FeqzjFS0njlkxv/KIqDtDo/TLnffl7fhZ65951RGxwUu19xf+YhUCqoHIP7pRkDxs9nYAgc4Mwyy3ennFM1w2p4CVW6VH6OUMq3fvUWV6u8vLeSAfoAYtTXlJ/gg/fHujHs5mVEHfamu2JsacGu4HvRhI0WdZXrjnNEBHnwUsQUiT+znk0OCXiBJZ3azRKI85z47CIS8AYjfQYCthaSN3D2nEZ1OemBGFleMHG/zeIqaX/cDdSeSIs59kjEfWrihTpUu1RCqtAPg17VnKe/U8DUCtZ3/zNh1+/HTlRYq+DJqD8Sd1GSNQHtvnm8SWTI227p/oVBjxVqY0qh4hf1YFcRL5/9TTwg1K4bWz/ZmBNDqRgLBYtCJRU68Qtq4DjE+UN0ww8MVbkZ8Bdqikh7D0zCtA78PmLzYTKAzp+jW0nz9Isdh43nD3aglyVIhR4EHYWergqJ69hT7CIvAkkHfnKGvI+BUlhLN82KK1iylu1tEXSZzV6TdRTYTawGe+ej54UbLVPmFDq47PyNCz8+aMu1GZ4u6o09BQaKpGNPaZ2+3kWq7BlLA/biLcJagMzEG3CLZDEUCmQ0Y/l6YOBI/HSaupSTVCzk4RgGnWF/l7eQr8CDzdUQz1QzfN0A=
X-IPAS-Result: A2ElBACGSYRf/zCZrQpgHQEBAQEJARIBBQUBgg+BI4F3gTQKhDOBXY88mj2BLD0LAQEBAQEBAQEBCAEiDQQBAQKESAIXggEmOBMCAwEBCwEBAQUBAQEBAQYDAQEBAoZFDII3Ins9CT0BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBAINNh43EgEBHQEBAQECASMKSgIFCwIBCBEEAQEoAwICAjAUCQgCBAENBQgXgwiBfl4vpi92gTKEOwGFeQaBOIVSEjpChnGBQj6DI34+glwBAQIBgSIFAQwGAR4RCR+CYYJgBJAvgxeHBp0UAweCaId/gQKRXyuDFZ4lkyKBe4h2kQSEMAIEAgQFAhWBa4ELcHCDOVAXAg2NfFqDOoUUhUJ0AgEBCSoCBgEJAQEDCYwDgTSBEQEB
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.1979.3; Mon, 12 Oct 2020 08:20:47 -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.1979.003; Mon, 12 Oct 2020 08:20:47 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "beldmit@gmail.com" <beldmit@gmail.com>, "Thomas.Corte@knipp.de" <Thomas.Corte@knipp.de>
CC: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt
Thread-Index: AQHWoI1zAxEPhW7h7k+u3/36GcJtFqmUI44A//++vJA=
Date: Mon, 12 Oct 2020 12:20:47 +0000
Message-ID: <542572b0e6284550a9bee035bea2d6bf@verisign.com>
References: <160241615917.22211.18203451406032701031@ietfa.amsl.com> <CADqLbzKL10v_=+_DRtXiOVMnLqUpz=xMgYKw+8StF+JGbirunw@mail.gmail.com> <7d09c6e4-9237-939a-3e50-047899c800a2@knipp.de> <CADqLbzJy5Eg+ybgtRA_T26HUpYkQh9b1u0w7o_P6P-eMs7bE=Q@mail.gmail.com>
In-Reply-To: <CADqLbzJy5Eg+ybgtRA_T26HUpYkQh9b1u0w7o_P6P-eMs7bE=Q@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_542572b0e6284550a9bee035bea2d6bfverisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/iKiPskwzjNHzSjJpcYnZOUWnIWI>
Subject: Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt
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, 12 Oct 2020 12:20:59 -0000

From: regext <regext-bounces@ietf.org> On Behalf Of Dmitry Belyavsky
Sent: Monday, October 12, 2020 8:11 AM
To: Thomas Corte (TANGO support) <Thomas.Corte@knipp.de>
Cc: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt



Well,



On Mon, Oct 12, 2020 at 2:47 PM Thomas Corte (TANGO support) <Thomas.Corte@knipp.de<mailto:Thomas.Corte@knipp.de>> wrote:

   Hello,

   On 10/11/20 13:39, Dmitry Belyavsky wrote:

   > Dear colleagues,
   >
   > Here is the updated version of the draft describing the usage of the
   > Internationalized Email Addresses (EAI) in the EPP protocol.
   > This version provides a specification to submit EAI to the registries via
   > the EPP protocol extension.
   >
   > Any feedback is welcomed!

   As James already pointed out, I'm not sure why the extension is even
   necessary to accomplish this on a purely technical (protocol) level.

   eppcom:minTokenType is based on xsd:token, which is based on
   xsd:normalizedString and adds whitespace collapsing. Unless that
   introduces a problem I'm not a aware of, none of this prevents the
   specification of internationalized e-mail addresses for contacts in EPP;
   in particular, it doesn't limit the available characters to ASCII.

   Many registries (like e.g. Neustar for .biz, or the TLDs run by our own
   TANGO system) already accept them right now. It would be silly to require
   them to use an extension to do the same in the future.



   If the registries work this way, it's great but it means they formally violate the EPP protocol.



   https://tools.ietf.org/html/rfc5733#section-2.6<https://secure-web.cisco.com/1hzu_WlPioMsUO-ycVN-zDMofl2fHO7fLFN8tmG0h1ua4fI7qT4zfOJ3Y4VH3VasUchmJp8BP_rL5zVbgz5Qjdgw93z2s0rn5IOSMAy_ZGBXuMk3s8B3BMGX0d8hicT9dyXOwlkRQnFmzwIgpA5BOd8sbnrlbrKbu8SEciN4EpA5mkN5hpMIjviWULHfq6XuWUUJrZz-20koRV6ebQtU1N9ikjlyYDg1KrqYVSBJlGWY4zva7EQYi3axiAgOibVz7qgLgS7n5UOVj0nDXOzZNApINoxoNmRQDb5ZujVAoo1c/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5733%23section-2.6> denotes:



      Email address syntax is defined in [RFC5322].  This mapping does not
      prescribe minimum or maximum lengths for character strings used to
      represent email addresses.



   EAI addresses do not fit the RFC 5322.



   The 1st version of the draft was basically replacing RFC 5322 to RFC 6530 :)



   [SAH] Perhaps there’s a case to be made for RFC 6530 being an update to RFC 5322. I’m going to see if I can run some tests to confirm it, but I, too, suspect that EPP as-is won’t have any issues with internationalized email addresses.



   Scott

v2.23.0 | Report a Bug | By Email