The JavaScript Object Notation (JSON) Data Interchange Format
RFC 8259
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Alvaro Retana No Objection
(Alexey Melnikov; former steering group member) (was Discuss, Yes) Yes
Alvaro: I think you are correct. I've added an RFC Editor note.
(Mirja Kühlewind; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
- section 9: This allows limits for nesting depth, number range and precision, and string length. Can you offer any guidance about what sorts of limits might be reasonable? Or what limits might unreasonably impact interoperability? - 12, 2nd paragraph: This paragraph sort of buries the lede. I thought it was going to talk about the implications of not being able to parse certain JSON legal characters with eval(), but I understand it really about the risk of arbitrary executable content. I suggest you say that in the first sentence.
(Benoît Claise; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
I don't see a response to the first part of the SecDir review on the Security Considerations section. Given the content of the current security considerations section, I agree with Ben that the additional considerations he mentions should be included. Can someone respond to Ben please on that part of his review? Thank you.
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection