Re: [Json] Consensus call: establishing name equality

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 24 June 2013 06:18 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED36321E80B8 for <json@ietfa.amsl.com>; Sun, 23 Jun 2013 23:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.971
X-Spam-Level:
X-Spam-Status: No, score=-102.971 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIXxBO-d57F9 for <json@ietfa.amsl.com>; Sun, 23 Jun 2013 23:18:29 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1D81721E80B3 for <json@ietf.org>; Sun, 23 Jun 2013 23:18:28 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5O6IP2a004531; Mon, 24 Jun 2013 15:18:25 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 22e5_17b5_e0ce013a_dc95_11e2_ae55_001e6722eec2; Mon, 24 Jun 2013 15:18:25 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 66DA8C0002; Mon, 24 Jun 2013 15:16:59 +0900 (JST)
Message-ID: <51C7E49C.5040401@it.aoyama.ac.jp>
Date: Mon, 24 Jun 2013 15:18:04 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John Cowan <cowan@mercury.ccil.org>
References: <DB211AD8-6BBA-4D95-9B6E-F00AA69E584E@vpnc.org> <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> <CAO1wJ5SzsOvj2voaeM83G2FxmEwBSREHP5YtE5T8G-mgoM4jNw@mail.gmail.com> <CAHBU6iv8wGJQGpsswSf0GgkN6uQAXP8XFRbabjzWnNSJoifQzw@mail.gmail.com> <CAO1wJ5S7gvqJUydhfUkweffOxm+DcnEgZVciUVvnzj2gHYrAow@mail.gmail.com> <CAHBU6is5OVK6jVB_=Lu1W0RPEF1+f0wG1GZU44OQ1vbgP8vGgw@mail.gmail.com> <CAO1wJ5TV1f0G-WHKnO33TAjSVa2v77vm2kX=otTycyUFZf66pw@mail.gmail.com> <20130622005014.GA31186@mercury.ccil.org>
In-Reply-To: <20130622005014.GA31186@mercury.ccil.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Tim Bray <tbray@textuality.com>, Carsten Bormann <cabo@tzi.org>, Jacob Davies <jacob@well.com>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Consensus call: establishing name equality
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2013 06:18:36 -0000

On 2013/06/22 9:50, John Cowan wrote:
> Jacob Davies scripsit:
>
>> C6 A process shall not assume that the interpretations of two
>> canonical-equivalent character sequences are distinct.
>
> JSON, like XML, does not assume they are distinct: it decides that they
> are distinct.  This is what in Unicode is called a higher-order protocol.

This is just playing with words. In the general use of the words, I'd 
think that "decide" is a specific(ally narrow) version of "assume". And 
just as a higher-order protocol would be extremely ill-advised to treat 
upper-case and lower-case characters as distinct in a situation where 
the two get converted into each other all the time, the same applies 
here. I don't remember having seen the phrase "higher-order protocol" 
anywhere near or in relationship to C6; if you have, I'd appreciate you 
telling me where.

The truth of the matter is that C6, to a large extent, is based on 
wishful thinking: Canonically equivalent strings are one and the same, 
and software may and will convert from one normalization form to another 
at almost every corner, so you're never sure which one you get, and 
better don't bet on getting one or the other.

In actual practice, the kinds of software that changes character 
normalization has turned out to be few and far between. The MacIntosh 
file system is (one of) the exception(s) that proves the rule. In 
particular, there are no known instances of changes of character 
normalization during network transit, which is what's most important for 
us here.

Regards,   Martin.