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

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/

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.

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

Though it makes me sad that we have to have this fork, rather than having fixed RFC 7159.

I share Juergen/s question ...

- 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

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.