Re: [apps-discuss] draft-pbryan-zyp-json-pointer: name syntax for non-ASCII

[Julian Reschke <[e-mail]>]

On 2011-11-22 10:33, Carsten Bormann wrote:
> On Nov 21, 2011, at 21:55, Mark Nottingham wrote:
>
>> +1 to Julian here -- there's no reason why non-ASCII chars need to be percent-encoded when they occur inside a JSON document, only when they're in a URI (or similar context).
>
> OK, folks, let's see where that leads to.
>
> JSON document:
> {"Bjørn/Carsten": "Fritz"}
>
> JSON pointer:
> "/Bjørn%2FCarsten"
>
> Multi-segment URI-encoded version of this JSON pointer:
>
> /Bj%C3%B8rn%252FCarsten
>
> (For reference: Plain URI-encoded version:
>
> %2FBj%C3%B8rn%252FCarsten
> )
>
> If this is what you want, please document it thoroughly, clearly, painfully redundantly.
> Dozens of examples, including examples that show how to do it wrong.
>
> With this kind of dual-layer percent-encoding, we are deeply in quoting hell, and implementers will need all the help we can give them (and they will still get it wrong).
>
> Grüße, Carsten

Indeed.

To add to the coverage, we should also consider whitespace and non-BMP 
characters:

JSON document:
{"Bjørn/Carsten/foo \uD834\uDD1E": "Fritz"}

JSON pointer:
"/Bjørn%2FCarsten%2Ffoo(X)(Y)"

(X) right now would be %20. Should it? Why escape it here already? (this 
applies to all characters that are currently disallowed expect '/' and '%')

(Y) imho should be the Unicode code point U+1D11E 
(<https://tools.ietf.org/html/rfc4627#section-2.5> has this example

So yes, the fact that a JSON name can be anything a JSON string can take 
is indeed a problem, because it doesn't leave us any characters as 
delimiters (so this is very different from XML vs XPath).

Best regards, Julian