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

[David Noveck <[e-mail]>]

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

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


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

Understood.


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

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.


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

Good point. Nfsv4 needs to do that.


> The NFSv4 protocol (and others) does need to support telling _caching_
> clients what I18N rules are applied by each filesystem (or even each
> 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.


> To help with this, I've written and submitted draft-williams-filesystem-
> 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-
> williams-i18n-boundary-analysis-00.)
>
> This has led to lively


I assume you mean "heated".

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.


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

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.


> For this WG, this work should be exciting because it will mostly get the
> 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.


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

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

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

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


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