Re: [I18ndir] I-D on filesystem I18N

[Nico Williams <[e-mail]>]

On Tue, Jul 07, 2020 at 07:01:42AM +0200, Patrik Fältström wrote:
> Nico, I think this is good stuff. I must though of course(!) come with
> some suggestions and ideas that can make this even better.

Thanks!

> When you talk about what context this document is about, I feel you
> should explicitly say that you do not deal with RTL/LTR issues. This
> ends up being something that is very very important as well, but
> display issues is definitely not within scope for this document.

Quite true!

> https://stupid.domain.name/node/681
> https://stupid.domain.name/node/682
> https://stupid.domain.name/node/683

:)

> When looking at case folding, I normally succeed by explaining that
> the definition of case folding in fact is a function, not an attribute
> on the character. I.e. one can apply the function lower_case() to a
> character, and then with the help of that function say that "a
> character is said to be lower case if lower_case(s) is s. I.e. that
> the character is stable when applying the lower_case() function on it.
> 
> The reason for this is that it makes it easier to explain in the next
> step that the function might very well be (as you say) locale
> dependent, and I think more important that lower_case() and
> upper_case() are two functions that might not be inverse of each
> other. I.e. just because t = lower_case(s) might not imply s =
> upper_case(t).

And case folding can be designed for case-insensitive comparisons, so it
need not be the same as tolower().  That's why we speak of case folding,
not "lowering case" or such like.

> When this is understood(!) one can move forward and explain why for
> example IDNA only look at stability of normalisation and case folding
> to lower case. I.e. that that is one of the main ways "stability"
> regarding characters is defined in the IETF, and then how/why we need
> that stability after storage (as you explained).

Yes.  But it's easier for filesystems anyways, since the rules can vary
by filesystem and are applied by the filesystem (and caching clients),
so we have more locality and less in the way of global rules.  That is
as to case anyways; fortunately there's no need for local variations in
NFs!  In contrast, in DNS, the rules are not applied by the servers[*],
which complicates any attempt to vary the rules applied by clients to
domainnames under different TLDs.

That's a distinction probably worth being more explicit about.  In order
to engineer a solution, one has to know the constraints.  The
constraints in DNS are different than in filesystems.

[*] In principle, I suppose, DNS servers could pretend that all case
    variations of U-labels exist with the same content as the canonical
    A-labels.  (After all, that's what DNS servers are required to do
    for ASCII labels.)  But I suspect no one wants to implement this
    functionality in their DNS servers!  (This would be not unlike,
    e.g., Active Directory pretending that all case variations of the
    same realm name are essentially the same.)

Nico
--