Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

Dmitry Belyavsky <beldmit@gmail.com> Tue, 13 September 2022 20:17 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 4AC96C1527A6; Tue, 13 Sep 2022 13:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 BYqiD6GTjr8c; Tue, 13 Sep 2022 13:17:18 -0700 (PDT)
Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) (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 7C3A7C1522AE; Tue, 13 Sep 2022 13:17:18 -0700 (PDT)
Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-3378303138bso154466767b3.9; Tue, 13 Sep 2022 13:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=f1bEJuxY4I2IjFd32lKK0Bx2wGodBagJin53zdB3/Bo=; b=WXDtMUhqe28XGwziY/aghYHU3MNeDfyQldkOWp+yoENxPFY0YldxCIx9a4BBO4oesT PWoqUGhn2Wo920AQVQ42cpi/wngmFiaAs/lNBnz9mwQ+FBNq0jdgN7+DhUUAZ1urEVhE oC4pLNuTsam6EWQi98Yg/BN4gEEKs6+puzPQQyHdVIAacTp5mAIEiQNlvHict/WzdbLy 9W6bBBMB+bcJg6ihuyN8dU8Gl2YuxFbTDBCO+y1Zht7fS5TJNex2zVjURA3F47oXU2J+ uWzNJtsIvc8wfBpQe9cBJl4ns36foPDLEsxmt+9868OoGVJUOJCkgBwh1hN+fxZ1SFSs jxLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=f1bEJuxY4I2IjFd32lKK0Bx2wGodBagJin53zdB3/Bo=; b=mDXQGRjtLcAq+NqbvrszLv5K8R/ELZS17SxNoV2J9IoKJ0BAvKD9VCy009kV1MJn9N KPfkepN7pHrJ0pGGK0lVOz+uGzqLzaF2ouWy7y6unEeZpZle/yD7tDbh02uT5YfJ21Jj mjdhzekUp8I/k2+i5KNBQ6D9x4BQ50ff0Xo/HnMCQJCJN/XrKVhn4p9Iqz4Hx83l9k45 cFRqWSX4DlbvJJeKPoYFRo2hVe7azXBPNnTeF91VCj/c2iO6emjbV9VQWxGumSrjDOMO I6mNQwge37IAa2KN90KP31Khs5kEFVgxg3ordr4RofVtfqH4Hx6REjXQPMSYxevRXsRu NJgw==
X-Gm-Message-State: ACgBeo0Mo7H/w7U20QVENv6Xn+ct+A1yKJMSWjexDgcZ7MwrDSp2jCgN aKuegBMFQepBB4RuEF37Ki+jSuWY5/jvssM3pu8=
X-Google-Smtp-Source: AA6agR4AS9jt+gEC2/0/kFTyyhx2XyIW2CMPCiDA5HSlDUdw7O+4ar19zX6nvmp7+Wo8r6o3cSaWTVfAM6i1YHmHVbA=
X-Received: by 2002:a81:1246:0:b0:345:222d:d994 with SMTP id 67-20020a811246000000b00345222dd994mr28187632yws.423.1663100237195; Tue, 13 Sep 2022 13:17:17 -0700 (PDT)
MIME-Version: 1.0
References: <DFBC3847-F489-42D8-AB28-A22F25BC7CD9@verisign.com> <1C6C85AAF7DA5EFEDCED0BB0@PSB>
In-Reply-To: <1C6C85AAF7DA5EFEDCED0BB0@PSB>
From: Dmitry Belyavsky <beldmit@gmail.com>
Date: Tue, 13 Sep 2022 22:17:05 +0200
Message-ID: <CADqLbzLZbAun8xAtmsnE2b6h5GArT=8g_o+L1wEwFc7_c4X7kA@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>, =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <paf@paftech.se>, art@ietf.org, draft-ietf-regext-epp-eai.all@ietf.org, last-call@ietf.org, regext <regext@ietf.org>, i18ndir@ietf.org, gen-art@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dd2ec905e894b2c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/p0h5glJ7Y-KIP4vh6UmtA7edHjI>
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 <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: Tue, 13 Sep 2022 20:17:19 -0000

Dear John,
Thank you for your clarification!

Let me explain my understanding.

First, SMTPUTF8 MUAs already exist.
Second, if the registry provides this support, it implies that it can deal
with such addresses.
Third, it shouldn't be a big deal for the Registrar to use such MUA.
Fourth, the Registrant using SMTPUTF8 address also is capable of dealing
with it.

Sorry, I don't see where the chain is broken and communication becomes
impossible.

On Tue, Sep 13, 2022 at 9:04 PM John C Klensin <john-ietf@jck.com> wrote:

> James,
>
> My apologies for not having responded to your note sooner.
> I've been preoccupied with several unrelated things.
>
> I greatly appreciate the changes to use an existing EPP
> extension framework and to correct the terminology error of EAI
> -> SMTPUTF8.   I agree that the more substantive SMTPUTF8
> technical issues should go back to the WG.
>
> However, in order that the discussion you suggest for IETF 115
> be useful and not just lead to another round of heated Last Call
> discussions, I think that, for the benefit of those who have
> been following the discussion closely and those who should have
> been, it is important to be clear about what the disagreement is
> about.  When you characterize the issue as "e-mail cardinality",
> it makes it sound, at least to me (maybe everyone in the WG has
> a better understanding) like this is some subtle technical
> matter.
>
> It really isn't.  The EAI WG was very clear during the
> development of the SMTPUTF8 standards that the biggest problems
> with non-ASCII email addresses were going to be with user agents
> (MUAs) (and, to some degree, with IMAP and POP servers that are
> often modeled as part of MUAs) and not with SMTP transport over
> the Internet.  Making an MUA tailored to one particular language
> and script (in addition to ASCII), or even a handful of them, is
> fairly easy.  Making one that can deal well with all possible
> SMTPUTF8 addresses is very difficult (some would claim
> impossible, at least without per-language, or
> per-language-group, plugins or equivalent).
>
> The implication of that problem is that, except with rather
> specific constraints, fallback all-ASCII addresses are
> important.  I'd be delighted to have a discussion about the
> types of constraints the would be needed, but every possibility
> involves a policy decision about DNS registration management and
> is hence out of IETF scope.  I claim didn't take the EAI WG to
> figure the need for fallback addresses out: it gets fairly easy
> as soon as someone thinks about, e.g., how their favorite MUA
> would manage addresses, and potentially error messages, that use
> a relatively complex writing system that has not been in active,
> non-scholarly, use for millennia.
>
> This is why, unless non-ASCII email addresses are used strictly
> within a particular writing system environment (and restricted
> to those writing systems), it is strongly recommended that an
> all-ASCII email address be available as a fallback.
>
> As we have discussed, I am not suggesting such an address be
> required in any particular transaction any more than you are
> suggesting that registries be required to accept non-ASCII email
> addresses at all.  Subject to whatever regulatory, contractual,
> or other constraints might apply, decisions about whether to
> allow (or encourage) such addresses, what constraints to impose
> on the scripts or domains that might be used in the addresses if
> any, and whether a all-ASCII address (or an all-ASCII local
> part) should be allowed or required in a particular transaction,
> is not a matter for the IETF.
>
> However, providing for the optional transmission of a non-ASCII
> address without providing for the optional transmission of an
> all-ASCII alternative is as much of a policy decision as trying
> to build rules about when non-ASCII addresses should be
> permitted would be.  If the IETF (or at least REGEXT) believe
> that it is a good idea to provide for non-ASCII addresses, let's
> do that right.  And "right" requires either provision for a an
> all-ASCII alternative or a globally agreed profile of what sorts
> of non-ASCII addresses are valid.  It is not the sort of thing
> that can reasonably be ignored or postponed for future work, at
> least without creating back-door policy decisions and/or
> interoperability problems, or the IETF is willing to standardize
> a protocol with known serious deficiencies on the assumption
> that those "details" can be worked out later.
>
> thanks,
>    john
>
>
> --On Wednesday, August 31, 2022 17:26 +0000 "Gould, James"
> <jgould=40verisign.com@dmarc.ietf.org> wrote:
>
> > John,
> >
> > draft-ietf-regext-epp-eai-16 was posted that addresses two of
> > the issues that you raised, by changing to use a
> > command-response extension, and to replace the EAI references
> > with SMTPUTF8.  I believe the remaining issue of the e-mail
> > cardinality needs to be brought back to the REGEXT working
> > group for discussion.  I've requested an agenda item at
> > IETF-115 for it and I encourage you to participate in the
> > meeting to discuss it first-hand if the agenda item is
> > accepted.
> >
> > Thank you for all your detailed feedback and discussion!
>
>
>

-- 
SY, Dmitry Belyavsky