Subject: [Gen-art] Gen-art last call/telechat review of draft-ietf-json-rfc4627bis-07.txt

From: Elwyn Davies <[email-masked]>
Date: Thu, 28 Nov 2013 23:55:51 +0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-json-rfc4627bis-07.txt
Reviewer: Elwyn Davies
Review Date: 28 November 2013
IETF LC End Date: 25 November 2013
IESG Telechat date: 5 December 2013

Summary:
[Apologies for missing the end of last call.]
Almost ready for publication as a standard track RFC.  There are a 
couple of minor issues and some nits that should be addressed before 
publication.

There have been discussions of the use of BOM characters at the start of 
JSON strings and the "heavy encouragement" of the use of UTF-8 
encoding.  IANA also require some clarification of the update of the 
application/json MIME type. This review doesn't address these issues.

Major issues:
None.

Minor issues:
s1, para 4: It would probably be useful to clarify that 'value' has the 
same meaning as in the previous para.  Also that it is not required that 
the array elements in a single array be all the same type.

s4: The unordered nature of the entries in an object is not mentioned.  
Presumably it should state that two objects with the same sets of 
name-value pairs ("members") in any order are logically equivalent.

s12, last sentence:
> The same
>     consideration applies in any other programming language in which JSON
>     texts conform to that language's syntax.
Whilst there is clearly a security issue when a JSON text is fed to the 
equivalent of JavaScript's eval() function, it strikes me that this is 
only a problem if the other programming language also overloads its 
equivalent of eval() to parse JSON texts.  I think the text isn't clear 
on this.  Perhaps add 'and the JSON text parser does the equivalent of 
eval()' to the end. (Actually the change note in Appendix A is *much* 
clearer on what is meant!)

A potentially more serious issue comes from the standard buffer 
overrun/execution of data problems in that the JSON text may be parsed 
(effectively compiled) into a piece of executable binary. This should 
probably be called out.

Nits/editorial comments:
s1, para 1 and s1.2, para 2: The statements of ECMAscript being 'Third 
Edition' in s1 and 'version 5.1' in s1.2 is slightly confusing - would 
it be possible to explain what is going on here please?

s5: Would be worth reiterating that there is no requirement for the 
values in an array to be the same type.

s6: To be absolutely definite, assert that numbers are represented in 
base 10.

  s11: There is inconsistency in the presentation of email addresses: 
The two instances of <[email-masked] are (presumably) missing a trailing 
'>'. For consisteency should [email-masked] be 
<[email-masked]>?

s13: Might be useful to insert examples with
- an array with elements that are not the same type
- equivalent objects with the members in different orders.
These could also show off escape sequences and maximally compact formats 
(using the equivalent object example to show that the white space is 
irrelevant).