Re: [I18ndir] I-D on filesystem I18N

[Nico Williams <[e-mail]>]

On Tue, Jul 07, 2020 at 10:27:36PM -0400, John R Levine wrote:
> > It's the same issue.
> 
> Indeed, so unless we can address it, I wouldn't put a lot of work into this.

Well, we have a spec that running code does not match.

We have two choices: leave it as-is, or find a way to make it a better
match for reality while achieving our I18N goals.  I believe we can do
the latter, and I believe that the former kinda sucks.

We in the then Solaris Engineering group chose to do the right thing,
which meant ignoring the spec.  We were able to do that by reasoning our
way through the problem, and because implementing the spec as written
leads to serious problems (described in my I-D).

So what shall we do?

And what shall we do for other protocols that deal in filenames?  E.g.,
if ever we finish SFTP, or maybe in HTTP.  RFC 7230 basically refers to
RFC 3986 regarding lookups, but it says nothing about PUT/POST and
whether new resources get their local parts normalized.

> > > You are right that NFS clients need some way to find out whether two
> > > different names refer to the same file, but the idea of a registry
> > > seems like a non-starter, both because nobody has any incentive to
> > > register and because I expect there are a lot of strange corner cases
> > > like unpaired UTF-16 surrogates that would be very hard to describe.
> > 
> > Perhaps.  I was considering using some existing repository of locales,
> > specifically CLDR.
> 
> CLDR is great for what it does, but I would be surprised if file system case
> folding matched any of its entries.  CLDR tells the "ls" program how to
> format timestamps for display.

I looked, and... I'll have to look again, but I'm pretty sure CLDR does
have case-folding tailorings.

> > [ NFS already has a way to get handles for filenames ]
> 
> > Caching clients might support disconnected operation.  Then what?
> 
> I don't think I've ever seen a disconnected NFS client, but let's assume one
> exists.  It will have to deal with all sorts of synchronization issues
> including the possibility that "foo" and "bar" are the same file.  Why is
> dealing with "foo" and "FOO" any different?

Indeed, NFSv4 clients don't, but the whole world isn't NFSv4.  That's a
big part of what's wrong with putting I18N into the NFSv4 server: NFSv4
isn't the only protocol.

Thanks for your review!

Nico
--