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

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Jun 2013 10:44:34 -0700

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"
* "\/"
* "/"

---

From: Stefan Drees <[email-masked]>
Date: Tue, 11 Jun 2013 20:10:26 +0200

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
> ==========
> 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 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.
>

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.

---

From: "Markus Lanthaler" <[email-masked]>
Date: Tue, 11 Jun 2013 20:21:47 +0200

> where I propose to use "name" and "names" respectively instead.

+1, was just about to say the same.: So both proposals should be changed to

For the purpose of establishing equality of names within an object... to the
characters in names...

--
Markus Lanthaler
@markuslanthaler

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Jun 2013 11:26:46 -0700

On Jun 11, 2013, at 11:10 AM, Stefan Drees <[email-masked]> wrote:

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

Yipes, very good catch.

--Paul Hoffman

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 11 Jun 2013 22:37:37 +0000

>For example, the following four keys MUST be considered equivalent:

I'd like to suggest adding some names that are not equivalent as well,
like:

"\u212B" (ANGSTROM SIGN: Å)
"\u00C5" (LATIN CAPITAL LETTER A WITH RING ABOVE: Å)
"A\u030A" (LATIN CAPITAL LETTER A, COMBINING RING ABOVE: Å)
"\u00E5" (LATIN SMALL LETTER A WITH RING ABOVE, å)

and if we could put *&!@# non-ASCII7 characters in an RFC, that would
actually make sense to the reader.

-- 
Joe Hildebrand

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Jun 2013 15:40:36 -0700

<no hat>

> "\u00E5" (LATIN SMALL LETTER A WITH RING ABOVE, å)

-1. Both of the proposed texts are clear on not case and normalization, aren't they?

> actually make sense to the reader.

OK, so -2 now. :-)

--Paul Hoffman

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 12 Jun 2013 10:02:14 +0900

I prefer the second proposal (no surprise, I proposed it, and you can 
find the reasons for why I prefer it in the mail where I proposed it).
Of course, fixing key/keys to name/names to align terminology as pointed 
out by Stefan is great.

Regards,   Martin.

On 2013/06/12 2:44, Paul Hoffman wrote:
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Jun 2013 08:38:35 +0200

> For example, the following four keys MUST be considered equivalent:

-- This uses equal and equivalent as if they are equivalent.
   Note that 2.2 uses "unique", which doesn't quite connect to this text.

-> I would prefer to have a complete proposal that covers the 
   sentence in 2.2 as well and makes sure they connect.

-- Talking about "modification" confuses me.  
   Of course, there is no modification; 
   it is not OK to turn {"A": 1} into {"a": 1} in the parser, 
   or {"\u212b": 1}*) into {"Å": 1}.
   Is this still about the equality check?  Not at all clear to me.

-> Make it clear that this is just reinforcing the numeric comparison of code points.

-- Are "ab" and "ba" equivalent?  They use the same numeric character code points.

-> Say something about comparing the sequences in order.

And, of course, s/key/name/ (equality of names in objects, or really, uniqueness of names in objects).

Grüße, Carsten

*) (had to write the escape: my mail client normalizes the Angstrom sign under my fingers, WTF).

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Jun 2013 07:04:35 -0700

You talk about "prefer", but you don't say whether or not you can live with any of the alternatives.

You also talk about some ideas without giving specific wording.

Please see the introductory text of the message. :-)

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Jun 2013 17:58:57 +0200

> You talk about "prefer", but you don't say whether or not you can live with any of the alternatives.

These are all editorial comments, so I can live with anything*).
(On the technical level, we have consensus on comparing the sequences of Unicode code points.)

> You also talk about some ideas without giving specific wording.

I don't talk about ideas at all, I just point out where the proposed specific wording doesn't quite work.
I'll leave it to the native speakers to fix that.  
In particular, I trust that our esteemed editor can do that much better than I can.
(And I trust that he will transcend us if we try to micromanage him.)

(I sure can generate some clumsy wording for all of this, but I don't want to increase the number of proposals on the table.  Obligatory xkcd: http://xkcd.com/927/‎)

Grüße, Carsten

*) As long as it is not:

10 Let A be the first name, and B be the second name.
20 Let Aseq be the sequence of code points in A, and Bseq the sequence of code points in B.
30 If Aseq is empty, and Bseq is empty, return true.
40 If Aseq is empty, and Bseq is non-empty, return false.
50 If Aseq is non-empty, and Bseq is empty, return false.
60 If the first code point of Aseq is not equal to the first code point in Bseq, return false.
70 Replace Aseq by the sequence of all code points but the first in Aseq.
80 Replace Bseq by the sequence of all code points but the first in Bseq.
90 GOTO 30

READY

---

From: Pete Resnick <[email-masked]>
Date: Wed, 12 Jun 2013 19:38:46 -0500

I am speaking here solely as a participant. I just have a couple of 
suggestions on this topic:

On 6/11/13 12:44 PM, Paul Hoffman wrote:

[Both proposals:]
> For purpose of establishing key equality, comparisons MUST be conducted, after all unescaping is done, by comparing numeric character code points.
>    
I think the passive construction is really confusing, and in this case 
it took me multiple re-readings to figure out what it was trying to say. 
So I'd like to suggest (including changing "key" to "name"):

"For purpose of establishing name equality, implementations MUST first 
do all unescaping and then MUST compare numeric character code points."

Assuming that's what was meant. That was my guess after much re-reading.

As for the rest:

> Proposal 1
> ==========
> There is to be no modification of any kind to the characters in keys, including case-changing or combining-form normalization.
>
> Proposal 2
> ==========
> 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.
>    

I actually prefer proposal 1. This sentence is simply reinforcing the 
first sentence, which has the actual requirements. If you really want 
requirements language, again I'd prefer a non-passive construction:

"Modifications MUST NOT be made to the characters in the names when 
doing comparisons, such as change of case or change between precomposed 
and decomposed forms of the characters."

But again, just my preference.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478