From nobody Sun Sep 18 07:08:40 2022 Return-Path: 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 0DE75C152580; Thu, 15 Sep 2022 07:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHSBI5uZcYCK; Thu, 15 Sep 2022 07:55:34 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4A1C1522CF; Thu, 15 Sep 2022 07:55:34 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id f14so29842961lfg.5; Thu, 15 Sep 2022 07:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date; bh=RSddMy4BbGtq9fh996EhRKxsjNVyKBAXQsDrMaM/+L8=; b=F0y3MteNXUnEqARVvWuZVSLW8DFsgQudMvBeqBOdFSGMkXBga7xDIq6Zn/0I5jT4Ay XIZfUXvrFwfRM3xbYa1zx8k+KaMtF3i6vSlvqfU6IO7ZsyJGmDg0I23EQFm3oanc0pI9 rOvk5PL3y04YGoSew6oQxGaEGy3pSb1Cr4zxijQUdm8bUEKd2F8YncwgIKs3QcVSSWsj May/MuuJsnpM85bQsJ4OLUIcAWq0Q+gr1Luhs1rcgg6I5ndabXJ5+LJ5CQViaF8pFWdB Lva0Hh9hRwUfTO4i1XT63fMwjwA9MGL1QdhgswyCCZ6AAHbMM5+nPj62sKYSXqT1qYZg PK2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=RSddMy4BbGtq9fh996EhRKxsjNVyKBAXQsDrMaM/+L8=; b=MDyxS/8KETBEqRuLMlZRAJS3eOFrwtyhrV/SKjHEWU21wne+Gi6rwmf9JQ3YUuSSPt dmDoLOfP4dUVBvGUtmhWWQ8L6LC0THdq+SMc/GOP0tAtpUQUHSNY/bcrD3ZO9QtIZ5zW yVOOMyfsexhIJYCIEstKPkK/LlY3RrRlNM7RFBoeIBTYuO3jrXmwDpU8oTra22BiBHAh VnQDh0WIVkH2CtYZxg1mqG8Q+XVwJMcFvwbP0J+ovCKc0WD/Y9H00Vvymhw2ZT3cC29s E9+qWZdkVR9FDYTaEVyOaOQh54m6HmPqa2tCz6rjS2QoQDrRTlLBkCTDxGVbdPMm3ELb qMaA== X-Gm-Message-State: ACrzQf0Ww/wbDLbcQgVm2NPzRmLgU4Ng6wzBKCcKjFsilrJBhl+tKIE2 0wwBozOKU/Hir4ClRzsvOrs= X-Google-Smtp-Source: AMsMyM6DONZOwkGzCV0/kLqnj4gBcl8MKKz04Cqk3QSLySkTSbb9bckyc3OixcKtw387L8ryPpd0bg== X-Received: by 2002:a05:6512:3182:b0:499:edbc:d23c with SMTP id i2-20020a056512318200b00499edbcd23cmr92964lfe.675.1663253732263; Thu, 15 Sep 2022 07:55:32 -0700 (PDT) Received: from imac.home.reedcat.net (broadband-77-37-187-88.ip.moscow.rt.ru. [77.37.187.88]) by smtp.gmail.com with ESMTPSA id v16-20020a05651203b000b00492ca820e15sm3002569lfp.270.2022.09.15.07.55.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Sep 2022 07:55:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: =?utf-8?B?0JLQsNGB0LjQu9C40Lkg0JTQvtC70LzQsNGC0L7Qsg==?= In-Reply-To: <4ACF0279061CC0B6C78E0E8C@PSB> Date: Thu, 15 Sep 2022 17:55:29 +0300 Cc: Dmitry Belyavsky , "Gould, James" , =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , art@ietf.org, draft-ietf-regext-epp-eai.all@ietf.org, last-call@ietf.org, regext , i18ndir@ietf.org, gen-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <566C585E-BE5B-4C5F-95D4-88C0DD6FDFCA@gmail.com> References: <1C6C85AAF7DA5EFEDCED0BB0@PSB> <4ACF0279061CC0B6C78E0E8C@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: X-Mailman-Approved-At: Sun, 18 Sep 2022 07:08:35 -0700 Subject: Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15) X-BeenThere: regext@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Registration Protocols Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2022 14:55:38 -0000 Hello! I understand your concern, that if this content in e-mail addresses = will be standardised, then at least for some period of time (very = lengthy one, indeed) some =C2=ABunreachable=C2=BB address domain could be created. at least = for some time, while all MUAs will be upgraded. from the other side, if this will not be standardised - there will never = be move forward in technology. I think, that the proper way forward is to standardise new, extended = approach, whereas note that these addresses could not be for some time=20= be globally accessible (until software refreshment cycle will occur) and = should be used for official and/or critical purposes with caution. HTH. dol@ > 14 =D1=81=D0=B5=D0=BD=D1=82. 2022 =D0=B3., =D0=B2 04:13, John C = Klensin =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0= =B0): >=20 >=20 >=20 > --On Tuesday, September 13, 2022 22:17 +0200 Dmitry Belyavsky > wrote: >=20 >> Dear John, >> Thank you for your clarification! >>=20 >> Let me explain my understanding. >=20 >> First, SMTPUTF8 MUAs already exist. >=20 > But are typically limited to a relative handful (compared to the > total) of scripts. See below >=20 >> Second, if the registry provides this support, it implies that >> it can deal with such addresses. >=20 > To take an really extreme example, I think it would be seriously > dumb for a registrar to allow an email address with the local > part consisting of the Unicode code points, U+1F438 U+200D > U+1F445 U+1F438 [1]. It might be bad news for a registry to > access such an address. I can't even guess how many of those > SMTPUTF8 MUAs would render that in a reasonable way, much less > allow users to type it without Unicode escapes. Similar > comments might apply to one consisting of U+0460 U+030E U+1CF50 > which I assume you will agree makes no sense (and I wonder how > your favorite MUA would render it or how you could input it from > anything resembling a "normal" keyboard). But the SMPTUTF8 > specs allow both of those things (see Section 3.1(9) and 3.2 of > RFC 6531 and Section 3.2 of RFC 6532) and, arguably, worse. >=20 > Now, that suggests that it is very important that registrars and > registries get some serious guidance, perhaps less about > accepting non-ASCII email address local parts but about what > restrictions they should impose. You (and James) will probably > suggest that is not a job for REGEXT or the IETF and I agree > but, if the guidance does not come from somewhere, some > registry-registrar pair will come along who are expert in areas > other than Unicode and writing system issues, decide that they > _really_ want to be supportive of internationalization and > non-Latin writing systems and allow anything the SMTPUTF8 specs > allow. Noting that, for example, > \u1F438\u200D\u1F445\u1F438@example.com is, syntactically, a > perfectly valid email address (but an all-ASCII one, not some > sort of Unicode escape), someone is likely to be looking for an > ASCII form in a hurry. Or not, but that is where I think our > more fundamental disagreement lies (see below). >=20 >> Third, it shouldn't be a big deal for the Registrar to use >> such MUA.=20 >=20 > But you are effectively assuming that SMTPUTF8 MUAs, maybe all > of them, can handle, in a reasonable way, handle any email > address that is valid under SMTPUTF8 syntax. That is just not > the case. Again, see below. >=20 >> Fourth, the Registrant using SMTPUTF8 address also >> is capable of dealing with it. >>=20 >> Sorry, I don't see where the chain is broken and communication >> becomes impossible. >=20 > And here is where we are making very different assumptions. As I > understand it, you see this as EPP, and anything it might > affect, being entirely a private-use registrar-registry protocol > with, of course, registrant needs in there somewhere. If one > completely accepts that model, then a reasonable answer to my > concerns is that they should be smart enough to not allow/accept > addresses that they cannot deal with, manage, etc. If they > can't, they will find out soon enough, work it out somehow, and > adjust their rules and procedures as needed. >=20 >> =46rom my perspective, the IETF is about the Internet and we have > no more business standardizing a protocol for private use > between a pair of commercial parties in the domain name sales > and management space than we would, for example, standardizing > peering agreements among ISPs. Various protocols for > communication across that peering boundary -- protocols that we > expect will be used, or at least considered, by anyone involved > in those arrangements -- certainly, but the agreements > themselves and how commercial peers exchange, e.g., non-routing > information or information about their clients are things we > don't touch. >=20 > So, again from my point of view, but with the understanding that > I believe that the boundaries involved are a very big deal, I'm > concerned about the data involved, whether it could end up in > registry databases or be (legally) accessed by other parties who > need to contact registrants, interactions with registrants who > might want to change registrars, and so on. =46rom one > perspective, all of those are ICANN issues, not IETF ones. But > the IETF should not be making protocols that constrain ICANN > discussions or decisions in those areas unless they are > absolutely, critically, necessary from a technical point of > view. The "transmit a non-ASCII email address only because this > is a private protocol among about buddies and business partners" > idea just does not work with those considerations. So, to > repeat what I said some time ago, I see your alternatives as > providing for all-ASCII alternate email addresses along with > allowing non-ASCII ones in a standards track specification that > is about the Internet or dropping the idea of IETF > standardization, treating the effort as a private extension for > use by any registrar-registry pair who choose to use it, and > moving the effort toward Informational registration by you, > Verisign, or some other combination. >=20 > We may need to agree to disagree about that, but I hope we are > getting closer to clarity about each other's positions and > concerns. >=20 > best, > john >=20 >=20 >=20 >=20 > [1] That is frog face, ZWJ, tongue, frog face: something that > some systems would ignore and display as those three emoji > graphemes and that others would interpret as two graphemes, the > first as a frog with its tongue extended. >=20 > [2] Cyrillic Capital Omega, Combining Double Vertical Line > Above, U+1CF50. >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call