Skip to main content

Telechat Review of draft-ietf-json-rfc4627bis-09

Request Review of draft-ietf-json-rfc4627bis
Requested revision No specific revision (document currently at 10)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-12-17
Requested 2013-12-05
Authors Tim Bray
Draft last updated 2014-01-30
Completed reviews Genart Last Call review of -07 by Elwyn B. Davies (diff)
Genart Telechat review of -09 by Elwyn B. Davies (diff)
Secdir Last Call review of -07 by Tobias Gondrom (diff)
Secdir Telechat review of -09 by Tobias Gondrom (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Review review-ietf-json-rfc4627bis-09-genart-telechat-davies-2014-01-30
Reviewed revision 09 (document currently at 10)
Result Almost Ready
Completed 2014-01-30
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

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

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

Almost ready for publication as a standard track RFC.  Several of the 
issues identified in the last call/previous telechat review have been 
addressed but the authors have noted that the document update was agreed
on the basis that it would make minimal changes.  However, at least the 
first of the 'minor issues' called out represents undocumented 
functionality that could result in non-interoperable implemenattions if 
the unordered requirement is not honoured.  The second is an 
inconsistency and the third is a judgment call.

There are a couple of recommendations that I think would assist 
readability and reflect usual practice with such documents. 

Major issues:

Minor issues:
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.

s10: s9 allows there to be parsers that accept extensions.  s10 only 
allows generators to produce strict JSON.  Perhaps one should allow for 
strict generators and extended generators that match with extended parsers?

Since JSON text may potentially be parsed (effectively compiled) into what 
looks like a piece of executable binary, it is vital that parsers don't 
suffer from buffer overruns etc. This should probably be called out.

Nits/editorial comments:
General: Many RFCs that use ABNF specifications where parts of the ABNF 
are presented in separate sections also provide a section or appendix 
with the whole of the ABNF in one place.  Whilst this provides a very 
minor double maintenance problem, it does aid implementers and 
facilitates checking of the complete grammar to catch mismatches.

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

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 

Gen-art mailing list
Gen-art at