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

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Jun 2012 12:41:24 +1000

This is <http://trac.tools.ietf.org/wg/appsawg/trac/ticket/4>.

I've tried to address them all with <http://trac.tools.ietf.org/wg/appsawg/trac/changeset/69>, except:

1) I haven't said anything about 0 being allowed; Julian, do you have a proposal for text in Security Considerations?

2) I haven't attempted to address the status of this being JSON's fragment identifier. 

Julian, you mentioned reserving more characters, but the downside there will be (potentially) making it more difficult to use with existing JSON that uses those characters. However, we *do* define an escape character; couldn't we just say that future escape sequences can be defined by updating this specification?

Cheers,

On 04/01/2012, at 11:49 PM, Julian Reschke wrote:

> 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
> 
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

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

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 27 Jun 2012 13:19:25 +1000

> we can. (There MAY be dragons here).

wrong?
I don't think we can avoid empty fragment identifiers so easily.

Consider the following JSON value:
  {
    "":1,
    "foo":2
  }

URI    refers to
---    ---------
#/     1
#/foo  2
#      {...}  (the root object)

Hence I think we need to undo part of the changeset <http://trac.tools.ietf.org/wg/appsawg/trac/changeset/69> [at line 206].

The examples need to include element names with "^" and "/" characters, and perhaps an empty element name for completeness.

--
James Manger

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Jun 2012 13:21:06 +1000

Good point; will fix.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Jun 2012 09:25:05 +0200

> 1) I haven't said anything about 0 being allowed; Julian, do you have a proposal for text in Security Considerations?

"Note that JSON pointers can contain the NUL (Unicode U+0000) character, 
which may not be representable in all programming languages."

(I personally think we should disallow it, though).

> Julian, you mentioned reserving more characters, but the downside there will be (potentially) making it more difficult to use with existing JSON that uses those characters. However, we *do* define…

I'd prefer that we simplify things by not attempting to define fragment 
identifier syntax for now. Doing so without updating the 
application/json spec will lead to lots of confusion.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Jun 2012 17:29:44 +1000

On 27/06/2012, at 5:25 PM, Julian Reschke wrote:

> "Note that JSON pointers can contain the NUL (Unicode U+0000) character, which may not be representable in all programming languages."
> 

I'll insert the text now, as it seems uncontroversial; if there's a decision to disallow it later, we can change it.

> I'd prefer that we simplify things by not attempting to define fragment identifier syntax for now. Doing so without updating the application/json spec will lead to lots of confusion.

Isn't that just a matter of updating the registry entry?

Regards,