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

Dmitry Belyavsky <beldmit@gmail.com> Mon, 12 October 2020 12:23 UTC

Return-Path: <beldmit@gmail.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 709EA3A148D for <regext@ietfa.amsl.com>; Mon, 12 Oct 2020 05:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, FREEMAIL_FROM=0.001, 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=gmail.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 9qwdAvVLI6Zp for <regext@ietfa.amsl.com>; Mon, 12 Oct 2020 05:23:55 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BF53A1468 for <regext@ietf.org>; Mon, 12 Oct 2020 05:23:54 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id u8so22928706ejg.1 for <regext@ietf.org>; Mon, 12 Oct 2020 05:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i/aGbBGOXn1gkTOyCfb5EYqsh39Gr96fmqDq1VfFGX8=; b=DMAQ5BF3YJG1EnW1iGpuib+7KJ1t8623MskNjYq55Qsj8QNyW04epbj4hL7qrWxJD/ S9SywdTwVwucCMrJmB1C5GQ6/R15iwlYoqPxqv0ZwnZ01hrvv1gSqg8WWOZ49Uxbk5Wh Vy/fUN3BB3riYwxAX3dxNfvXd9E2BDnvYsdpNhui00uhqsKOBhvmgwvbqC493bX36sS2 rgK3velvU0iThcRMiWPiuHHf/AD6Vis9gz0S0MG/XflG6RFbRcaHye+0d50hjGVuGHRJ cJylCKd04+iZi0n9VU/2zKNTSJFc+iY7/sZNSL9lftvgcwm8YZd4At0MWk7ZOyCHiKXt O+Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i/aGbBGOXn1gkTOyCfb5EYqsh39Gr96fmqDq1VfFGX8=; b=nVfMfpc0w1o+5khvqYjtShXq1HtVQSYmTeJR4TY+TQP0BKvmAHYh/SDtSND2PiysM9 UMiShoH/tGImox1ZxzKqa3xa/Q6uE1uXQZKld5XBYNJ5BBAeVK+9af3/5TjnyI6jz3IE K3eYXPgTwN+0TiDaza/3sijkQ7rTxPdL2pXDxdNA2hc1bVQYEozGL9LD6rmLkfnQJEfc QEFHjND64lya22zg0r5TZdxzeed/2K1RF6+a3Rvhm7Av4X+kMOwKBKLeqdwPLvH+gPeV 560wQGeW1qTwVR+U9ujcwOxVyNouNKKvknOVo1gluTDb9v/d4AagFNd+bNY6iCE3SAk2 6sWQ==
X-Gm-Message-State: AOAM531oW3j2+qKEiZSKDvZqRGrnaTDnRIGIsT8qZuencDxPWfanwnzp TexHn0rOv47mxDIWU3zls3dQjHGPtAF/P+TLROS6v4S/aIY=
X-Google-Smtp-Source: ABdhPJzrMqKxuTbL9lpuo2jZRVYkdEuB+XrlMSqgjDglzJcNJCO0NfF+7iQZyo2sxNssqIpX+UUIyYKrNCdasBCjmbY=
X-Received: by 2002:a17:906:2604:: with SMTP id h4mr26768209ejc.26.1602505433219; Mon, 12 Oct 2020 05:23:53 -0700 (PDT)
MIME-Version: 1.0
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> <542572b0e6284550a9bee035bea2d6bf@verisign.com>
In-Reply-To: <542572b0e6284550a9bee035bea2d6bf@verisign.com>
From: Dmitry Belyavsky <beldmit@gmail.com>
Date: Mon, 12 Oct 2020 15:23:42 +0300
Message-ID: <CADqLbzKow+VxaMAYu_vw4RXup+3FAMM7f5mRd60XU2AFi9Simg@mail.gmail.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: "Thomas.Corte@knipp.de" <Thomas.Corte@knipp.de>, "regext@ietf.org" <regext@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000190af405b1785f11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Sh6GlDtF7Izjt12aIa9juuGRqok>
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:24:05 -0000

Dear Scott,

On Mon, Oct 12, 2020 at 3:20 PM Hollenbeck, Scott <shollenbeck@verisign.com>
wrote:

> *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> 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*
>

I'm sure EPP itself will not. Do you think it's reasonable to indicate such
support via an extension or just leave it as a registry (internal) policy?

-- 
SY, Dmitry Belyavsky