Re: [I18ndir] I-D on filesystem I18N

[John C Klensin <[e-mail]>]

--On Tuesday, July 7, 2020 02:04 -0500 Nico Williams
<[e-mail]> wrote:

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

Except that "so not deal with RTL/LTR issues" is equivalent to
"blow off a significant number of people in the world who use
such writing systems".  There are probably ways deal with the
issues in things like file system paths, but saying "display
system are not in scope" and then moving on is probably not a
reasonable member of that set.


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

With the understanding that it is case folding, regardless of
its other advantages, that causes some of the nasty edge cases,
e.g.,

* At least before the upper-case Eszett ("Sharp S") was
introduced as a code point (and still for backwards
compatibility reasons) 

   toLower(ß) -> ß  (already lower case)

* Similarly,

   toLower(i) -> ı (U+0131, already lower case)

Only when does case folding, mapping the former to "SS" and then
to "ss" and the latter to "I" and then to "i", do nasty edge
cases requiring locale or language-specific treatment arise.

Priority question: we have a whole series of long-outstanding
and core i18n documents more or less in queue with
draft-faltstrom-unicode12 (and the now-required
draft-faltstrom-unicode13), draft-klensin-idna-rfc5891bis,
draft-freytag-troublesome-characters, and some SMTPUTF8 ("EAI")
tweaks that have not been turned into I-Ds as obvious examples
along with, perhaps, draft-sullivan-lucid-prob-stmt, the
notorious draft-klensin-idna-5892upd-unicode70, and others.  How
do we want to prioritize those probably tedious (but important
to make/keep existing standards track specs workping] well)
specs versus work relative to Nico's much more exciting file
system proposal?

    best,
     john