Re: [I18ndir] NFS i18n

Nico Williams <> Thu, 21 May 2020 22:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AEB573A0DD4 for <>; Thu, 21 May 2020 15:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sFPCSmD-Hcde for <>; Thu, 21 May 2020 15:49:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E38393A0C70 for <>; Thu, 21 May 2020 15:49:04 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id CC7B6207D4; Thu, 21 May 2020 22:49:03 +0000 (UTC)
Received: from (100-96-23-30.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 0671C20E54; Thu, 21 May 2020 22:49:02 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.18.8); Thu, 21 May 2020 22:49:03 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Illustrious-Befitting: 2c910dbd5a8c4101_1590101343551_1166084577
X-MC-Loop-Signature: 1590101343551:1478273170
X-MC-Ingress-Time: 1590101343551
Received: from (localhost []) by (Postfix) with ESMTP id 97C8A7F67E; Thu, 21 May 2020 15:49:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=hulWzbEf70ftVo CBN7FKxgqKYIY=; b=BSJuPhUGhiBhASvWDpvSG7wlovRKIR6ACSEyoXCxpNDuza PK8k4a925BemNO6OcecQxB7NfpNymsb4wwIEYXLD9SWQ7oQpoiWlcyERzPsGsF+n AFut4ym+k7ncBUUY0a2l9aIjvwz+DypPOA+vGmIO0zYoFLau4mPVe8zJq+HGk=
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id CED877F69E; Thu, 21 May 2020 15:49:01 -0700 (PDT)
Date: Thu, 21 May 2020 17:48:59 -0500
X-DH-BACKEND: pdx1-sub0-mail-a26
From: Nico Williams <>
To: John Levine <>
Message-ID: <20200521224857.GL18021@localhost>
References: <> <> <ra6rmd$1nah$>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ra6rmd$1nah$>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudduvddgudefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <>
Subject: Re: [I18ndir] NFS i18n
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 May 2020 22:49:15 -0000

On Thu, May 21, 2020 at 09:26:38PM -0000, John Levine wrote:
> In article <>ca>,
> Marc Blanchet  <> wrote:
> >On 21 May 2020, at 13:57, Pete Resnick wrote:
> >
> >> We've been asked to do an early review the NFS i18n document 
> >> (draft-dnoveck-nfsv4-internationalization; about 23 pages). Does 
> >> anybody want to be the official reviewer, or shall I randomly pick the 
> >> next person on the list?
> >
> >I???m no volunteering, but I would expect that they would have a Precis 
> >(RFC8264) profile or if not, why they are not using one. A quick 
> >browsing does not seem to tell that.
> You need to read the i18n parts of RFC7530 (NFSv4) and RFC5661
> (NFSv4.1 and 4.2) and the comments on them in the draft. They created
> a stringprep profile for NFSv4.1 a decade ago which nobody ever
> implemented.
> 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. They specifically note that
> normalization and case mapping is language specific with the Turkish
> "i" as an example so it is locale dependent. Most of this draft is
> unchanged from Sec 12 of RFC 7530 with the biggest change I can see a
> switch from IDNA2003 to IDNA2008 for things like server names which
> are domain names. Filenames are not domain names so IDNA doesn't
> apply.

[The following is all about I18N as to file names, not domainnames.]

NFSv4 servers can't realistically support varying locales by client, I
don't think.  Among other things, client-side NFSv4 kernels, therefore
in-kernel NFSv4 clients, are usually unaware of user processes' locales
(certainly in Unix and Unix-like systems).

Moreover, on classic Unix and Unix-like systems, the NFSv4 server can't
really implement I18N for file names either!  That has to be done by the
filesystem, or else by the NFSv4 server *and all other* filesystem
access methods, such as SMB/CIFS, AFS, WebDAV, POSIX system calls, WIN32
system calls, etc.

Due to the pluggable VFS (virtual filesystem) design of many systems on
top of which one might build an NFSv4 server, normative I18N language in
the NFSv4 RFCs ends up either having to be implemented either in the
filesystems and not the NFSv4 server, or it has to be implemented in all
access methods including the NFSv4 server (see above list), or not at

Note in particular that POSIX system call access methods as implemented
in most systems (all? I think so) simply do not know anything about the
locale of user processes calling those system calls, not even about the
codeset of the file name and path strings given to those system calls!

Co-existence of POSIX access methods and NFSv4 servers almost of
necessity drives I18N requirements into the filesystem, well below the
NFSv4 server.

Thus it is my opinion is that NFSv4 shouldn't have that much to say
normatively about I18N for file names!  Instead we should have an RFC
laying out requirements and recommendations for filesystems used via
Internet remote/distributed filesystem protocols.

> One thing I would suggest is an appendix at the end summarizing the
> changes from RFC7530.  They're mentioned in the text but it'd be nice
> to have them in one place for NFS implementors who have already
> slogged through the 300 and 600 page documents this updates.