Re: [I18ndir] NFS i18n

Nico Williams <nico@cryptonector.com> Fri, 22 May 2020 03:32 UTC

Return-Path: <nico@cryptonector.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 89EAD3A0E23 for <i18ndir@ietfa.amsl.com>; Thu, 21 May 2020 20:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 udIR7YCxx6zj for <i18ndir@ietfa.amsl.com>; Thu, 21 May 2020 20:32:05 -0700 (PDT)
Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97AF63A0E1C for <i18ndir@ietf.org>; Thu, 21 May 2020 20:32:05 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9A3209211A4; Fri, 22 May 2020 03:32:04 +0000 (UTC)
Received: from pdx1-sub0-mail-a40.g.dreamhost.com (100-96-21-73.trex.outbound.svc.cluster.local [100.96.21.73]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 207E09202E4; Fri, 22 May 2020 03:32:04 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a40.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Fri, 22 May 2020 03:32:04 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Arithmetic-Broad: 23a7065e7b724969_1590118324396_3749560149
X-MC-Loop-Signature: 1590118324396:3558845075
X-MC-Ingress-Time: 1590118324396
Received: from pdx1-sub0-mail-a40.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a40.g.dreamhost.com (Postfix) with ESMTP id B83A77FEAE; Thu, 21 May 2020 20:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=KTpYFhtT9sDF6G sQaeI/N4Go9uc=; b=Ss/eXMoiseGXnh9xjEee+EqW6ULKFVLs0fCYSrRWPS5KTQ VM0YWXvIv9KFM2tl7TSU+cm1TN5AIy3xkzW293+6P+JYuQobR4HgVP29d8ZTggV2 jsBc/EA0JPjtAGd1VcuAENotA2zvl15qAzBg7AvKzOC5z/DEp9T90SCLRYIqc=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a40.g.dreamhost.com (Postfix) with ESMTPSA id E9F4E7F600; Thu, 21 May 2020 20:32:01 -0700 (PDT)
Date: Thu, 21 May 2020 22:31:59 -0500
X-DH-BACKEND: pdx1-sub0-mail-a40
From: Nico Williams <nico@cryptonector.com>
To: John R Levine <johnl@taugh.com>
Cc: i18ndir@ietf.org
Message-ID: <20200522033158.GM18021@localhost>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.OSX.2.22.407.2005212130371.6217@ary.qy>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudduvddgieelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/SIdVr18zbuVYPbU_RTFFmk4LIuU>
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:32:08 -0000

On Thu, May 21, 2020 at 09:34:41PM -0400, John R Levine wrote:
> > > My quick scan says that NFS character sets are a historical mess but
> > > they seem to be making the best of it and trying to end up at UTF-8
> > > with some reasonable normalization. ...
> 
> > [The following is all about I18N as to file names, not domainnames.]
> > 
> > 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.

Indeed, a configurable, server-side one-size-fits-all for each
filesystem is preferable to a one-size-fits-all for all implementations.

> > Thus it is my opinion is that NFSv4 shouldn't have that much to say
> > normatively about I18N for file names!
> 
> It doesn't.  How about reading the draft, and comparing it to the part of
> the NFS RFC it updates, and reviewing it for us?

I haven't read it yet.  But the document I reviewed years ago did have
much to say.  Also, I'm making a general point: that this shouldn't be
about NFSv4 specifically but about filesystems generally -- I don't have
to have read this document to make that point.

That said, I can volunteer to review it.  Is there a deadline?

> > Instead we should have an RFC laying out requirements and
> > recommendations for filesystems used via Internet remote/distributed
> > filesystem protocols.
> 
> That strikes me as something the IETF is very poorly qualified to do, and
> that nobody would pay attention to since it would be about 40 years too
> late.

You argue "who are we to tell filesystem implementors?", but telling
NFSv4 server implementors is not much different, and is strictly worse.

Specifically you could do a global search for "NFSv4 server" (and
similar phrases) and replace with "filesystem", add text explanining the
motivation for directing the latter rather than the former, and
otherwise the rest of the document's contents stays exactly the same.

Saying what one filesystem _protocol_ must do for I18N instead of what a
_filesystem_ must do for I18N is asking for conflicts with other
protocols, and also putting server implementors who are not also the
filesystem implementors in a very tough spot.

Text describing pluggable filesystem architectures and the architectural
constraints would also be good.  I'd be willing to contribute such text.

Pretending that because "we don't do filesystems, just protocols", we
can advise only protocol designers and server implementors as to I18N,
is suboptimal for the reasons above, and does not magically cause us not
to be imposing requirements on filesystems anyways.

Pretending that is also incorrect: there clearly are participants in the
NFSv4 WG who implement filesystems, and there are IETF participants who
are not NFSv4 WG participants who have sufficient experience.

Anyways, we don't really have a choice but to develop the expertise if
we're going to pretend that telling the server what to do is good enough
when in fact doing so imposes on the filesystem implementor.  At the
very least we must acknowledge that we're doing just that and the risks
involved.

Nico
--