Subject: [apps-discuss] draft-ietf-appsawg-json-pointer-00 feedback

From: Julian Reschke <[email-masked]>
Date: Wed, 04 Jan 2012 13:49:50 +0100

Hi Paul,

below some feedback:

Section 3:

>    ABNF syntax:
>
>    json-pointer = *( "/" reference-token )
>    reference-token = *( unescaped / escaped )
>    unescaped = %x00-2E / %x30-5B / %x5D-10FFFF

Is 0 really allowed? (I see JSON allows this as well; maybe that's 
something that needs to be discussed in the security considerations).

>    escaped = "\" ( "/" / "\" )
>
>    It is an error condition if a JSON Pointer value does not conform to
>    this syntax.

I'm fine with this because it allows using \ to escape more values in 
the future.

Section 4:

>       If the currently referenced value is a JSON array, the reference
>       token MUST contain an unsigned base-10 integer value, and the new
>       referenced value is the array element with the zero-based index
>       identified by the token.

Do we want to say something about leading zeroes in index values? I 
assume they are allowed?

Section 5:

>    A JSON Pointer MAY be represented in a JSON string value.  Per
>    [RFC4627], section 2.5, all instances of quotation mark '"' (%x22),
>    reverse solidus '\' (%x5C) and control (%x00-1F) characters MUST be
>    escaped.

The MAY is a statement of fact, not a normative requirement. Just say "can".

Section 6:

>    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.

See above.

Appendix A:

The semantics of fragment identifiers depends on the media type. You 
need to be clear whether you're trying to define the fragid semantics 
for application/json (which as far as I recall doesn't define any), or 
something else.

That being said:

>    http://example.com/example.json#
>       Resolves to the object value at the root of the JSON text
>       document.

The same would be true for

   http://example.com/example.json#/

right? I think we should stay away from empty fragment identifiers if we 
can. (There MAY be dragons here).

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 05 Jan 2012 10:42:56 +0900

> something that needs to be discussed in the security considerations).

So a JSON pointer like /// would mean there are four empty reference 
tokens. And that would actually work (pointing to 127) for a document 
like this:

{ "": { "": { "": { "": 127 } } } }

> I'm fine with this because it allows using \ to escape more values in

Anything needed to make this "more values in the future" work?

> Do we want to say something about leading zeroes in index values? I

If they are, probably better to point out that it still means decimal. 
Some scripting languages might take leading zeroes to mean octal if an 
implementer isn't careful.

> for application/json (which as far as I recall doesn't define any), or

Yes. I'd propose that you just say you do, and then add a line at the 
top saying that your RFC-to-be will update the JSON definition. You'll 
also have to note that in an IANA section.

> right?

If an empty reference token is allowed, then
http://example.com/example.json# would point to the data identified by 
the first "" object key. And http://example.com/example.json#/ would be 
two empty reference tokens, so it would point to one level down. If we 
have a document of
   { "": { "": 127 } }
then http://example.com/example.json# would point to { "": 127 } and 
http://example.com/example.json#/ would point to 127. The question then 
is what to use to denote the whole document/object. The absence of a 
fragment identifier (i.e. just http://example.com/example.json) might 
work just fine.

On the other hand, if empty reference tokens are disallowed, 
http://example.com/example.json#/ is illegal and 
http://example.com/example.json# is illegal too, unless we add it to the 
grammar with a special meaning.

> I think we should stay away from empty fragment identifiers if we

At least, we have to define them in a consistent way.

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 05 Jan 2012 11:08:35 +0100

On 2012-01-05 02:42, "Martin J. Dürst" wrote:
> ...
 > ...

I have to say that I'm getting nervous about this.

1) When this WG adopted this as a work item, was it clear that JSON 
pointer isn't "a pointer syntax" but "*the* pointer syntax"?

2) Also, declaring this the one and only fragment identifier syntax for 
application/json means that we're closing the door for any future syntax 
that offers more expressiveness.

In XML, people tried to handle this problem with a whole framework 
(XPointer), which doesn't seem to work too well.

Maybe in this case the solution would be to reserve more delimiter 
characters that we'll likely need in the future (such as "[", "]", "(", 
")", double quotes, single quotes etc).

Best regards, Julian