Skip to main content

Last Call Review of draft-ietf-appsawg-json-pointer-07
review-ietf-appsawg-json-pointer-07-secdir-lc-eastlake-2013-01-03-00

Request Review of draft-ietf-appsawg-json-pointer
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-12-25
Requested 2012-12-13
Authors Paul C. Bryan , Kris Zyp , Mark Nottingham
I-D last updated 2013-01-03
Completed reviews Genart Last Call review of -07 by Suresh Krishnan (diff)
Secdir Last Call review of -07 by Donald E. Eastlake 3rd (diff)
Assignment Reviewer Donald E. Eastlake 3rd
State Completed
Request Last Call review on draft-ietf-appsawg-json-pointer by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 09)
Result Has nits
Completed 2013-01-03
review-ietf-appsawg-json-pointer-07-secdir-lc-eastlake-2013-01-03-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This draft describes two closely related syntaxes for pointers to
objects within a JSON (JavaScript Object Notation) document. One is a
JSON string syntax, the other is a URI fragment identifier for URIs
defined to take such a fragment identifier.

Security:

I do not see any security problems with this document. The syntax
appears to be unambiguously specified, including ABNF, and the
Security Considerations Section is adequate and touches on the
potential pit-falls that JSON pointers can contain NULs.

Miscellaneous:

I found significant ambiguity in the semantics of a JSON pointer
string. Is the result of the successful evaluation ("evaluation" is a
term used in the draft) of such a pointer string a structure that
points into a JSON document or is it the objection pointed to? It
mostly seems to be an object but it is specifically provided that
array references could point beyond the end of an array and at least
in that case perhaps some sort of pointer structure would be returned
with the error condition. It probably doesn't matter, because these
syntaxes are intended to be used in a variety of applications and it
will be up to the application to clarify the semantics.

Minor:

The expansion for the acronym JSON should be given in the title and abstract.

In the first line of the second paragraph of Section 6, I found the
word "nominate" kind of odd. Why not "specify" or "select" or "use"?

None of the Authors Addresses given includes a postal address.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 at gmail.com