Subject: [apps-discuss] #1: json-pointer internationalisation

From: Mark Nottingham <[email-masked]>
Date: Wed, 30 May 2012 15:44:38 +1000

<http://trac.tools.ietf.org/wg/appsawg/trac/ticket/1>

I think this issue has been taken care of in the latest draft:

>    A JSON Pointer is a [Unicode
> ] string containing a sequence of zero or
>    more reference tokens, each prefixed by a '/' (%x2F) character.
> 
>    If a reference token contains '/' (%x2F) or '^' (%x5E) characters,
>    such characters MUST each be prefixed (escaped) with a '^' (%x5E)
>    character.
> 
>    ABNF syntax:
> 
>    json-pointer = *( "/" reference-token )
>    reference-token = *( unescaped / escaped )
>    unescaped = %x00-2E / %x30-5B / %x5D-10FFFF
>    escaped = "^" ( "/" / "^" )

<http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-01>

and therefore can be closed. Make sense?

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 May 2012 08:38:23 +0200

> and therefore can be closed. Make sense?

+1

Best regards, Julian

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 30 May 2012 03:10:24 -0700

> unescaped = %x00-2E / %x30-5B / %x5D-10FFFF

It should read:

unescaped = %x00-2E / %x30-5D / %5F-10FFFF

Paul

On Wed, 2012-05-30 at 15:44 +1000, Mark Nottingham wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2012 11:36:47 +1000

Fixed, thanks.

Question: JSON allows characters to be represented in a few ways; e.g., "\\" and "\u005C" and "\u005c" are equivalent, according to section 2.5. 

Does pointer need to account for this?

Cheers,

On 30/05/2012, at 8:10 PM, Paul C. Bryan wrote:

>> <http://trac.tools.ietf.org/wg/appsawg/trac/ticket/1
>> >
>> 
>> <
>> http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-01
>> >
>>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 31 May 2012 12:20:14 +1000

> Does pointer need to account for this?

No.
Pointer uses the logical JSON values after any escaping in a serialization is removed.

Tools creating a pointer from a serialized JSON value do need to be careful about this, though. Unnecessarily (and hence unexpectedly) escaping "^" in a JSON serialization as "\u005E" could well trip up some (imperfect) pointer code. Including some examples using escaping in draft-ietf-appsawg-json-pointer-01 would be a good response.

Example value: {"2\u005E3":8}
Pointer: /2^^3

--
James Manger

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2012 12:22:49 +1000

> Pointer uses the logical JSON values after any escaping in a serialization is removed.

That seems like a perfectly reasonable position to take, but where is it reflected in the draft?

Currently, all we say is:

> The member name is equal to the token if it
>       has the same number of Unicode characters as token and their
>       codepoints are positionwise equal. 

Thanks,

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 31 May 2012 12:58:44 +1000

> >> Question: JSON allows characters to be represented in a few ways;
> e.g., "\\" and "\u005C" and "\u005c" are equivalent, according to
> section 2.5.
> >>

Uhmm… use of logical (not serialized) string values is implied by being the only sensible approach. Perhaps that is not quite precise enough for a spec, particularly as it talks about "JSON text document" and the N does stand for "Notation".

How about changing
  "…the object member with the name identified by the reference token"
To
  "…the object member with the name (after unescaping any backslash escape sequences that can occur in a JSON string) identified by the reference token"

And/or just add enough examples with escapes for anyone to work it out.

--
James Manger

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2012 13:04:30 +1000

> Uhmm… use of logical (not serialized) string values is implied by being the only sensible approach. Perhaps that is not quite precise enough for a spec, particularly as it talks about "JSON text do…

Huge interop problems have been built on smaller assumptions. 

It'd be just as reasonable to say that it should be the serialisation in the document, because it has performance impact (not that I'm asserting that, or have quantified it, but it's an easily imaginable justification).

>  "…the object member with the name (after unescaping any backslash escape sequences that can occur in a JSON string) identified by the reference token"

Seems like a good start.

> And/or just add enough examples with escapes for anyone to work it out.

Examples are important, but we shouldn't rely upon them to specify behaviour.

Cheers,