Re: [Json] [apps-discuss] JSON mailing list and BoF

[Mike Jones <[e-mail]>]

As background, the JOSE specs require that equality comparisons for members be done as a comparison of Unicode code points, with no normalization or case folding performed.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-8.3.

                                                                -- Mike

From: [e-mail] [mailto:[e-mail]] On Behalf Of Paul C. Bryan
Sent: Tuesday, February 19, 2013 4:18 PM
To: [e-mail]
Subject: Re: [Json] [apps-discuss] JSON mailing list and BoF

Should two representations of the same JSON (string) value be c14n'ed differently? I think not*.

If not, then I think comparisons would need to occur by parsing JSON strings into Unicode codepoints.

Paul

* Why not? Mostly because I foresee many operations such as signature verification occurring on already-parsed JSON values, so how it was represented when it was serialized should (ideally) be moot.

On Tue, 2013-02-19 at 16:02 -0800, Tim Bray wrote:
Yes, I guess I did sort of strawman-suggest banning \uxxxx.  Which clearly doesn't fly.  So, two suggestions:

- \uxxxx is only allowed for chars that must be escaped per the JSON spec
- \uxxxx is freely allowed, but the \uxxxx is considered to represent a single codepoint, and all comparison/hashing operations have to be conducted codepoint-by-codepoint

I think I probably support the first, because it does allow comparison using strcmp() or equivalent. That's assuming that c14n is in fact worth doing. -T


On Tue, Feb 19, 2013 at 3:52 PM, Joe Hildebrand (jhildebr) <[e-mail]<mailto:[e-mail]>> wrote:
Nor was I suggesting we do so.

I was suggesting that if you want to get \u0000 - \u001f, excluding
\u0008(\b), \u0009(\t), \u000a(\n), \u000c(\f), and \u000d(\r) into the
canonicalized output, you have to use the \u notation, which means we
can't outlaw \u notation entirely in the canonicalized form, as some of us
thought Tim had suggested in the first place.

Note, I was wrong about \u0000 being the only codepoint we care about.
From section 2.5 of 4627:

"All Unicode characters may be placed within the
   quotation marks except for the characters that must be escaped:
   quotation mark, reverse solidus, and the control characters (U+0000
   through U+001F)."



On 2/19/13 4:42 PM, "Tim Bray" <[e-mail]<mailto:[e-mail]>> wrote:

>I haven¹t heard anyone saying U+0000 should be illegal in JSON.  It¹s too
>late to redesign JSON. -T
>
>
>
>On Tue, Feb 19, 2013 at 3:13 PM, Francis Galiegue
><[e-mail]<mailto:[e-mail]>> wrote:
>
>On Wed, Feb 20, 2013 at 12:08 AM, Joe Hildebrand (jhildebr)
><[e-mail]<mailto:[e-mail]>> wrote:
>[...]
>>>
>>>
>>>He means "\u0000 is an exception to Tim's proposed 'forbid escaping'
>>>rule".
>>
>> Exactly.  It's the only code point that I know of that MUST be escaped
>> using \uxxxx notation when serialized (either canonically or otherwise).
>> All of the other codepoints that need to be escaped have \x versions.
>>
>
>
>OK, but why should it be considered illegal at all? Any ASCII
>character is representable by such a sequence, it just happens that 0
>can where ASCII can't... I don't see this as a reason to outlaw this
>particular sequence... Or there is something I don't understand in
>your argument.
>
>--
>Francis Galiegue, [e-mail]<mailto:[e-mail]>
>Try out your JSON Schemas:
>http://json-schema-validator.herokuapp.com
><http://json-schema-validator.herokuapp.com>
>
>
>
>
>
>
>
>



--
Joe Hildebrand






_______________________________________________

json mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/json