Re: [I18ndir] NFS i18n

John C Klensin <john@jck.com> Fri, 22 May 2020 03:13 UTC

Return-Path: <john@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 40DE63A0E3B for <i18ndir@ietfa.amsl.com>; Thu, 21 May 2020 20:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChhIAe0sZpcE for <i18ndir@ietfa.amsl.com>; Thu, 21 May 2020 20:13:32 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 455123A0E36 for <i18ndir@ietf.org>; Thu, 21 May 2020 20:13:32 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1jby7h-000MW9-2u; Thu, 21 May 2020 23:13:25 -0400
Date: Thu, 21 May 2020 23:13:18 -0400
From: John C Klensin <john@jck.com>
To: John R Levine <johnl@taugh.com>, Nico Williams <nico@cryptonector.com>
cc: i18ndir@ietf.org
Message-ID: <B9C29FA210931FEC78FAF9F8@PSB>
In-Reply-To: <alpine.OSX.2.22.407.2005212130371.6217@ary.qy>
References: <4DC95412-CAE3-414C-8B28-42CB5E129224@episteme.net> <CCED5FB7-4D12-483C-BC4D-7F7393AB0D8B@viagenie.ca> <ra6rmd$1nah$1@gal.iecc.com> <20200521224857.GL18021@localhost> <alpine.OSX.2.22.407.2005212130371.6217@ary.qy>
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: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/Pw9QRLY2viKwy_qxZ4GzdzGUjBg>
Subject: Re: [I18ndir] NFS i18n
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
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, 22 May 2020 03:13:41 -0000


--On Thursday, May 21, 2020 21:34 -0400 John R Levine
<johnl@taugh.com> wrote:

>> NFSv4 servers can't realistically support varying locales by
>> client, ...
> 
> I agree, but a NFS server in Turkey will want to use Turkish
> case mapping, not some generic UTS46 one-size-fits-badly
> mapping.  That's the point, they don't prescribe a single
> mapping.

Of course, an NFS server in Turkey (or anywhere else) serving
out a file system where names or case-sensitive (such as Unix)
won't want to do case mapping at all.  And that is a fairly good
example of why this is sensitive... and why these folks would be
better off recommending appropriate profiles of PRECIS -- if
necessary, somewhat localized ones-- rather than rolling their
own.  It is also the reason why they need to much more careful
approach to normalization than the handwaving I think I noticed
as I went quickly through the draft.

   john