Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS

Stefan Drees <stefan@drees.name> Tue, 11 June 2013 18:10 UTC

Return-Path: <stefan@drees.name>
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 E471B21F947C for <json@ietfa.amsl.com>; Tue, 11 Jun 2013 11:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 Z0z3-GgIins1 for <json@ietfa.amsl.com>; Tue, 11 Jun 2013 11:10:31 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id DA65421F9420 for <json@ietf.org>; Tue, 11 Jun 2013 11:10:30 -0700 (PDT)
Received: from newyork.local.box ([77.13.213.234]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0LqlF4-1U8TdR3gjS-00eHld; Tue, 11 Jun 2013 20:10:28 +0200
Message-ID: <51B76812.6050307@drees.name>
Date: Tue, 11 Jun 2013 20:10:26 +0200
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org>
In-Reply-To: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:lSszKY351TxrHyv/qwx/7HQz+3//EPsst0FSpsTm1Z+5mgtwZ6M dxA1Uatz7bPUtOSCwLPvfdQFAcUCRpjDkmT+fXBUzhBvPIp3O6aiJzPiFu8dG/Rj4j1SjB7 EWg2ORutSxsmtVYHvEtkiOXSBDCwoJkzmRpLiQXCryAPL7AHQPbv/P88smspRAnTAzAozMA ugIDT1KTqhbvJQ94n7Zlw==
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stefan@drees.name
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: Tue, 11 Jun 2013 18:10:37 -0000

On 2013-06-11 19:44 CEST, Paul Hoffman wrote:
> Greetings again. The following thread has died off, with two
> proposals. If none of "leave the text in the draft as-is" or the
> following proposals would be acceptable to you, please propose specific
> text that would be acceptable.
>
> --Paul Hoffman
>
> Proposal 1
> ==========
> In Section 2.5. Strings, immediately before the ABNF add:
>
> For purpose of establishing key equality, comparisons MUST be
> conducted, after all unescaping is done, by comparing numeric character
> code points. There is to be no modification of any kind to the
> characters in keys, including case-changing or combining-form normalization.
>
> For example, the following four keys MUST be considered equivalent:
>
> * "\u002F"
> * "\u002f"
> * "\/"
> * "/"
>
> Proposal 2
> ==========
> In Section 2.5. Strings, immediately before the ABNF add:
>
> For purpose of establishing key equality, comparisons MUST be
> conducted, after all unescaping is done, by comparing numeric character
> code points. There MUST NOT be any modification of any kind to the
> characters in keys, including change of case or change between
> precomposed and decomposed forms.
>
> For example, the following four keys MUST be considered equivalent:
>
> * "\u002F"
> * "\u002f"
> * "\/"
> * "/"
>

I do not know what the most convenient form of the proposal I want to 
make in this case is:
In both proposals above (1 and 2) the terms "key" and "keys" are used, 
where I propose to use "name" and "names" respectively instead.

We had IMO a lot of "whishful thinking" lately that seemed to start by 
replacing the word "name" in the current JSON RFC with "key" and based 
on this transform some participants were trying to go further and 
further until maybe the paradise of uniqueness constraints finally would 
have been reached by all of us ;-)

All two occurences of the term "key" inside the RFC 4627 are related to 
RFC2119 unless I overlooked something. JSON uses the term "name" for the 
first part of those pairs that form the members of objects.

So I'll give a parametrized proposal form a try, but please advice me if 
there is a better way to accomplish this:

Proposal 3
==========

Use either the Proposal 1 or Proposal 2 but with the paragraph beginning 
as "For purpose" having replaced the terms "key" and "keys" with the 
terms "name" and "names" respectively wherever they occur therein.

All the best,
Stefan.