Re: [I18ndir] I-D on filesystem I18N

[Asmus Freytag <[e-mail]>]

On 7/6/2020 3:51 PM, Nico Williams wrote:
> I've submitted draft-williams-filesystem-18n-00.

Here are my comments:

>     This document describes requirements for internationalization (I18N)
>     of filesystems specifically in the context of Internet protocols, the
>     architecture for filesystems in most currently popular general
>     purpose operating systems, and their implications for filesystem
>     I18N.  From the I18N requirements for filesystems and the

The first sentence doesn't scan - the constructions joined by "and" 
seemingly are not parallel enough.

>     [TBD: Add references galore.  How to reference Unicode?  How to

If you go on the Unicode site and look for the page on the latest 
version (currently https://www.unicode.org/versions/Unicode13.0.0/), you 
can navigate to suggested ways to reference. I would cite the latest 
version as of the time of drafting of the I-D and then also write: "the 
latest version is available at" and give the URL as 
http:\\www.unicode.org\versions\latest.

If you need to reference specifically the properties, the character 
database is at https://www.unicode.org/Public/13.0.0/ or  
https://www.unicode.org/Public/UCD/latest/ -- You could also link to 
UAX#44, which is the overview of the Unicode Character Database. The 
"latest" is at: https://www.unicode.org/reports/tr44/ and the current 
one, as of today, is at 
https://www.unicode.org/reports/tr44/tr44-26.html (see the "This 
version" link for the latest).

Unless you need to specifically discuss a particular topic, in which 
cases you might like to identify a specific UAX (e.g. 9 for Bidi) or 
chapter. Links to chapters are redirected correctly from the "latest" link.

If this is a bit complex, it's because Unicode really is a family of 
standards.

>   To deal with the equivalence problem, Unicode defines Normal Forms
Unicode calls these "Normalization Forms", see Section 3.11 in TUS (The 
Unicode Standard) so that is what should be used when capitalized. Ditto 
for the formal names for NFC and NFD.

I think you need to mention already here that NFC/NFD represent a 
semantic identity (and generally identical appearance) while NFKC and 
NFCD abstract away rather noticeable differences in appearance that may 
in some cases imply strong semantic differences to some users (e.g. math 
alphabets).

>   Unicode compatibility equivalence allows equivalence between
>     different representations of the same abstract character that may
>     nonetheless have different visual appearance of behavior.  There are
>     two canonical forms that support compatibility equivalence: NFKC and
>     NFKD.  Using NoCL with NFKC or NFKD may be surprising to users in a
>     visual way.  While form-insensitivity with NFKC or NFKD may surprise
>     users who might consider two file names distinct even when Unicode
>     considers them equivalent under compatibility equivalence.  The
>     latter seems less likely and less surprising, though that is an
>     entirely subjective judgement.
You really MUST not use the term "canonical" with NFKC and NFKD because 
for Unicode, the two forms NFC and NFD are considered "canonical" and 
that term is used contrastively to "compatibility".

There's an "of" that should be an "or", but it's not just behavior - 
it's also meaning. Mathematicians would object strenuously to having 
their math alphabets "normalized" to standard A-Z.

NFK(C/D) is useful in a different way: if it used to disallow code 
points that aren't stable under these normalization forms, then one 
sidesteps the issue of whether the distinct appearance etc. is 
meaningful, but without ever changing a filename (which would happen if 
it was normalized when stored). (There may be no file-systems that take 
this approach, nevertheless it's worth discussing as it is used in other 
naming schemes).

>     foldings are defined by Unicode.  Generally, case-insensitive
>     filesystems preserve original case just form-insensitive filesystems
>     preserve original form.
There's an "as" missing.

However, early case-insensitive file systems did not preserve case. Not 
sure how rare this has become.

>     listings that work the same way as on the server.  We do not specify
>     any case foldings here.  Instead we will either create a registry of
the "here" is unclear. Does it refer to recommendation in this ID 
relevant to caching clients? If so, link to section.

>    "just-use-8" or "just-use-16" (as in UTF-16 [UNICODE  <https://tools.ietf.org/html/draft-williams-filesystem-18n-00#ref-UNICODE>]), with no
>     attempt at normalization or case folding done anywhere in between.
In Unicode parlance: "just use strings of code units".

Specifically for UTF-8, this would imply that there are also no 
guarantees of well-formedness of the UTF-8 strings (likewise for 
surrogate pairs in UTF-16).

-- reached end of section 1 and out of time slot --

A./