Subject: [apps-discuss] Confusing JSON Pointer

From: 지송원 James Songwon Chi <[email-masked]>
Date: Tue, 27 Mar 2012 14:22:05 +0900

After reading JSON Pointer (draft-ietf-appsawg-json-pointer-01), I am
confused with encoding or escape scheme.
For me, it is an ambiguous scheme. For example, a reference token
"ref/1" can be expressed following ways:

1) If it is a URI fragment identifier and a JSON Pointer
     Step 1. apply URI encoding: ref%5C1
     Step 2. apply JSON Pointer encoding:  ref%5C1
     Final result: ref%5C1

2) If it is a JSON Pointer and a URI fragment identifier
     Step 1. apply JSON Pointer encoding: ref^/1
     Step 2. apply URI encoding:  ref^%5C1
     Final result: ref^%5C1

I expected the same results.

And if my interpretation is wrong, to prevent the similar question,
there should be some examples for this kind.

James

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Mar 2012 09:57:50 +0200

On 2012-03-27 07:22, 지송원 James Songwon Chi wrote:
> ...

I don't understand the question.

The spec states how to put JSON Pointers (^-escaping) into fragment 
identifiers (%-escaping).

As far as I can tell the outcome then is what you have under 2), no?

Best regards, Julian

---

From: 지송원 James Songwon Chi <[email-masked]>
Date: Tue, 27 Mar 2012 22:49:12 +0900

> As far as I can tell the outcome then is what you have under 2), no?

Thank you Julian for the reply.
Yes. Answer is 2) for above question. Well, but I gave a wrong
question and a wrong example (And solidus is 0x2F, not 0x5C.)

This is corrected one:

If I want a JSON Pointer to be represented as both a JSON String and a
URI fragment identifier, I should apply three encoding scheme.
There are two sequences with example:

1) step 1. JSON Pointer escape:  ref^/1
    step 2. JSON String escape:    ref^\/1
    step 3. URI encoding:              ref^\%2F1

2) step 1. JSON Pointer escape: ref^/1
    step 2. URI encoding:              ref^%2F1
    step 3. JSON String escape:    ref^%2F1

The results are same except  only when there is a solidus and it is
encoded as '\/' during JSON String encoding.
As in the example, ref^/1 becomes either ref^\%2F1  or  ref^%2F1 ( differs '\').

Note that JSON String allows multiple encodings for a character.  For
a soldus(/) there are four possible encodings -  '/', '\/', '\u002F',
and '\u002f'.  Also URI encoding allows multiple encodings in case of
percentage encoding - %2F and %2f.

Any comment?

James

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Mar 2012 16:23:02 +0200

On 2012-03-27 15:49, 지송원 James Songwon Chi wrote:
> 2012년 3월 27일 오후 4:57, Julian Reschke<[email-masked]>님의 말:

You convert *either* to a string *or* to a URI fragment. Never both.

Best regards, Julian

---

From: 지송원 James Songwon Chi <[email-masked]>
Date: Wed, 28 Mar 2012 08:47:41 +0900

> You convert *either* to a string *or* to a URI fragment. Never both.
I don't agree with you. First, there is no such words.
Second, if it is used in a JSON Schema as a "$ref" value, it should be
both JSON String and URI.

By the way, do we really *need another escape* even there are two
encodings already?

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 27 Mar 2012 18:36:27 -0700

> both JSON String and URI.

The intent of the draft is to establish rules for encoding in a JSON
string or in a URI. Of course, I agree that a URI can in turn be
expressed in a JSON string, but in this case, URI encoding applies; you
do not mix-and-match encodings.

> By the way, do we really *need another escape* even there are two

I'm not sure what you mean here. If you encode as URI, presumably all
valid URI characters are representable without any further escaping in a
JSON string.

Paul

---

From: 지송원 James Songwon Chi <[email-masked]>
Date: Wed, 28 Mar 2012 11:04:53 +0900

2012년 3월 28일 오전 10:36, Paul C. Bryan <[email-masked]>님의 말:
> The intent of the draft is to establish rules for encoding in a JSON string
> or in a URI. Of course, I agree that a URI can in turn be expressed in a
> JSON string, but in this case, URI encoding applies; you do not
> mix-and-match encodings.
>
>
> I'm not sure what you mean here. If you encode as URI, presumably all valid
> URI characters are representable without any further escaping in a JSON
> string.

We have URI encoding and JSON String encoding. Why do we need another
escape or encoding for JSON Pointer?

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

-- 
--
James Chi

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 27 Mar 2012 19:46:20 -0700

> escape or encoding for JSON Pointer?

JSON Pointer needs a separator character to separate reference tokens.
The slash '/' character has proven to be the most intuitive separator to
date. If this character appears in a token, however, it needs to be
escaped so as not to be interpreted as a separator.

Paul

---

From: 지송원 James Songwon Chi <[email-masked]>
Date: Wed, 28 Mar 2012 12:33:11 +0900

2012년 3월 28일 오전 11:46, Paul C. Bryan <[email-masked]>님의 말:
> We have URI encoding and JSON String encoding. Why do we need another escape
> or encoding for JSON Pointer?
>
>
> JSON Pointer needs a separator character to separate reference tokens. The
> slash '/' character has proven to be the most intuitive separator to date.
> If this character appears in a token, however, it needs to be escaped so as
> not to be interpreted as a separator.

I prefer '/' as a reference-token separator. What I don't like is
using a caret(^) as a escape character.
In the draft 00, the escape character was a reverse solidus(\) but it
is changed to caret(^) in draft 01.
Is there something that I missed?

--
James Chi

---

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

Hello Paul, others,

On 2012/03/28 10:36, Paul C. Bryan wrote:
>> 2012년 3월 27일 오후 11:23, Julian Reschke<[email-masked]>님의 말:

>>>>>> there should be some examples for this kind.

Can we please make sure that we add some example(s) and clarify the spec 
so that such questions can be avoided in the future?

> valid URI characters are representable without any further escaping in a

Can we please make sure this is as clear as possible in the spec?

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Mar 2012 12:57:40 +0200

On 2012-03-28 05:33, 지송원 James Songwon Chi wrote:
> 2012년 3월 28일 오전 11:46, Paul C. Bryan<[email-masked]>님의 말:

Using "\" would be awkward, because it would appear as "\\" in a JSON 
string.

Best regards, Julian

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 28 Mar 2012 22:06:49 -0700

> so that such questions can be avoided in the future?

Yes, for sure.

> Can we please make sure this is as clear as possible in the spec?

Sure, but I'd appreciate suggestions. Would it be best to outright state
what I did above?

Paul