The I-JSON Message Format
draft-ietf-json-i-json-06

[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.

[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.

[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

[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).

[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.

[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

[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/

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.

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.

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.