Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)
Dmitry Belyavsky <beldmit@gmail.com> Mon, 22 August 2022 06:40 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 64983C152599; Sun, 21 Aug 2022 23:40:43 -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 RCPu2MZdjxZJ; Sun, 21 Aug 2022 23:40:41 -0700 (PDT)
Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (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 8FC90C152592; Sun, 21 Aug 2022 23:40:41 -0700 (PDT)
Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-334dc616f86so266488497b3.8; Sun, 21 Aug 2022 23:40:41 -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; bh=sM/WlOv+5KOUC0UbEuezw3kyafWhqKG9SiGrOSoXG40=; b=AbUuiELuEFOvIfJW2f8kVZtz4zE18xuNPFkjmDKUEswd4pIpMSReMbMxD/wAAlUYvP l4J/MvhZJyY16TpyUJYGRPdhw/99j3K/b2I0CsA2IXXm4WlU/gnw/EyryscscdqIRsHW ELpjvqClmLcQyQVkS4edEF7evctL+5u49W7cWlCoMvsBqYP+aB8G5Y5Od0OFURjGYlYA Hzdl97ZWAuWhHXU+Ae0uWVre7pEs0s1rxU36IYMlyAOaXZNQHYaTIkY57IY8+qTZT7Xw fJdDs68ak3BGZTxDPGQgfuyuG+FZ/KliIpwbxbA1+4OmpQL074RbpGfb41+aAW23wfnE 6sgw==
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; bh=sM/WlOv+5KOUC0UbEuezw3kyafWhqKG9SiGrOSoXG40=; b=wtuvuwO8/tXzm71L/sIDdqRY7rBt29LeX2OWQFRqsdkOY3P+uHAj8nf9Ujcs70zgNQ 6FXaNv8cUnsDplJLlXDuZoR4vyHTzUjH7JWofc/6pxQdjdmPka9NMl4P8apP5pNZw5N3 pUsl5AvO6X05QVUf6zOt2EPq0pipiZxR48t/QG88oXKdmKvZIyN/iIcXzD/HZJWoNtkY CLOEPJi0xKVDHnqFp59NymCDbWwCpDg/iENqHSUMGHZja3XmF0m0ndn9MEL+8seWHk+L 0YgBSRBvJL12usfOVMuU4Pc0dY03J1s2qRC83dRMirmDFgvhML+2AREGllqf/dGuM8/A NAPg==
X-Gm-Message-State: ACgBeo3ofOd6UqVZ724vx96c8XzWrLvVQJ56DvC2iEnPWmLzCRfzxaJr iRowMASHLKZ/IlDKl7MV7om/+QKzj0C77YwjYTqNZQqX
X-Google-Smtp-Source: AA6agR5iufKMpQxmLKj8f3/mLAVlS3vGRh1lvNX7tB8HMPugpYR67LAQtqTif12RtFGJ6R7Tx+QcvSjWGV/fCMqnBtk=
X-Received: by 2002:a25:7e42:0:b0:670:9c92:d1ab with SMTP id z63-20020a257e42000000b006709c92d1abmr18137533ybc.638.1661150440654; Sun, 21 Aug 2022 23:40:40 -0700 (PDT)
MIME-Version: 1.0
References: <58F0C1701FA3E97B1EB188D5@JcK-HP5>
In-Reply-To: <58F0C1701FA3E97B1EB188D5@JcK-HP5>
From: Dmitry Belyavsky <beldmit@gmail.com>
Date: Mon, 22 Aug 2022 08:40:28 +0200
Message-ID: <CADqLbzKyyTEGPqrUmodw+nRATOs2M8+_whG70UY-Z-YSt8J_YA@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: Patrik Fältström <paf@paftech.se>, "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>, 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="000000000000ef0ca305e6ceb922"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/cgMbULKmTbMASM5xsarHMGM-CDk>
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: Mon, 22 Aug 2022 06:40:43 -0000
Dear John, Many thanks for your comprehensive response! On Sun, 21 Aug 2022, 18:24 John C Klensin, <john-ietf@jck.com> wrote: > Dmitry and James, > > I think several different issues are getting intertwined here, > some of which rise to the level of principles. It is clear that > we are making different assumptions about what is relevant and > important and almost as clear that we are not going to convince > each other. As I said earlier, that is why we pay the IESG the > big bucks. > > In no particular order: > > (1) I believe that, if you are trying to create an IETF > standards track protocol that draws on another IETF standards > track protocol for its motivation, you are obligated to follow > the specifications of that protocol and associated experience, > not just pick up its syntax. In the case of non-ASCII email > addresses, that includes making all-ASCII addresses available as > an alternative unless there is great confidence that they will > not be needed (e.g., for communications within a country using > that country's major script (and where relevant, language) and a > restricted set of email providers. Such a restriction might > actually be reasonable within a constrained business > transaction, especially when registrant, registry, registry, and > the domain itself primarily serve a particular country or > cluster of countries (see below). > > The IETF and its predecessors have carefully avoided specifying > MUA, especially MUA-UI, behavior for well over 40 years. In > that context, the key difficulty with non-ASCII addresses may > not be easily discerned from our specifications. However, as > the EAI WG understood from the beginning, transporting non-ASCII > addresses across the Internet,in message header formats, even > delivery status notification (DSN) messages, is fairly easy. It > is especially easy by comparison to actually designing and > building software that interacts with users across a very broad > range of languages and writing systems. The usual solutions are > to either give up on that quality of MUA/UI-UX design and > instead design for a particular language community or small > cluster of them, but that leaves messages that use, or embed > addresses in, other languages and scripts in need of all-ASCII > (or some other common/agreed form) in greater or lesser trouble. > > As a different, extreme, and nit-picky, example of where this > specification has failed to appreciate what the > Internationalized Email specifications say, thse specifications > for non-ASCII email addresses and headers make it quite clear > that there are no such things as an "EAI Address" or an "EAI > extension" and that the correct term is "SMTPUTF8". That would > not be important except that IETF specs should not be creating > confusion by using incorrect terminology (no matter how > prevalent elsewhere) and because it reinforces the concern that > the WG may not have paid careful attention to the relevant > specifications (beyond a citation of syntax) in creating this > one. > Yes, using the "SMTPUTF8-compliant" term seems reasonable. > > > (2) As Patrik pointed out, there is a community interest (both > general and in ICANN policy) in making it easy for registrants > to switch registrars (whether the earlier registrar remains in > business or not). For a registrar to treat business > relationship data that do not affect users, various authorities, > or elements of the DNS itself, as confidential is entirely > reasonable. However, usable contact information for registrants > does not fall into that category but, instead, is information > registries have been required to have in their possession since > before there was an ICANN (a principle reaffirmed many times > since then). Probably this is the most important point. So let me explain how the business process looks like from my point of view. I am aware of two transfer scenarios. First implies a one domain transfer. In this case a registrant should be already registered as a client and provide some email address. If this address is SMTPUTF8, it means that the registrar-acceptor supports sych addresses. If not, then registrar-acceptor can update the contact associated with the transferring domain immediately after acceptance. So it is not a show stopper. The second one is bulk transfer in case of emergency. In that case it is the registrar's interest to be able to get more clients. > > > (3) Whether a registrant is allowed to supply a non-ASCII email > address at all and, if they are allowed to do that, whether an > ASCII alternative should (or must) be supplied is, we are > agreed, a matter for registry-registrar agreements -- at least > until national governments, other authorities, or ICANN itself > step in. I don't think anyone has suggested that supplying an > alternative all-ASCII address through the protocol should be a > requirement imposed by the IETF (certainly I have not). I > imagine that the REGEXT WG making a strong recommendation on the > subject would even be viewed by some as an intrusion on ICANN's > scope of authority. However, it is important that the protocol > be able to accommodate the inclusion and transfer of that > alternate address information lest someone --perhaps even > someone acting on behalf of a registrar who believes its > interests would be served by making transfers difficult-- claim > in an ICANN forum that such information is unnecessary and > difficult to provide --and hence should be excluded from > discussions-- because the IETF decided it was not allowed in the > protocol. > Well... Providing an opportunity to provide multiple email addresses within object (no matter if they are ASCII or SMTPUTF8) is probably worth doing but out of scope of this document. Otherwise I don't understand your point here :( > (4) To say almost the same thing from a different perspective, > if the purpose of this specification is to reduce the number of > incompatible ways in which registry-registrar pairs do things, > then please recognize that there is a strong possibility (as > predicted by the SMTPUTF8 specification family), either > immediately or after experience starts to accumulate, that > alternate all-ASCII addresses will be required for some > combinations of actors (before you removed the text, it strongly > implied just that). If you allow them in the protocol and data > structure, then people who need to transmit them will have a > guide as to how to do so. If they are not allowed in the > protocol, they you would be actively encouraging different ways > of doing things by forcing different arrangements for > transferring that information. Given what everyone who has > studied database theory knows about the dangers of transmitting > closely linked data in separate pieces it is even more likely > that they will invent alternatives to this protocol as soon as > the requirement (or even an option) for transmitting an > all-ASCII alternative address to the registry arises. > It is a fair point - but I'm not sure if it is in the scope of IETF. Registrars have a lot of such quirks and any registry adds more and more. > (5) Finally, there is a procedural issue that seems to have > gotten lost in the other (particularly i18n) discussions. The > base EPP spec [RFC5730] says that there are three ways to extend > the protocol -- protocol, object, and command-response levels. > It does not say there can never be additional ways or that other > ways are not possible but it does say "three ways". This > document defines and adds a fourth, a "functional extension". > No matter how harmless that addition is and even if the WG is > certain it would never be used for anything other than this > particular spec (in which case the reasoning should probably > appear in the spec), that constitutes an update to 5730 that > should be appropriately reflected in the RFC header and other > document metadata. If it really were a change to allow changes > to the function of EPP (I don't think it is and believe the term > may be badly chosen), then the community is owed an explanation > of why the function and/or scope of an Internet Standard is > being changed as part of what ought to be a fairly minor > extension. I believe that the change in this document is quite similar to the protocol extension - but definitely doesn't fit to it perfectly. From the other point of view we technically don't change the formal XML scheme for the email address - as I wrote in the very first version of the document. Do you think it makes sense to add that our document updates RFC 5730? > > thanks, > john > > >
- Re: [regext] [Last-Call] last call reviews of dra… John C Klensin
- Re: [regext] [Last-Call] last call reviews of dra… Dmitry Belyavsky
- Re: [regext] [Last-Call] last call reviews of dra… Gould, James
- Re: [regext] [I18ndir] [Last-Call] last call revi… John C Klensin
- Re: [regext] [Last-Call] last call reviews of dra… John C Klensin
- Re: [regext] [Last-Call] last call reviews of dra… John C Klensin
- Re: [regext] [Last-Call] last call reviews of dra… Gould, James
- Re: [regext] [Last-Call] last call reviews of dra… John C Klensin
- Re: [regext] [Last-Call] last call reviews of dra… Dmitry Belyavsky
- Re: [regext] [Last-Call] last call reviews of dra… Hollenbeck, Scott
- Re: [regext] [Last-Call] last call reviews of dra… Gould, James
- Re: [regext] [Last-Call] last call reviews of dra… Gould, James
- Re: [regext] [Last-Call] last call reviews of dra… John C Klensin
- Re: [regext] [Last-Call] last call reviews of dra… Gould, James
- Re: [regext] [Last-Call] last call reviews of dra… Gould, James
- Re: [regext] [Last-Call] last call reviews of dra… John C Klensin
- Re: [regext] [Last-Call] last call reviews of dra… Dmitry Belyavsky
- Re: [regext] [Last-Call] last call reviews of dra… John C Klensin
- Re: [regext] [Last-Call] last call reviews of dra… Gould, James
- Re: [regext] [Last-Call] last call reviews of dra… Василий Долматов
- Re: [regext] [Last-Call] last call reviews of dra… John C Klensin
- Re: [regext] [I18ndir] [Last-Call] last call revi… Martin J. Dürst
- Re: [regext] [I18ndir] [Last-Call] last call revi… Asmus Freytag