Re: [I18ndir] NFS i18n

[Nico Williams <[e-mail]>]

On Thu, May 21, 2020 at 09:26:38PM -0000, John Levine wrote:
> In article <[e-mail]>,
> Marc Blanchet  <[e-mail]> 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
all.

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.

+1

Nico
--