[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
- [regext] I-D Action: draft-ietf-regext-epp-eai-21… internet-drafts
- [regext] Re: I-D Action: draft-ietf-regext-epp-ea… Hollenbeck, Scott
- [regext] Re: I-D Action: draft-ietf-regext-epp-ea… John C Klensin
- [regext] Re: I-D Action: draft-ietf-regext-epp-ea… Arnt Gulbrandsen
- [regext] Re: I-D Action: draft-ietf-regext-epp-ea… John C Klensin