Re: [I18ndir] [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12

John C Klensin <john-ietf@jck.com> Fri, 26 August 2022 18:48 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3B7C14CF1F; Fri, 26 Aug 2022 11:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 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_NONE=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 oi5NJ9n8uPb6; Fri, 26 Aug 2022 11:48:14 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9F2C14F74E; Fri, 26 Aug 2022 11:48:14 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1oReNI-0007Hi-5v; Fri, 26 Aug 2022 14:48:12 -0400
Date: Fri, 26 Aug 2022 14:48:06 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>
cc: beldmit@gmail.com, art@ietf.org, draft-ietf-regext-epp-eai.all@ietf.org, last-call@ietf.org, regext@ietf.org, i18ndir@ietf.org, gen-art@ietf.org
Message-ID: <C8F21E176669FD9E43DC976B@PSB>
In-Reply-To: <9d402942-3050-873d-79ae-3932965761a8@it.aoyama.ac.jp>
References: <00B2BD2D-63E7-4D73-95BC-DD0650B3A7DA@verisign.com> <8510291CFDD59E597396E0A4@PSB> <9d402942-3050-873d-79ae-3932965761a8@it.aoyama.ac.jp>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/NNg4vh28C1wjvgufk7sHn84phC4>
Subject: Re: [I18ndir] [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2022 18:48:15 -0000


--On Friday, August 26, 2022 14:32 +0900 "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> wrote:

> [sorry to be late with my comment; traveling]
> 
> Not objecting to the general direction of the discussion, and
> in particular Patrick's points about multiple registrations
> and transferability from a registrant's purpose, but one
> comment below.
> 
> On 2022-08-18 14:59, John C Klensin wrote:
>>...
>> (2) Whether we like it or not, when non-ASCII email addresses,
>> especially ones using scripts very different from European and
>> other so-called GLC-related one are used in arbitrary ways,
>> they don't work smoothly and globally.  They are fine for,
>> e.g., ccTLDs where communications, as well as domain name
>> labels are confined to a script or two and known providers,
>> but not for generalized communications or registries handling
>> arbitrary scripts.    If the purpose of this protocol is
>> ultimately to populate registry databases -- databases whose
>> contents are expected to provide reliable contact and
>> identify information for registrants even if that information
>> is only accessible under court order or the equivalent --
>> then all-ASCII alternative addresses are a necessity.
> 
> If it comes to court orders, then please note that courts and
> lawyers and the like are perfectly able to deal with issues
> with foreign scripts. (It may take some more time (when it
> comes to courts) and money (when it comes to lawyers).)
> 
> It's always possible to pay somebody for
> translation/transcription. Recently, software such as Google
> translate may work extremely well in most cases. It certainly
> did very recently when I tried for my own Japanese address.
> Also, if courts or lawyers need to contact somebody by EAI
> email address, they may set up EAI-capable software or ask
> somebody to do that for them or send the necessary messages
> for them. But most probably, they will chose to use snail
> mail, because that's a mode of communication that's more
> established in legal circles.

Martin,

(1) For free text, Yes.

(2) However, remember that the issue here is email addresses and
that neither the labels of the domain part nor the local part
are required to be "words" or well-known personal name in some
language.  Registries and email providers may make some
restrictions in those areas, but are not required to do so.
Made-up strings or phrases are unlike to translate accurately
whether by people are automated means.  They may transliterate
but, as you certainly know, there are many languages for which
there are multiple transliteration systems.  Even for those for
which there are ISO-standard transliteration systems, other
systems may also be in use.

Since you mentioned snail mail, the above considerations are, of
course, connected to the reason why the UPU has strict rules for
what is and is not allowed to be used in a postal address for
mail being sent internationally. Such mail addresses are an
easier problem than email precisely because of those
restrictions.  Of course, that experience is also part of the
reason why there have been periodic proposals to reduce chaos in
the DNS and on the Internet by getting of all gTLDs that do not
serve an obvious international purpose and restricting TLD
labels to ISO 3166-1 alpha-2 codes and a _very_ small number of
exceptions, none of them involving non-Latin characters.

best,
   john

> 
> Regards,   Martin.