Subject: [apps-discuss] Review of draft-ietf-appsawg-json-pointer

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Nov 2012 07:24:28 -0800

This document mostly looks fine.

- I do not understand the use of "-"; at least one use of it in an application should be given.

- If "-" is useful, wouldn't it also be useful to have something that indicates the (non-existant) member before the first array element?

- Editorial nit in section 4:
      *  characters that represent an unsigned base-10 integer value
         (possibly with leading zeros), making the new referenced value
         is the array element with the zero-based index identified by
         the token, or
That should either be "the new referenced value is the" or "making the new referenced value the", I believe.

- One of the security considerations is too limited.
   Note that JSON pointers can contain the NUL (Unicode U+0000)
   character, which may not be representable in all programming
   languages.
The same is true for all control characters, and for some programming languages, all non-ASCII characters. Proposed rewording:
   Note that JSON pointers can contain the NUL (Unicode U+0000)
   character, control characters, non-ASCII characters, and so
   on. These characters may not be representable in all programming
   languages.

--Paul Hoffman

---

From: James M Snell <[email-masked]>
Date: Thu, 15 Nov 2012 09:27:44 -0800

On Thu, Nov 15, 2012 at 7:24 AM, Paul Hoffman <[email-masked]> wrote:

> - If "-" is useful, wouldn't it also be useful to have something that
> indicates the (non-existant) member before the first array element?
>
>
This came from a requirement with json patch to allow a way of appending
new array items to the end. This was fairly extensively discussed and
concluded that the - was the least-complicated option that met the
requirement.

- James

> The same is true for all control characters, and for some programming
> languages, all non-ASCII characters. Proposed rewording:

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Nov 2012 09:36:35 -0800

On Nov 15, 2012, at 9:27 AM, James M Snell <[email-masked]> wrote:

> This came from a requirement with json patch to allow a way of appending new array items to the end. This was fairly extensively discussed and concluded that the - was the least-complicated option that met the requirement. 

Understood. However, is there *no* reason to prepend something to the beginning of the list? Or is that done with "1"? (I admit not fully getting all the fun features of -patch).

--Paul Hoffman

---

From: James M Snell <[email-masked]>
Date: Thu, 15 Nov 2012 09:41:30 -0800

It's a zero-based array. With JSON patch, adding an item to the beginning
of the array would be done using {"op":"add", "path": "/a/b/0", "value":1},
which causes the new value to be inserted at position 0 and all existing
items to be shifted right.

On Thu, Nov 15, 2012 at 9:36 AM, Paul Hoffman <[email-masked]> wrote:

> Understood. However, is there *no* reason to prepend something to the
> beginning of the list? Or is that done with "1"? (I admit not fully getting
> all the fun features of -patch).
>
> --Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Nov 2012 10:39:50 -0800

On Nov 15, 2012, at 9:41 AM, James M Snell <[email-masked]> wrote:

> It's a zero-based array. With JSON patch, adding an item to the beginning of the array would be done using {"op":"add", "path": "/a/b/0", "value":1}, which causes the new value to be inserted at position 0 and all existing items to be shifted right. 

This is a good reason why I should not be a reviewer for -patch. :-)

Ignore my question for -pointer: the "-" is sufficient for patching.

--Paul Hoffman

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 16 Nov 2012 14:56:04 +1100

>    on. These characters may not be representable in all programming

The issue with NUL is that you need to be careful not to misinterpret it as an end-of-string marker. How about:

   Note that JSON pointers can contain the NUL (Unicode U+0000)
   character. Care is needed not to misinterpret this character
   in programming languages that use NUL to mark the end of a string.

And a reminder that there was one other just-before-WGLC comment: disallowing unnecessary leading 0's (eg allow /7, but not /007, to point into an array).

--
James Manger

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Nov 2012 15:17:42 +1100

>   in programming languages that use NUL to mark the end of a string.

In Security Considerations?

> And a reminder that there was one other just-before-WGLC comment: disallowing unnecessary leading 0's (eg allow /7, but not /007, to point into an array).

Yes. probably needs to make it into the ABNF.

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

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 16 Nov 2012 15:50:08 +1100

> > The issue with NUL is that you need to be careful not to misinterpret
> it as an end-of-string marker. How about:
> >
 
> In Security Considerations?

Yes. Treating NUL as end-of-string is more of a security issue than not being able represent some characters.

Bad guys stuck NULs in domain name fields in certificates (eg paypal.com<NUL>www.badguy.net). One party treats it as a (harmless) subdomain of badguy.net; another party is fooled into believing it is for paypal.com. Result: security failure.

Consider the pointer "/readonly\u0000abc" in a patch {"op":"remove", "path":"/readonly\u0000abc"} applied to a doc {"readonly":"MUST NOT BE TOUCHED", "anyone":"can change anything else"}. A security layer that properly handles NUL will allow the patch through; but a subsequent processor that isn't careful about NUL might treat the pointer as "/readonly" and disaster results.

About the only other security consideration I can think of is checking that an array index does not overflow a programs representation (eg don’t treat "/4294967297" as "/1", throw an error if necessary).

--
James Manger

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 16 Nov 2012 14:19:26 +0900

>     on. These characters may not be representable in all programming

I have to disagree here. There may indeed be programming languages that 
cannot handle non-ASCII characters. But these days, this means that they 
are very much fringe languages. On the other hand, there are also 
programming languages, or implementations of programming languages, that 
cannot handle ASCII (think EBCDIC machines).

The original warning, although it doesn't say so explicitly, is more or 
less specifically about string representation in C. C is an extremely 
widely used programming language, and its usual string representation 
takes the null byte to signal the end of a string.

So the warning essentially just reads: If you language happens to use a 
null byte to signal the end of a string (e.g. like in C) then you may 
have to be careful and invest additional effort (e.g. use a string 
library that handles null bytes, too). Same applies to wide strings and 
null 16-bit or 32-bit units.

So I don't think it's a good idea to widen this warning.

Regards,   Martin.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Nov 2012 17:12:13 +1100

In SVN.