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

John C Klensin <john-ietf@jck.com> Tue, 10 May 2016 16:06 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A79812D500; Tue, 10 May 2016 09:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPAAnBIm8AlI; Tue, 10 May 2016 09:06:41 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C77C12B03F; Tue, 10 May 2016 09:06:41 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1b0AB7-000AtO-Od; Tue, 10 May 2016 12:06:33 -0400
Date: Tue, 10 May 2016 12:06:28 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Julian Reschke <julian.reschke@gmx.de>, Matthew Kerwin <matthew@kerwin.net.au>
Message-ID: <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com>
In-Reply-To: <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp>
References: <570D4C99.1030405@dcrocker.net> <CACweHND-OX+5okkJ+oE=6UN84x+CFtPBpMnU8HqaPbgQgJ_oWA@mail.gmail.com> <570E2510.4040408@ninebynine.org> <CACweHNCLS+QU2QveqYjkuPnDybbm-dtX9qQPsO4tTkgUoc5QYg@mail.gmail.com> <5710953E.5040505@gmx.de> <CACweHNDuDnP4P-4suUaFpS0OX-CbAYxn39jsZ3O_s-KYn=qbKw@mail.gmail.com> <a16b7cf5-3635-a3cb-b743-850f4047f862@gmx.de> <B3F27B33707E397A452D158D@JcK-HP8200.jck.com> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/D5o9GvI1pe8VeDpEvI-o6OO0gEg>
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, draft-ietf-appsawg-file-scheme@ietf.org
Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2016 16:06:42 -0000


--On Tuesday, May 10, 2016 19:19 +0900 "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> 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.

   john