Subject: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Apr 2012 17:34:01 +0200

Hi there,

right now, the draft escapes forward slashes in reference tokens using 
^-escapes, that is:

  a/b

becomes

  a^/b

and

  a^b

becomes

  a^^b

(Reminder: previously "\" was used, but it results in ugly double 
escaping when the pointer occurs in a JSON string).

A drawback of this scheme is that when the pointer is used inside a URI, 
such as the path component of a an HTTP URI, the / still needs to be 
escaped, so the name

   a/b

becomes the pointer

   a^/b

and would end up as

   a%5e%2fb

in the URI.

An alternate proposal I heard during the IETF meeting in Paris was to 
simply apply URI percent escaping to the characters in the URI 
gen-delims range:

  gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

so

   a/b

would simply become

   a%2fb

and wouldn't need any further escaping in a URI path component.

Feedback appreciated,

Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Apr 2012 17:52:38 +0200

On 2012-04-12 17:49, Joe Hildebrand wrote:
> I really like this.  Would you unescape *all* %-encoded, or just the ones in
> that list?  What about escape sequences that lead to invalid UTF-8, for
> example?
> ...

Assuming that your question refers to the process of retrieving a 
sequence of reference tokens from a URI path...

I would

1) separate into URI path segments (using "/" as delimiter)

2) for each path segment, percent-unescape-then-UTF8-decode to obtain 
the reference token

Best regards, Julian

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 12 Apr 2012 09:21:31 -0700

This takes us back to a previous version of JSON Pointer, which in fact
did use URI escaping of %2F to distinguish between the '/' token
delimiter and a '/' character within a token. IIRC, the objections that
lead us to change were:

1. It requires URI decoding logic in non-URI-processing code (e.g. when
pointers are used in JSON strings rather than in URI fragment
identifiers). This has always been a somewhat weak argument, IMO.

2. Some URI parsers normalize the URI (i.e. expand %2F into '/') before
any JSON Pointer parsing code can get a chance to see it.

In response to this, I went down the path of using a single escape
character. If we can overcome these objections, I'd be happy to
entertain returning to URI escaping.

Paul

On Thu, 2012-04-12 at 17:34 +0200, Julian Reschke wrote:

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

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 13 Apr 2012 09:27:09 +1000

> and wouldn't need any further escaping in a URI path component.

Not true. The % then needs escaping when you put the JSON pointer in a URI.

  a%252fb

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 13 Apr 2012 14:04:55 +1000

If we really want URL-friendly escapes for JSON pointers pick '~' as the escape character. Use '~0' and '~1' as escapes for a '~' and '/' in a JSON member name respectively. If we want a different separator (eg ';') to distinguish arrays vs objects in pointers, escape it as '~2'.

{ "a/b": true, "c~d": false, "d":{"e":null}, "f;g":null, "h":[100,200] }

JSON pointers to items in the above JSON value could be:
  /a~1b
  /c~0d
  /d/e
  /f~2g
  /h;0

These 5 can go in a URI query parameter or fragment without any %-escaping.
You still need URI %-escaping for other characters (eg for pointer "/<hi>" to fragment "#/%3Chi%3E") so the receiver always needs to do %-unescaping, but there should be less confusion between JSON pointer and URI layers. It is mostly harmless to apply %-escaping more than necessary (eg it doesn't matter whether or not the pointer "/a~1b" is put in a URI fragment as "#/a~1b" or "#%2fa~1b" or "#%2fa%7eb").

--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Apr 2012 09:12:20 +0200

> Not true. The % then needs escaping when you put the JSON pointer in a URI.

No. The whole idea is to produce a string that can be used as a valid 
URI path directly.

Best regards, Julian

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 12 Apr 2012 09:49:22 -0600

-- 
Joe Hildebrand

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 12 Apr 2012 10:12:28 -0600

> 2) for each path segment, percent-unescape-then-UTF8-decode to obtain

That makes sense.

-- 
Joe Hildebrand