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

From: [email-masked]
Date: Tue, 03 Jan 2012 15:56:37 -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
	Filename        : draft-ietf-appsawg-json-pointer-00.txt
	Pages           : 7
	Date            : 2012-01-03

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-pointer-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-json-pointer-00.txt

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 04 Jan 2012 15:24:01 +0900

A small nit:

OLD:
             this is performed by simply the '\' (escape)
NEW:
             this is performed by simply removing the '\' (escape)

More major stuff:

    If a reference token is being evaluated against a concrete JSON
    document...

Are there JSON documents that are not concrete? How do they look?

And immediately preceding that sentence, what happens if the currently 
referenced value is neither a JSON object nor a JSON array? I guess it 
should say that this is an error condition.

Choice of escape character: I think choosing "\" as the escape character 
is the right thing to do. There were other proposals such as U+FFFD or a 
character in the U+0000-001F range, but while they look clever in the 
spec, they are actually too clever: they may not be visible, and are 
difficult to type. If such characters were really a good idea as escape 
characters, then they would already be used that way :-(.

Section 5, JSON String Representation:

As far as I understand, this will lead to quadruple escaping. That's 
fine with me, but it would be good to have an example. What about:

For the following JSON object:

{ "ab\\cd" : { "ef/gh" : 127 } }

the JSON Pointer pointing to 127 is "ab\\cd/ef\/gh", consisting of the 
two reference tokens "ab\cd" and "ef/gh". Please note that in the above 
JSON object, there are two backslashes in "ab\\cd", but no backslash in 
"ef/gh", because JSON requires escaping for backslashes, but not for 
forward slashes, in strings.

The above JSON Pointer, "ab\\cd/ef\/gh", has to be escaped again when 
written as a JSON string: "ab\\\\cd/ef\\\/gh".

If I got it wrong, please correct. But please in any case add an example 
with explanations.

Section 6,  URI Fragment Identifier Representation

    A JSON Pointer MAY be represented in a URI fragment identifier.  The
    JSON pointer MUST be UTF-8 [RFC3629] encoded as octets; octets in the
    URI "unreserved" set SHOULD be percent-encoded, per [RFC3986],
    section 2.5.

Having to percent-encode the octets in the "unreserved" set would be 
hopelessly counterproductive. For the above example, it would produce 
something like:

"%61%62%5C%5C%63%64%2F%65%66%5C%2F%67%68"

The unreserved set is:
       unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
These are the most 'harmless' characters that never need escaping. (They 
can be escaped, but it's rarely, rarely done.)

Here's how I would rewrite section 6:

    When a JSON Pointer is used as a fragment identifier in an URI
    [RFC3986], any characters in a reference token that cannot
    appear literally in a fragment identifier, as well as a slash when
    appearing as part of a reference token, has to be escaped by
    converting it to a sequence of octets using UTF-8 [RFC3629] and
    percent-encoding [RFC3986] each octet.

    As an example, the JSON Pointer "ab\\cd/ef\/gh" becomes
    "ab%5Ccd/ef%2Fgh" as a fragment identifier. Please note that the
    URI syntax can distinguish between slashes used inside a reference
    token (written "%2F") and slashes used as reference token separators
    (written "/"); as a consequence, a backslash in a reference token
    only has to be escaped as "%5C" (and not "%5C%5C") because the
    backslash isn't needed as an escape character.

Again, if I got this wrong, please correct, but please include actual 
examples and explanations.

Regards,     Martin.

On 2012/01/04 8:56, [email-masked] wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 03 Jan 2012 23:11:24 -0800

>              this is performed by simply removing the '\' (escape)

Thanks. I removed "removed" instead of "simply" in a last-minute
revision. Fixed.

> Are there JSON documents that are not concrete? How do they look?

Good point.

> should say that this is an error condition.

+1.

> characters, then they would already be used that way :-(.

Yes, this one took some thought. Ultimately I wasn't thrilled with the
use of exotic Unicode characters for a number of reasons, including
avoiding inventing exotic solutions; most developers are familiar with
how to use backslash, and it's on every modern keyboard.

> If I got it wrong, please correct. But please in any case add an

Okay.

> "%61%62%5C%5C%63%64%2F%65%66%5C%2F%67%68"

Thanks for catching this mistake. I (again!) misquoted RFC 3986, missing
the double negative. Fixing.

>     backslash isn't needed as an escape character.

So while indeed it seems URIs do allow for the reserved character "/" to
be used as a subcomponent delimiter and %2F to be treated as a data,
having a different string syntax for representation in JSON string
values and fragment identifiers will almost certainly lead to
implementation complexity (and implementation errors). This is in fact
one reason we drove toward pure Unicode strings and only require URI
percent-encoding when encoding in a URI. This topic seems debatable
though.

> examples and explanations.

Thanks!

Paul