Re: [I18ndir] I-D on filesystem I18N

[Nico Williams <[e-mail]>]

On Tue, Jul 07, 2020 at 08:27:36AM -0400, John C Klensin wrote:
> --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.

For filenames and paths I believe there are only display issues.  That
was Patrik's point.  Thus the I-D should say as much and normatively
reference Unicode.

And yes, the display is absolutely not in scope for an I-D that provides
advice to designers of filesystem protocols and implementors of those
and filesystems!  Both of those are far from the display action.  And
from user input too, for that matter.  There is nothing we can say to
them that will alter anything about input and display.  Therefore it is
appropriate and correct to leave display (and input) issues out of
scope.

> >...
> >> 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.,
> 
> [...]

This is only for case insensitivity.  In filesystems.  I don't think
there will be too much trouble.  We can offer alternatives, but I think
we should follow what Unicode says.

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

My I-D is the result of my writing an early review of an external I-D
that I was assigned by a directorate chair to review.  You might even
recall pointedly telling me to write one if I wanted the issues in
question addressed (I already had written it, just not submitted it).

To answer your question, I believe the chairs can and should a) assign
individual directorate members to review each document that comes to the
group and each document by members of the group, b) cajole others to do
their own reviews as well.

As I understand it, the chairs are currently not available, so in
further answer to your question, unless we self-organize, it may be a
few more weeks before we get assignments to review the I-Ds you listed.

As to self-organization, I don't mind trading a review of some of the
above-mentioned I-Ds if that's what it takes to get more review of mine.

Nico
--