Re: [I18ndir] I-D on filesystem I18N

[Patrik Fältström <[e-mail]>]

Nico, I think this is good stuff. I must though of course(!) come with some suggestions and ideas that can make this even better.

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.

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

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

   Patrik

On 7 Jul 2020, at 0:51, Nico Williams wrote:

> I've submitted draft-williams-filesystem-18n-00.
>
> The I-D covers the background of the issue, documents the existence of the VFS, explains why I18N behaviors belong at the filesystem layer instead of the filesystem protocol server layer, the need to expose I18N behavior metadata to clients, and provides advice to protocol designers and filesystem implementors.  It only deals with path components, not any other I18N issues.
>
> It seems unlikely that this directorate will meet "at" IETF 108.
> Nonetheless, this I-D may be useful as a starting point for the issue of filesystem I18N, and it should be useful as a follow-up to my early review of draft-dnoveck-nfsv4-internationalization-01.
>
> Cheers,
>
> Nico
> -- 
>
> -- 
> I18ndir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i18ndir