Mainly a response on the 'unordered' issue. I'll leave the other ones
as things for
consideration between AD and the WG. See below:
Regards,
Elwyn
On 17/12/13 18:35, Paul Hoffman wrote:
On Dec 17, 2013, at 9:01 AM, Jari Arkko <[email protected]> wrote:
Elwyn: Thank you very much for your review. Tim, Pete - any thoughts on Elwyn's
comments?
Wearing my co-chair hat, I'll take a shot at answering them, given that they
have to do with both the WG charter and WG consensus.
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.
This is not a "minor issue". Our charter says that the WG "will keep changes to a
minimum", and we have discussed almost every issue in this light. While some people would
agree with Elwyn that entries in an object are unordered, many would disagree because JSON can be
parsed by streaming parsers. There were multiple threads on the mailing list about this topic. The
wording in the current draft comes after multiple consensus calls on the topic. Adding a
requirement that we now declare the entries unordered goes against the charter and the consensus of
the WG.
In that case you have an inconsistency, since the Introduction says that
the entries
*are* unordered. I can't immediately see why using a streaming parser
interacts
with the unordered issue but I am willing to be enlightened. I was
assuming that
the effect should be that the internal representation generated after
parsing should be the same whatever order the entries come in.
/E
s10: s9 allows there to be parsers that accept extensions. s10 only
allows generators to produce strict JSON.
Both of these are carried over from RFC 4627 unchanged.
Perhaps one should allow for
strict generators and extended generators that match with extended parsers?
This would be a change from RFC 4627 that the WG didn't even consider, given
our charter requirement.
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.
In keeping with trying to keep changes to a minimum, the WG chose not to list ever
possible thing that parsers could do wrong that could be perceived as security
considerations. If we add this one, there would be a tendency to add many other,
hopefully obvious items such as "don't allow numbers to have exponents that are too
large" and so on.
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.
This has not been listed as a problem since RFC 4627 was published.
s6: To be absolutely definite, assert that numbers are represented in
base 10.
To date, no implementer has said that they were fooled by the lack of
representation.
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).
For a new format, additional examples might be useful. This hasn't been
perceived as useful by any other reviewer so far.
--Paul Hoffman
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
