JavaScript Object Notation (JSON) Pointer
draft-ietf-appsawg-json-pointer-09

[Ballot discuss]
I'm putting a DISCUSS on to hold this for now while I have a bit of discussion with the authors about the arrays vs objects issue.

[Ballot comment]
- I consider this draft as poor in explaining the use cases and example for the JSON pointer.
In comparison, draft-ietf-appsawg-json-patch did a much better job.
The interaction, if any, with the JSON patch should be explained. It nothing else as a potential use case/example.
JSON-PATCH mentions:

  Additionally, operation objects MUST have exactly one "path" member,
  whose value MUST be a string containing a [JSON-Pointer] value that
  references a location within the target document to perform the
  operation (the "target location").

But JSON-POINTER doesn't even mention JSON-PATCH
So bad luck is someone starts by reading JSON-POINTER...

- For the record, I insert Dan Romascanu's OPS DIR review, stressing the need to reclassify RFC 4627 sooner than latter:

    By now, if somebody makes a snapshot after these documents will be approved a rather odd situation shows up. Two (maybe more documents) which are standards track extend a base document which is Informational. Standards that extend non-standards. If 4627 was Standards Track we would have used 'Updates RFC 4627' in the meta-data, but of course we cannot do it now.

    Nothing critical happens (I think) as long as things work OK - but probably the sooner reclassifying 4627 happens the better.

[Ballot comment]
I'm clearing my Discuss after exchanges with the document shepherd and responsible AD that indicate that, in their opinion, consensus has been reached on the IETF last call issues and that the on-going thread represents only a tail-end to that dicussion with the potential to spin up a new I-D, but will not impact this particular document.

[Ballot comment]

- Intro: Does this identify a "value" within a JSON document or
a "place where a value should be found" within a JSON document?
Seems more like the latter to me.

- Section 3: FWIW, Pete's comment about i18n has me confused.
But so does "is a Unicode string" here. I guess i18n just has
me confused generally, but that's common;-) The last sentence
of section 3 however does seem clear to me, as is section 4 so
I think leaving this as-is is better than changing it.

- Section 3: You say that "~" is special before you say why its
special, might be clearer if you said that in text before the
ABNF, e.g. adding '"~" is only special because it allows you to
escape "/"' and that you chose "~" because its not otherwise
used to escape JSON things (which I guess is why you picked
it).

- 4: is there no MAX value for array indices? Is there any
chance that "/foo/12345667890002122312312" might be a DoS
vector if it caused some memory allocation to go wonky? If so,
it might be good to note that in the security considerations
and say that e.g. implemtations MAY have a MAX value they
allow for array indices and also give a number that they all
MUST support or something. (Yes, I know that'd be a naive way
to allocate memory, but I still wanna ask:-) I guess such
a warning could go here or in specs that use this, I'm not
sure which'd be better.

- Section 6: Is "#/i%5Cj" really the same as "/i\\j" ? If it is
(which I can believe) then maybe good to call that out as I can
imagine folks getting it wrong and using "#/i%5C%5Cj" instead.

- section 7: This says specs using this SHOULD do something for
"each type of error" but you don't give a specific list of the
types of error (you say "is not limited to"). That seems to be
a conflict and might be a source of problems if different
consumers of this do different things. Given that json-patch
does need to know which error has happened sometimes, I think
it'd be better if you defined specific named (or numbered,
whatever) errors here that could be referenced in other specs
using this.

- Section 9: Would it be worth saying that pointers in
fragments might expose sensitive information? E.g. a fragment
like "/user109/hivtest/followupneeded" could be sensitive and
we generally prefer to not have sensitive information in URLs
as it might be logged.

[Ballot discuss]
This Discuss position is just to close a topic with the responsible AD.
No action is required or requested from the document authors.

There seems to have been something of an avalanche of email on this I-D
continuing long after IETF last call completed. Some of the email has
been on the IETF list and some restricted to the appsawg list. Could the
responsible AD confirm that the topics, as they impinge on this
document, have been addressed to completion and with consensus of the
WG? (The recent date on the current version suggests that updates have
been made, but also that the new version hasn't had a chance to be
widely read.)

[Ballot comment]
- Probably worth noting in section 3 that the syntax is in terms of characters (as described in 5234) and in particular not in terms of coded characters (e.g., UTF-8 or any other encoding of a document containing these things is independent of this syntax). The document is exactly correct as-is, but sometimes people confuse characters and bytes.

- I would note in section 4 the obvious with regard to arrays: If the reference token following an array is neither a string of "0".."9" nor a "-", then  the member that is referenced is undefined, and evaluation fails.

- In the example in section 5, I think referring to an object within the object would be helpful.

IANA has reviewed draft-ietf-appsawg-json-pointer-07, which is currently
in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (JSON Pointer) to Proposed Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'JSON Pointer'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


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




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/


No IPR declarations have been submitted directly on this I-D.