Skip to main content

The I-JSON Message Format
RFC 7493

Revision differences

Document history

Date Rev. By Action
2018-05-10
06 (System) Received changes through RFC Editor sync (added Errata tag)
2015-10-14
06 (System) Notify list changed from linuxwolf@outer-planes.net, json-chairs@ietf.org to (None)
2015-03-22
06 (System) RFC published
2015-03-20
06 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-03-18
06 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-03-16
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-02-13
06 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-02-12
06 (System) RFC Editor state changed to EDIT
2015-02-12
06 (System) Announcement was received by RFC Editor
2015-02-12
06 (System) IANA Action state changed to No IC from In Progress
2015-02-12
06 (System) IANA Action state changed to In Progress
2015-02-12
06 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-02-12
06 Amy Vezza IESG has approved the document
2015-02-12
06 Amy Vezza Closed "Approve" ballot
2015-02-12
06 Amy Vezza Ballot approval text was generated
2015-02-12
06 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2015-02-11
06 Barry Leiba [Ballot comment]
Thanks for putting in the reference for "Surrogates" and "Noncharacters".
2015-02-11
06 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to Yes from Discuss
2015-01-27
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-01-27
06 Tim Bray IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-01-27
06 Tim Bray New version available: draft-ietf-json-i-json-06.txt
2015-01-22
05 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2015-01-22
05 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-01-22
05 Ted Lemon
[Ballot comment]
This is an editorial nit, which the RFC editor might catch, but they'd have to know about the distinction between double precision floating …
[Ballot comment]
This is an editorial nit, which the RFC editor might catch, but they'd have to know about the distinction between double precision floating point and fixnums, so I figured I'd just mention it to be safe:

  In particular, an I-JSON sender cannot expect a receiver to treat an
  integer whose absolute value is greater than 9007199254740991 (i.e.,
  that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value.

The "in particular" at the beginning of this sentence has no antecedent, so it doesn't make sense to say it.  You should just delete "in particular".  I wonder if there was some text prior to this that got deleted in a previous revision...

  For applications which require the exact interchange of numbers with
  greater magnitude or precision (one example would be 64-bit
  integers), it is RECOMMENDED to encode them in JSON string values.
  This requires that the receiving program understand the intended
  semantic of the value.

What was the rationale for this?  I don't know of a lot of platforms that don't support 64-bit integers, so this seems overly restrictive.  I'm not raising this as a major issue because I am sure there _was_ a rationale, but I'd like to hear it.
2015-01-22
05 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2015-01-22
05 Jari Arkko
[Ballot comment]
I should note that there was a Gen-ART review from Meral with some minor editorial observations. For instance, the first sentence of Section …
[Ballot comment]
I should note that there was a Gen-ART review from Meral with some minor editorial observations. For instance, the first sentence of Section 3 could use improvement. These could be handled by the RFC Editor, too.
2015-01-22
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-01-21
05 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-01-21
05 Richard Barnes [Ballot comment]
Though it makes me sad that we have to have this fork, rather than having fixed RFC 7159.
2015-01-21
05 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2015-01-21
05 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-01-20
05 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2015-01-20
05 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-01-19
05 Stephen Farrell
[Ballot comment]

- 2.1: I've no idea what Surrogate or Noncharacter
means here - a precise reference would be good for me.
And the examples …
[Ballot comment]

- 2.1: I've no idea what Surrogate or Noncharacter
means here - a precise reference would be good for me.
And the examples don't help me. So I agree with
Barry's discuss.

- 4.3: Did the WG discuss whether to require/encourage
inclusion/exclusion of 00 values and timezones in
times? E.g. is there a preference for 20150119T2304Z or
20150119T230400Z which represent the same time.

- 4.3: I'm also a bit surprised you don't say that UTC
is the default TZ. I think those time rules do help
interoperability so defining defaults would have been
an improvement. Why is that? (I don't think 3339 does
that or does it?)

- 4.4: I don't recall them so have had to track down
the difference between base64 and base64url and check
I'm using the right APIs over and over.  That might be
because I only write code sporadically (and badly:-)
and forget stuff in between, but an example of the
difference (possibly parenthetical) would help me a
bit, just so's I could look at a value I generate and
spot I've done it wrong again.

- I mostly agree with the secdir reviewer's [1] point
that it might be good to RECOMMEND use of I-JSON for
more security sensitive applications, but I'd have felt
more strongly about that if you'd profiled the time
values more strictly as messing up those can lead to
vulnerabilities and being more precise there helps to
get e.g. signatures correct a bit more easily.

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html
2015-01-19
05 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2015-01-19
05 Barry Leiba
[Ballot discuss]
This should be quite simple to sort out:

-- Section 2.1 --

  Object member names, and string values in arrays and object …
[Ballot discuss]
This should be quite simple to sort out:

-- Section 2.1 --

  Object member names, and string values in arrays and object members,
  MUST NOT include code points which identify Surrogates or
  Noncharacters.

Where are the definitions of "Surrogates" and "Noncharacters"?  Because you say they MUST NOT be included, I think they need to be defined in normative reference(s) and cited here (they're not defined in 3629, nor does 3620 cite a definition).
2015-01-19
05 Barry Leiba
[Ballot comment]
The RFC Editor will make a lot of "which" -> "that" changes.  Just be aware.

-- Sections 3 and 4 --
Going in …
[Ballot comment]
The RFC Editor will make a lot of "which" -> "that" changes.  Just be aware.

-- Sections 3 and 4 --
Going in the other direction from Jürgen's comments, I think these sections are unremarkable, and would just suggest changing the 2119 language to English words instead.  This is all giving sage advice, not defining protocol.

-- Section 5 --
I don't normally comment on "Acknowledgments" sections, and please take this as you will and do as you think best.  You mention the contributions of Douglas Crockford, and I wonder whether you might also mention the contributions of Ecma International TC39.
2015-01-19
05 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2015-01-19
05 Kathleen Moriarty
[Ballot comment]
I agree with the SecDir reviewer in his assessment of this draft after reading it.  I'm putting this in as comments/suggestions to be …
[Ballot comment]
I agree with the SecDir reviewer in his assessment of this draft after reading it.  I'm putting this in as comments/suggestions to be considered as the security considerations really should be in the JSON document.  If any considerations are missing, that is where I'd expect to see them.  The JSON format is not simple, so  agree with the SecDir reviewer that one would have expected additional handling considerations for security purposes to be in that document.  They don't need to be listed in this one.

Having said that, it might be good idea to add text to the security
considerations section, to state that I-JSON restricts and limits some of
the dangerous formats of the original JSON, therefore it might be considered
more secure than the original JSON.  Perhaps also mention that
security critical usages of the JSON should use I-JSON
(perhaps even provide references to the jose specifications).
https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html
2015-01-19
05 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-01-19
05 Spencer Dawkins [Ballot comment]
I share Juergen/s question ...
2015-01-19
05 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-01-19
05 Meral Shirazipour Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour.
2015-01-19
05 Benoît Claise
[Ballot comment]
There is still a ongoing discussion between J. Schönwälder (OPS-DIR) and Tim Bray.

On Sun, Jan 04, 2015 at 04:54:55PM -0800, Tim Bray …
[Ballot comment]
There is still a ongoing discussion between J. Schönwälder (OPS-DIR) and Tim Bray.

On Sun, Jan 04, 2015 at 04:54:55PM -0800, Tim Bray wrote:
> On Sun, Jan 4, 2015 at 12:14 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>
>> My understanding is that compliance to I-JSON means compliance to
>> section 2 of this document. Perhaps it makese sense to clarify this
>> (in particular if my interpretation is wrong).
>>
>
> Hmm, good point.  ​The draft currently doesn’t mention compliance; all it
> does is give a syntactic definition of something called an “I-JSON
> message”.  The notion was that other specs which wanted to require the use
> of I-JSON should say something like “The message body must be an I-JSON
> message [RFCXXXX]”.  I think that would work fine, but I wonder if others,
> like you, will be bothered by the absence of a specification of
> “compliance”.
>

I am raising this question since I think the draft goes somewhat
beyond simply defining I-JSON (which I believe is the material
contained in section 2).

In particular, the I-D uses RFC 2119 language in a section titled
"Protocol-design Recommendations". It is not clear to me how these
recommendations have been selected or why they are part of an I-JSON
specification. This applies mostly to sections 4.3 and 4.4. Anyway,
since these sections use RFC 2119 requirements language, I am
wondering what happens if a protocol complies to section 2 but not all
of section 4 - is it using I-JSON? I hope so, but it might be good to
make this clear.

/js


----------------------------------------------------

Editorial nit:

- s/values in in ISO 8601/values in ISO 8601/
2015-01-19
05 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-01-17
05 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2015-01-15
05 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2015-01-15
05 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2015-01-14
05 Pete Resnick Ballot has been issued
2015-01-14
05 Pete Resnick [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick
2015-01-14
05 Pete Resnick Created "Approve" ballot
2015-01-14
05 Pete Resnick IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2015-01-14
05 Pete Resnick Changed consensus to Yes from Unknown
2015-01-14
05 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-01-09
05 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-json-i-json-05, which is currently in Last Call, and has the following comments:

We understand that this document does not …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-json-i-json-05, which is currently in Last Call, and has the following comments:

We understand that this document does not contain a standard IANA Considerations section.
After examining the draft, IANA understands that, upon approval of this document, there
are no IANA Actions that need completion.

It is helpful to have the IANA Considerations section of the document in place upon
publication for clarity purposes.


If this assessment is not accurate, please respond as soon as possible.
2015-01-09
05 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2015-01-08
05 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Tero Kivinen.
2015-01-06
05 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jürgen Schönwälder.
2015-01-04
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2015-01-04
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2015-01-02
05 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2015-01-02
05 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2015-01-02
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2015-01-02
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2014-12-31
05 Cindy Morgan IANA Review state changed to IANA - Review Needed
2014-12-31
05 Cindy Morgan
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 I-JSON Message Format) to …
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 I-JSON Message Format) to Proposed Standard


The IESG has received a request from the JavaScript Object Notation WG
(json) to consider the following document:
- 'The I-JSON Message 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 2015-01-14. 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


  I-JSON is a restricted profile of JSON designed to maximize
  interoperability and increase confidence that software can process it
  successfully with predictable results.




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

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


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

There are no IANA considerations for this document.
2014-12-31
05 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2014-12-31
05 Pete Resnick Placed on agenda for telechat - 2015-01-22
2014-12-31
05 Pete Resnick Notification list changed to linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org from json-chairs@tools.ietf.org, draft-ietf-json-i-json@tools.ietf.org, json@ietf.org
2014-12-31
05 Pete Resnick Notification list changed to json-chairs@tools.ietf.org, draft-ietf-json-i-json@tools.ietf.org, json@ietf.org from json-chairs@tools.ietf.org, draft-ietf-json-i-json@tools.ietf.org
2014-12-31
05 Pete Resnick Last call was requested
2014-12-31
05 Pete Resnick Ballot approval text was generated
2014-12-31
05 Pete Resnick IESG state changed to Last Call Requested from AD Evaluation::Point Raised - writeup needed
2014-12-31
05 Pete Resnick Last call announcement was changed
2014-12-31
05 Pete Resnick Last call announcement was generated
2014-12-31
05 Pete Resnick Ballot writeup was changed
2014-12-31
05 Pete Resnick Ballot writeup was generated
2014-12-18
05 Tim Bray New version available: draft-ietf-json-i-json-05.txt
2014-11-28
04 Tim Bray New version available: draft-ietf-json-i-json-04.txt
2014-10-16
03 Pete Resnick Eval sent. Waiting for WG.
2014-10-16
03 Pete Resnick IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation
2014-10-16
03 Pete Resnick IESG state changed to AD Evaluation from Publication Requested
2014-09-16
03 Matthew Miller
1. Summary

Matthew Miller (JSON WG co-chair) is the document shepherd and Pete Resnick is
the responsible AD.

This document defines a profile of JSON …
1. Summary

Matthew Miller (JSON WG co-chair) is the document shepherd and Pete Resnick is
the responsible AD.

This document defines a profile of JSON (RFC 7159).  This profile further
restricts characters, numbers, object members; it also provides additional
recommendations for protocol use.

This document is intended to be a Proposed Standard.

2. Review and Consensus

The WG discussion was not as extensive as for RFC 7159, but still broad.  Two
major points were brought up in WG Last Call: defining a link relation profile
URI, and the use of base64 versus bsae64url.

It was suggested that a profile URI be defined as an alternative to defining a
media type or media type suffix (which is also not defined in this document).
However, the WG could not reach consensus on this change.

There was considerable debate over the use of base64 versus base64url.  The WG
consensus was that binary data be encoded as some form of base64 but could not
reach any consensus on which specific variant.  The document first specified
base64url and without consensus to change it, it remains the recommendation in
the document.

Overall, the consensus on publishing this document is rough.  At least one
participant still questions its utility, although several participants have
brought up at least the JOSE WG's collection of normative documents as a user.

3. Intellectual Property

There was no WG discussion of IPR given that this document defines a subset of
a format for which there was no IPR statements in the first place.

4. Other Points

There are no normative downrefs.

There are no IANA considerations.
2014-09-16
03 Matthew Miller State Change Notice email list changed to json-chairs@tools.ietf.org, draft-ietf-json-i-json@tools.ietf.org
2014-09-16
03 Matthew Miller Responsible AD changed to Pete Resnick
2014-09-16
03 Matthew Miller IETF WG state changed to Submitted to IESG for Publication from WG Document
2014-09-16
03 Matthew Miller IESG state changed to Publication Requested
2014-09-16
03 Matthew Miller IESG process started in state Publication Requested
2014-09-16
03 Matthew Miller Intended Status changed to Proposed Standard from None
2014-09-16
03 Matthew Miller Changed document writeup
2014-09-09
03 Matthew Miller Changed document writeup
2014-09-09
03 Matthew Miller Changed document writeup
2014-09-09
03 Matthew Miller Document shepherd changed to Matthew Miller
2014-08-05
03 Tim Bray New version available: draft-ietf-json-i-json-03.txt
2014-06-30
02 Tim Bray New version available: draft-ietf-json-i-json-02.txt
2014-06-13
01 Tim Bray New version available: draft-ietf-json-i-json-01.txt
2014-04-30
00 Tim Bray New version available: draft-ietf-json-i-json-00.txt