Received changes through RFC Editor sync (changed abstract to '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 removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.')

Received changes through RFC Editor sync (created alias RFC 8259, changed abstract to '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.', changed pages to 16, changed standardization level to Internet Standard, changed state to RFC, added RFC published event at 2017-12-13, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-jsonbis-rfc7159bis and RFC 7159)

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

[Ballot discuss]
Text about mandatory to implement charset encodings or charset auto-discovery need to be added back to the document.

Alvaro: I think you are correct. I've added an RFC Editor note.

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

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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-jsonbis-rfc7159bis-03.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the application Media Types registry located at:

https://www.iana.org/assignments/media-types/

the entry for application/json already exists.

IANA Question --> Should the reference be changed from RFC 7159 to the new [ RFC-to-be ]? Are there changes to the template?

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

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.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
CC: jsonbis-chairs@ietf.org, json@ietf.org, "Matthew Miller" <mamille2@cisco.com>, mamille2@cisco.com, alexey.melnikov@isode.com, draft-ietf-jsonbis-rfc7159bis@ietf.org
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-jsonbis-rfc7159bis-03.txt> (The JavaScript Object Notation (JSON) Data Interchange Format) to Internet Standard

The IESG has received a request from the Javascript Object Notation
Update WG (jsonbis) to consider the following document:
- 'The JavaScript Object Notation (JSON) Data Interchange Format'
  <draft-ietf-jsonbis-rfc7159bis-03.txt> as Internet 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 2017-03-07. 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 removes inconsistencies with other specifications of
  JSON, repairs specification errors, and offers experience-based
  interoperability guidance.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-jsonbis-rfc7159bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-jsonbis-rfc7159bis/ballot/

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

1. Summary

This document is an update to RFC 7159 to promote the JSON
format to Internet Standard.  In promoting to Internet
Standard, this document is a minimal update to RFC 7159 to
apply accepted errata and to normatively reference ECMA-404.

Matthew Miller is the document shepherd.  Alexey Melnikov is
the responsible AD.

2. Review and Consensus

This document had numerous reviews, drawn out over several months.
While no new technical concerns were raised, the consensus on this
document is rough due to the unique nature of the normative
reference to ECMA-404.  It is not strictly necessary to understand
ECMA-404 to implement JSON; rather the reference is an agreement
with Ecma TC39 to agree on a single shared definition of JSON.

3. Intellectual Property

As with RFC 7159, 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

Ecma TC39 has agreed to publish an update to ECMA-404 to reference
the RFC-to-be 7159bis.  The responsible AD may hold publication
until TC39 makes their change, which is waiting until 7159bis is
assigned a number.