Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-06.txt

From: [email-masked]
Date: Tue, 04 Dec 2012 16:42:22 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : JSON Pointer
	Author(s)       : Paul C. Bryan
                          Kris Zyp
                          Mark Nottingham
	Filename        : draft-ietf-appsawg-json-pointer-06.txt
	Pages           : 8
	Date            : 2012-12-04

Abstract:
   JSON Pointer defines a string syntax for identifying a specific value
   within a JSON document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-pointer-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Dec 2012 11:52:31 +1100

Very small changes here based upon LC feedback; nothing to see, move along.

On 05/12/2012, at 11:42 AM, [email-masked] wrote:

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

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

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 5 Dec 2012 14:20:16 +1100

> Very small changes here based upon LC feedback; nothing to see, move

I noticed a bug in an implementation listed at http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch: unescaping ~0 to ~, before unescaping ~1 to / (so a ~ from the first unescaping is mistakenly treated as an escape character in the second unescaping).
It is a bug that could easily be repeated so one more example in draft-ietf-appsawg-json-pointer to cover this case would be worthwhile.

In section 5 "JSON String Representation" add:

Given the JSON doc:
  { "/": 9,
   "~1": 10 }
A pointer (as a JSON string) and value is:
  "/~01"  10

In the format of https://github.com/json-patch/json-patch-tests
   { "comment": "don't unescape ~0 separately before unescaping ~1",
      "doc": {
          "/": 9,
          "~1": 10 },
      "patch": [{"op": "test", "path": "/~01", "value":10}] },

> I think the best way to move them forward would be to raise issues in github -- do you mind doing that?

DONE

I also noticed a few implementations just use JavaScript’s parseInt() function to convert a segment in a JSON pointer (a <reference-token>) to an integer array index. Hence, they accept "/007" and "/  +0007zzz" as equivalent to "/7". Yuck. Perhaps add examples to the spec to explicitly show these are errors (so they make it into tests)?

--
James Manger

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 5 Dec 2012 10:40:58 +0100

Hi,

this probably something that has been asked before but I couldn't find
anything relevant.

How does JSON Pointer distinguish between objects and arrays? E.g. consider
the following JSON document:

{
  "foo": "bar",
  "1": "baz"
}

As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even
though that's probably not what the author intended. Is there are way to
avoid that?

Thanks,
Markus

--
Markus Lanthaler
@markuslanthaler

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, December 05, 2012 1:42 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-
> 06.txt
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Dec 2012 16:07:38 +1100

> I noticed a bug in an implementation listed at http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch: unescaping ~0 to ~, before unescaping ~1 to / (so a ~ from the first unescaping is mistaken…

Please log a bug with them, if possible (and if you haven't already done so).

> In section 5 "JSON String Representation" add:

OK, thanks.  Will add to the next rev.

> I also noticed a few implementations just use JavaScript’s parseInt() function to convert a segment in a JSON pointer (a <reference-token>) to an integer array index. Hence, they accept "/007" and…

How about just adding to the non-spec tests? This is implementation-specific, so I'd rather keep it out of the spec, I think.

Cheers,

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 6 Dec 2012 17:26:58 +1100

> > I also noticed a few implementations just use JavaScript’s parseInt()
> function to convert a segment in a JSON pointer (a <reference-token>)
> to an integer array index. Hence, they accept "/007" and "/  +0007zzz"
> as equivalent to "/7". Yuck. Perhaps add examples to the spec to
> explicitly show these are errors (so they make it into tests)?

> How about just adding to the non-spec tests? This is implementation-
> specific, so I'd rather keep it out of the spec, I think.

It seems no one does input validation. Argh!
I glanced at over half of the 8 implementations listed at http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch and didn't find a single one that checked that a JSON pointer segment was a valid array index before converting it to an integer.

Given that not one implementation validated the input seems like a strong reason to call more attention to it in the spec. For instance, stating "/+7", "/007", "/ 7", and "/7.0" are example of pointers that MUST NOT be accepted as array indices. Or perhaps provide a regex that a segment MUST match to be an array index: 0|[1-9][0-9]*.

All the implementations I glanced at just call a native function to convert a string to an integer.

The JavaScript code call parseInt.
The Python code calls int(), and isdigit().
The Ruby code calls to_i or Integer key.
The PHP code calls is_numeric.
The Java code calls Integer.parseInt().

All of these accept JSON segments that are not valid array indices: including leading whitespace, "+" signs, 0x hex values, decimal points, exponents, "_" digit separators, unnecessary leading 0's, trailing letters, and more.

--
James Manger

---

From: James M Snell <[email-masked]>
Date: Thu, 6 Dec 2012 10:57:45 -0800

On Wed, Dec 5, 2012 at 10:26 PM, Manger, James H <
[email-masked]> wrote:

> I glanced at over half of the 8 implementations listed at
> http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JsonPatch and didn't find
> a single one that checked that a JSON pointer segment was a valid array
> index before converting it to an integer.
>
> Given that not one implementation validated the input seems like a strong
> reason to call more attention to it in the spec. For instance, stating
> "/+7", "/007", "/ 7", and "/7.0" are example of pointers that MUST NOT be
> accepted as array indices. Or perhaps provide a regex that a segment MUST
> match to be an array index: 0|[1-9][0-9]*.
>
>
>
I'll eventually get proper validation added to the json-tools ruby impl. I
just haven't had much time to work on it. I'm not sure there's anything to
be gained in making the spec more explicit and strict on this point.

- James

> All of these accept JSON segments that are not valid array indices:
> including leading whitespace, "+" signs, 0x hex values, decimal points,
> exponents, "_" digit separators, unnecessary leading 0's, trailing letters,
> and more.
>
> --
> James Manger

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 7 Dec 2012 12:06:48 +1100

FWIW, I created:
  https://github.com/json-patch/json-patch-tests/issues/5