The JavaScript Object Notation (JSON) Data Interchange Format
RFC 8259

Note: This ballot was opened for revision 03 and is now closed.

Mirja Kühlewind Yes

Alexey Melnikov (was Discuss, Yes) Yes

Comment (2017-03-23 for -03)
No email
send info
Alvaro: I think you are correct. I've added an RFC Editor note.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2017-03-14 for -03)
No email
send info
- 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) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

(Kathleen Moriarty) No Objection

Comment (2017-03-15 for -03)
No email
send info
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.

Alvaro Retana No Objection

Comment (2017-03-14 for -03)
No email
send info
If rfc7159 already Obsoleted rfc4627 and rfc7158, and this document Obsoletes rfc7159, does it need to be marked as Obsoleting rfc4627 and rfc7158 again?  I would think that it doesn't.