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

[Ballot comment]
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.

[Ballot discuss]
Thanks for writing this. I would like to briefly discuss the topic of whether ordering is specified in Section 4 and WG's history on that topic before recommending the approval of the document.

[Ballot comment]
Thanks for writing this. I would like to briefly discuss the topic of whether ordering is specified in Section 4 and WG's history on that topic before recommending the approval of the document.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]

- 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

[Ballot comment]
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.

Shepherd writesup for draft-ietf-json-rfc4627bis

1. Summary

Paul Hoffman (one of the WG co-chairs) is the document shepherd. Pete Resnick is the responsible AD.

This document is an update to RFC 4627, the RFC that describes the JSON format. (Note that there two
other independent definitions of JSON: json.org, and ECMA-262 (Edition 5.1, June 2011). This
document is a minimal update to RFC 4627 that corrects some errors, adds a bit of clarification, and
points out topics where there have been interoperability issues since RFC 4627 was published. As
stated in the charter, this document is meant to be a Proposed Standard.

2. Review and Consensus

This document had a wonderfully wide and deep review. The WG had a high number of IETF regulars and
newcomers. Although we had little input from the members of TC39 in Ecma, we had lots of input from
the larger JSON-using community, including many active developers of JSON libraries.

The WG went through a couple of phases during the review, with some folks wanting to fix a lot of things,
some wanting to basicly push it out untouched, and still others wanting a light touch with useful notes.
In then end, there was rough group consensus for the latter.

Near the end of the review cycle, Ecma issued a new document that defined (mostly) just the syntax
for JSON, Standard ECMA-404. The syntaxes in this document and ECMA-404 appear identical. It
is worthwhile noting that the syntaxes are described in different languages (this document uses
ABNF, the Ecma document uses racetrack-style pictures).

3. Intellectual Property

There was no WG discussion of IPR given that this is an update to a format document for which there
was no IPR statements in the first place.

4. Other Points

The WG charter says:
  The resulting document will be jointly published as an RFC and by ECMA.
  ECMA participants will be participating in the working group editing
  through the normal process of working group participation. The
  responsible AD will coordinate the approval process with ECMA so that
  the versions of the document that are approved by each body are the
  same.
None of that happened. This document stands on its own, as does ECMA-404 and upcoming revision to
the ECMAScript standard.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-json-rfc4627bis-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about the IANA actions requested in the IANA Considerations section of this document.

IANA Question --> Is the only action being requested in the IANA Considerations section of this document - an update to the reference
for the application/json Media Type that is currently registered in:

http://www.iana.org/assignments/media-types/application

?

If so, IANA understands that this is the only action being requested
upon approval of the document.  The author should update the text
in the next version to indicate that this document updates
that reference for clarity purposes.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The JSON Data Interchange Format) to Proposed Standard


The IESG has received a request from the JavaScript Object Notation WG
(json) to consider the following document:
- 'The JSON Data Interchange Format'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  JavaScript Object Notation (JSON) is a lightweight, text-based,
  language-independent data interchange format.  It was derived from
  the ECMAScript Programming Language Standard.  JSON defines a small
  set of formatting rules for the portable representation of structured
  data.

  This document makes no changes to the definition of JSON; it repairs
  specification errors and offers experience-based interoperability
  guidance.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/ballot/


No IPR declarations have been submitted directly on this I-D.