[nfsv4] Making I18N exciting by getting it mostly out of NFSv4

[Nico Williams <[e-mail]>]

I performed an early review of draft-dnoveck-nfsv4-internationalization-
01 on behalf of the i18ndir.  I'm not holding up progress.  It was only
an early review.  I am taking advantage of this opportunity to revisit
filesystem internationalization though.

Yes, I do believe we (the IETF, the NFSv4 WG) have had filesystem I18N
wrong for 17 years now, i.e., since RFC 3530.  This is not something new
-- I've been saying something like this for almost as long as those 17
years, and I've written about this on my blog and elsewhere many times.

Specifically:

 - putting responsibility for normalization and case handling in a
   filesystem server is simply wrong and -since implementors understand
   that!- does not reflect running code

 - I18N responsibilities belong almost entirely to each filesystem

 - clients that cache directory contents with intent to perform local
   lookups against the cache do need to know the I18N rules applied by
   the remote filesystem

The NFSv4 protocol (and others) does need to support telling _caching_
clients what I18N rules are applied by each filesystem (or even each
directory).  And perhaps NFSv4 servers need to reject invalid file name
UTF-8 on create (and lookup), but that's it for the server's
responsibilities.

To help with this, I've written and submitted draft-williams-filesystem-
18n-00.  Soon I'll submit -01.  (Back in 2013 I also submitted draft-
williams-i18n-boundary-analysis-00.)

This has led to lively discussion on the i18ndir mailing list.  Some
concede that this approach is correct but don't care to change past
consensus.  Others think otherwise.  We've not reached consensus within
the i18ndir, but we will, I'm sure.  You can find the mailing list
archives, though you subscription is limited to members of the
directorate.

For this WG, this work should be exciting because it will mostly get the
WG out of the business of dealing with I18N.  There will be a modicum of
I18N work to do with caching clients.

Also, regarding running code, now that APFS implements the same approach
as ZFS has for some 14 years now, I think it's fair to say that the best
current practice for I18N in filesystems is:

 - regarding normalization, implement form-insensitive, form-preserving
   behavior

 - do it in the filesystem

Note that this treats normalization like case is typically treated in
case-insensitive filesystems: preserve {case, form}, but be {case-,
form-} insensitive.  Indeed, case-insensitivity is a lot like extending
the equivalence problem normally dealt with by normalization.

The only reasonable alternative is HFS+'s, which is closer to 20 years
old now, and that is to normalize on create (and lookup).  But Apple has
clearly abandoned this approach with APFS.

I took a look and Linux does have kernel Unicode form- and case-
insensitivity utility code, but it's generally only used by
case-insensitive filesystems.  It should be relatively simple to add
support for a form-insensitive filesystem option.  This isn't needed to
support the case about running code, but anyways, it'd be nice.

Nico
--