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

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

Search Mailarchive

(Richard Barnes) Yes

Comment (2013-12-17 for -09)
The following comment seems inaccurate: "This revision does not change any of the rules of the specification" et seq.  The changes made after LC for ECMA alignment have indeed caused texts that were not JSON (per 4627) to become JSON.  For example, the string "  { \"a\": 1 }  " would be illegal according to RFC 4627, but is legal according to this document.

(Barry Leiba) Yes

Comment (2013-12-19 for -09)
To the document shepherd: thanks for a good and useful shepherd writeup.

In addition to text asking IANA to change the reference document in the registration (which has been worked out with IANA), I'd have liked to have seen us take this opportunity to update the registration template to conform to RFC 6838 (with addition of "Security considerations" and "Fragment identifier considerations" sections).  That could be done with an RFC Editor note such as this:

   In Section 11:

   Insert before "Interoperability considerations:"...
   NEW
   Security Considerations: See [this RFC], section 12.
   END
   
   Insert before "Additional information:"...
   NEW
   Fragment identifier considerations: Fragments are not used and are
      not appropriate for this media type.
   END

I'll also note that an issue has been raised that I'm not sure has been adequately answered yet, as to the wisdom of our taking change control for this media type.

(Pete Resnick) Yes

(Sean Turner) (was No Objection) Yes

Comment (2013-12-18 for -09)
As the guy who kind of put a bug in somebody's ear to elevate this from Informational to Standard track - I thank all those involved.

(Jari Arkko) (was Discuss) No Objection

Comment (2013-12-19 for -09)
The discussion of the topic of whether ordering is specified in Section 4 seems to be converging. I expect the right thing to happen with the help of chairs and authors.

(Stewart Bryant) No Objection

Benoit Claise No Objection

Comment (2013-12-19 for -09)
Thanks for the precise and complete "Appendix A. Changes from RFC 4627" section. Pretty handy for the review.

Spencer Dawkins No Objection

Comment (2013-12-18 for -09)
I had the same understanding as Richard, but whatever you work out with Richard will be fine with me.

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-12-18 for -09)
- ECMA-404 looks weird;-)

- Please see the suggestions in the secdir review [1] 
which may or may not have gotten to you in mail
already.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04485.html

(Brian Haberman) No Objection

(Martin Stiemerling) No Objection