Elwyn: Thank you very much for your review. Tim, Pete - any thoughts on Elwyn's
comments?
Jari
> Summary:
> 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:
> None.
>
> 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?
>
> s12:
> 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
> irrelevant).
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
