Skip to main content

The JavaScript Object Notation (JSON) Data Interchange Format
draft-ietf-json-rfc4627bis-10

Yes

(Pete Resnick)

No Objection

(Adrian Farrel)
(Brian Haberman)
(Martin Stiemerling)
(Stewart Bryant)

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

Barry Leiba Former IESG member
Yes
Yes (2013-12-19 for -09) Unknown
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 Former IESG member
Yes
Yes (for -09) Unknown

                            
Richard Barnes Former IESG member
Yes
Yes (2013-12-17 for -09) Unknown
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.
Sean Turner Former IESG member
(was No Objection) Yes
Yes (2013-12-18 for -09) Unknown
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.
Adrian Farrel Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2013-12-19 for -09) Unknown
Thanks for the precise and complete "Appendix A. Changes from RFC 4627" section. Pretty handy for the review.
Brian Haberman Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2013-12-19 for -09) Unknown
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-12-18 for -09) Unknown
I had the same understanding as Richard, but whatever you work out with Richard will be fine with me.
Stephen Farrell Former IESG member
No Objection
No Objection (2013-12-18 for -09) Unknown
- 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
Stewart Bryant Former IESG member
No Objection
No Objection (for -09) Unknown