The I-JSON Message Format
draft-ietf-json-i-json-06
Yes
(Pete Resnick)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Alissa Cooper)
(Brian Haberman)
(Joel Jaeggli)
(Martin Stiemerling)
Note: This ballot was opened for revision 05 and is now closed.
Barry Leiba Former IESG member
(was Discuss)
Yes
Yes
(2015-02-11)
Unknown
Thanks for putting in the reference for "Surrogates" and "Noncharacters".
Pete Resnick Former IESG member
Yes
Yes
(for -05)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -05)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2015-01-19 for -05)
Unknown
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/
Brian Haberman Former IESG member
No Objection
No Objection
(for -05)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2015-01-22 for -05)
Unknown
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.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -05)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-01-19 for -05)
Unknown
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
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -05)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(2015-01-21 for -05)
Unknown
Though it makes me sad that we have to have this fork, rather than having fixed RFC 7159.
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-01-19 for -05)
Unknown
I share Juergen/s question ...
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-01-19 for -05)
Unknown
- 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
Ted Lemon Former IESG member
No Objection
No Objection
(2015-01-22 for -05)
Unknown
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.