Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme

[Ned Freed <[e-mail]>]

> --On Tuesday, May 10, 2016 19:19 +0900 "Martin J. Dürst"
> <[e-mail]> wrote:

> > In general, NFC gives you a higher chance for a match that
> > NFD. The Mac filesystem uses (mostly) NFD internally, but is
> > able to handle NFC. On the other hand, Windows and Linux don't
> > do normalization inside the file system, but the chances that
> > files were created in NFC is higher than for NFC.

> Agreed.  But note that this is partially an artifact that
> illustrates why the i18n / "multilingual" versus localization
> issues are important.    NFC gives a higher chance for a match,
> especially with strings that are not systematically normalized
> because, if one is using a keyboard designed for a particular
> language or location, that keyboard is likely to support
> locally-used characters and hence far more likely to product
> precomposed characters than combining sequences.  The same is
> generally true when people select characters from some sort of
> online character-picker, assuming the precomposed forms exist at
> all.   On the other hand, if I'm an experience user of one
> script trying to use a keyboard designed for a wildly different
> script or one with too many distinct character forms
> ("graphemes" or "grapheme clusters") to allow single-stroke
> arrangements to work well, all bets are off.

> For some scripts, there are also what look from the outside like
> internal consistency problems with Unicode: for example, NFD is
> more internally consistent then NDC because many recently-added
> precomposed characters decompose under NFC rather than
> composing.  And some don't, leading to some of the problems that
> led to the "non-decomposable character" mess that led to the
> LUCID BOF and the IETF's apparent paralysis about Unicode 7.x.

> It is hard to say something in cases like this that will always
> deliver the best, or even the most-expected, results.

I'm trying, but I find it difficult to have much sympathy here. The underlying
problem is that repeated applications of the "this is a tiny bit better for
this constituency so we must have it or at least allow for it" rule in this
space has led to a situation where no single best practice exists.

If this sounds like we've reached a distinctly suboptimal pareto optimum, it's
because that's exactly what has happened.

I therefore think the best thing is to document the situation as best
we can and be done with it. This is supposed to be a specification
for a URL scheme; there's no reqruiement that such documents also serve
as a BCP.

				Ned