Re: [I18ndir] NFS i18n

[Nico Williams <[e-mail]>]

On Thu, May 21, 2020 at 09:34:41PM -0400, John R Levine wrote:
> > > 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. ...
> 
> > [The following is all about I18N as to file names, not domainnames.]
> > 
> > NFSv4 servers can't realistically support varying locales by client, ...
> 
> I agree, but a NFS server in Turkey will want to use Turkish case mapping,
> not some generic UTS46 one-size-fits-badly mapping.  That's the point, they
> don't prescribe a single mapping.

Indeed, a configurable, server-side one-size-fits-all for each
filesystem is preferable to a one-size-fits-all for all implementations.

> > Thus it is my opinion is that NFSv4 shouldn't have that much to say
> > normatively about I18N for file names!
> 
> It doesn't.  How about reading the draft, and comparing it to the part of
> the NFS RFC it updates, and reviewing it for us?

I haven't read it yet.  But the document I reviewed years ago did have
much to say.  Also, I'm making a general point: that this shouldn't be
about NFSv4 specifically but about filesystems generally -- I don't have
to have read this document to make that point.

That said, I can volunteer to review it.  Is there a deadline?

> > Instead we should have an RFC laying out requirements and
> > recommendations for filesystems used via Internet remote/distributed
> > filesystem protocols.
> 
> That strikes me as something the IETF is very poorly qualified to do, and
> that nobody would pay attention to since it would be about 40 years too
> late.

You argue "who are we to tell filesystem implementors?", but telling
NFSv4 server implementors is not much different, and is strictly worse.

Specifically you could do a global search for "NFSv4 server" (and
similar phrases) and replace with "filesystem", add text explanining the
motivation for directing the latter rather than the former, and
otherwise the rest of the document's contents stays exactly the same.

Saying what one filesystem _protocol_ must do for I18N instead of what a
_filesystem_ must do for I18N is asking for conflicts with other
protocols, and also putting server implementors who are not also the
filesystem implementors in a very tough spot.

Text describing pluggable filesystem architectures and the architectural
constraints would also be good.  I'd be willing to contribute such text.

Pretending that because "we don't do filesystems, just protocols", we
can advise only protocol designers and server implementors as to I18N,
is suboptimal for the reasons above, and does not magically cause us not
to be imposing requirements on filesystems anyways.

Pretending that is also incorrect: there clearly are participants in the
NFSv4 WG who implement filesystems, and there are IETF participants who
are not NFSv4 WG participants who have sufficient experience.

Anyways, we don't really have a choice but to develop the expertise if
we're going to pretend that telling the server what to do is good enough
when in fact doing so imposes on the filesystem implementor.  At the
very least we must acknowledge that we're doing just that and the risks
involved.

Nico
--