[regext] Re: I-D Action: draft-ietf-regext-epp-eai-21.txt

John C Klensin <klensin@jck.com> Tue, 03 September 2024 18:32 UTC

Return-Path: <klensin@jck.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 310C1C180B6F for <regext@ietfa.amsl.com>; Tue, 3 Sep 2024 11:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 6kRsK5R8Q2_q for <regext@ietfa.amsl.com>; Tue, 3 Sep 2024 11:32:31 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D0C17C884 for <regext@ietf.org>; Tue, 3 Sep 2024 11:32:31 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <klensin@jck.com>) id 1slYK2-000Bws-Hi; Tue, 03 Sep 2024 14:32:10 -0400
Date: Tue, 03 Sep 2024 14:32:04 -0400
From: John C Klensin <klensin@jck.com>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Message-ID: <7CB10AD5188CF7A824119CE2@PSB>
In-Reply-To: <502af5bc-0e41-4a80-bfa2-a01a809c45c3@gulbrandsen.priv.no>
References: <172426679531.2321166.15578647447218404269@dt-datatracker-6df4c9dcf5-t2x2k> <181ca38acc5b4fb7a0dfec8f24858eb3@verisign.com> <A6DD4AFA8784AD97BD195BF9@PSB> <502af5bc-0e41-4a80-bfa2-a01a809c45c3@gulbrandsen.priv.no>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: klensin@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Message-ID-Hash: ELMDNB2C3ANGG2OKYXVDEMAHVRGC4TIM
X-Message-ID-Hash: ELMDNB2C3ANGG2OKYXVDEMAHVRGC4TIM
X-MailFrom: klensin@jck.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Hollenbeck, Scott" <shollenbeck@verisign.com>, regext@ietf.org, resnick@episteme.net
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [regext] Re: I-D Action: draft-ietf-regext-epp-eai-21.txt
List-Id: Registration Protocols Extensions Working Group <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/5lH7d_qgYLe1QpZQJbc4YHnLOwo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Owner: <mailto:regext-owner@ietf.org>
List-Post: <mailto:regext@ietf.org>
List-Subscribe: <mailto:regext-join@ietf.org>
List-Unsubscribe: <mailto:regext-leave@ietf.org>


--On Tuesday, September 3, 2024 12:15 +0200 Arnt Gulbrandsen
<arnt@gulbrandsen.priv.no> wrote:

> I want to digress on one point here.
> 
> John C Klensin writes:
>> (1) As you know, I personally favor the idea that, if non-ASCII
>> email addresses are to be used in a global context, all-ASCII
>> alternatives should be available.
> 
> This sounds so plausible, but it hinges on that global context.

Actually no disagreement.  See below.

> There's immense amounts of email that's not in any sort of global
> context. My mail is, of course, but one of my important
> organizations is my children's school. The place basically works on
> email. The email traffic is immense, and local. Not just local to
> the country, it's local to people who live in or around the city.
> Parents, employees, suppliers, consultants, the ministry of
> education are all reachable with a local transport ticket.
> 
> I spoke to a company that serves primary schools and kindergartens
> in Egypt. Their customers aren't good at latin letters.
> 
> I'm wary of requirements that assume that people can spell latin
> letters reliably. We globals can.

Nothing that I said was intended to be inconsistent with that.  IIR,
you posted a note recently that indicated you have different email
addresses that you use for different purposes.  So do many others.
For these particular "global" situation, you use globally optimal
addresses which are all-ASCII.  For your children's school, you and
all of those you list use whatever addressing conventions (and
language and writing system) work for you and for the rest of that
semi-closed community.  Similarly, that company working with schools
in Egypt should use whatever conventions it uses in talking about
that semi-closed community.

I even have a personal example: I grew up in a household where
parents, grandparents, and their friends (even ones where were quite
remote) communicated, and even wrong notes to each other in a
language (and writing system) the children of my generation were not
taught.  It became a sort of secret language for discussions of they
didn't want the kids to be part.  Very convenient, no matter how I
felt about it at the time.  But they didn't try to use that language
to communicate with strangers who where not part of that particular
group.

The lesson from all of this is that, if one is communicating within a
community with shared knowledge and practices  -- when I said
"local", I was not talking about geography -- then it is entirely
reasonable to communicate in a language (and writing system) that
makes sense in that community.  Unless people are, e.g., trying to
learn a different language, anything else would be fairly strange.
If they find it convenient to use non-ASCII email addresses in that
context, that is great and remains great whether they transmit the
non-ASCII addresses on the wire or develop some mapping convention
that the MUAs at both ends use (a convention with which the IETF
should have nothing to do).  But, it they want or need to communicate
globally, the best solution, at least for email envelope addresses,
remains all-ASCII (or all undecorated Latin script) strings.

I hope I'm not repeating myself too often, but that distinction
didn't start with the Internet. If you, your parents, and probably
your grandparents wanted to send a letter to someone within Norway
(or, if appropriate treaties were in place, to an associated
country), addresses could be written without concerns about basic
Latin script.   But, as soon as they (or you) wanted to send that
letter to someone in a country far away, addresses --at least at the
country-name level-- were required, by international treaty/
convention-- to be in undecorated Latin characters.  In many
countries, they would also be required to use different stamps and
perhaps even envelopes with different markings.   Same for the
Egyptian customers of that company if they wanted to send letters to,
e.g., Western Europe.

Now, there is an important difference between that postal example and
Internet email, which is that the former has a very clear
envelope-message separation.  For those envelopes, using undecorated
Latin characters -- even if one has to find help writing them-- has
no implications at all for anything in the message.   Due to what
might, in retrospect, have been errors in the design of RFC 822
and/or our failure to invent or adopt the multilevel envelope design
of X.400, we end up with requirements that bind information inside of
the envelope to information on the outside and, indeed, to
requirements for ASCII in header field names.  Of course, MUAs for
receivers can translate that information to local characters and
terminology if desired and MUAs for senders can translate the other
way, but nothing is going to make IETF-standard email header
requirements really friendly to those who find ASCII characters
difficult.  And it is far, far, too late to fix that now.

best,
   john