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

From: Nico Williams <[email-masked]>
Date: Thu, 9 Jul 2020 11:59:11 -0500

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
--

---

From: David Noveck <[email-masked]>
Date: Fri, 10 Jul 2020 07:07:34 -0400

On Thu, Jul 9, 2020, 12:59 PM Nico Williams <[email-masked]> wrote:

> wrong for 17 years now, i.e., since RFC 3530.

The IESG  clearly got this wrong in RFC3530  but the working did not. The
working group was not involved in drafting the internationalization section
that appeared in RFC3530 and it was never implemented.

In my view, RFC7530 dealt with this adequately, although it's handling of
the case-insensitive case needs work. The job now is to fix that and apply
the RFC7530 treatment to all Nfsv4 minor versions.

This is not something new
> years, and I've written about this on my blog and elsewhere many times.

Understood.

>    that!- does not reflect running code

That's only true if one considers the server-side file system as not part
of the server.

I see no up-side and a great deal of confusion arising from this peculiar
approach to terminology.

>  - I18N responsibilities belong almost entirely to each filesystem

No. As you point out, I18N *implementation *needs to be done within
server-side file systems.

The question of responsibility is different. Within protocol
specifications, responsibilities are assigned to the communicating
entities.  There is no way to assign responsibility to N'th parties within
those entities.

>    lookups against the cache do need to know the I18N rules applied by

Good point. Nfsv4 needs to do that.

> directory).

Agree.  That should be addressed via an NFSv4.2 extension. I hope your
document can provide the IANA  basis for that.

And perhaps NFSv4 servers need to reject invalid file name
> UTF-8 on create (and lookup),

This is currently OPTIONAL.  Your draft has this as a SHOULD.  We need to
discuss.

but that's it for the server's
> responsibilities.

Accepting, for the moment, your approach to terminology, yes.

> 18n-00.

I've read it.  I see a lot of value within this document but have the
following major issues with the approach:

  o The approach taken to terminology makes it hard to distinguish the
document's real advances from the pseudo-advances that come from making a
problem someone else's responsibility.

  o Given that the entities whose behavior is discussed are outside the
IETF's area of responsibility, the document makes more sense as
Informational.

Soon I'll submit -01.  (Back in 2013 I also submitted draft-
> This has led to lively

I assume you mean "heated".

discussion on the i18ndir mailing list.  Some
> the i18ndir, but we will, I'm sure.

This discussion has been going for a very long time. I'm not holding my
breath.

You can find the mailing list
> archives, though you subscription is limited to members of the

That is not reasonable.  This document needs to be discussed by the wide
range of people it might affect. An appropriate forum needs to be
found/created.

> WG out of the business of dealing with I18N.

I don't see how.

There will be a modicum of
> I18N work to do with caching clients.

I still anticipate problems getting people to read the documents.

Let's face it. You and I think this stuff is interesting but nobody else
does.

> the equivalence problem normally dealt with by normalization.

True. The only problem is the locale-dependance of the latter, because of
the way Unicode (mis)-handled Turkish.

> support the case about running code, but anyways, it'd be nice.

I'd like to see an unencumbered open source version. Sigh!

> Nico
> --
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>