Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-json-i-json-05

From: Meral Shirazipour <[email-masked]>
Date: Wed, 14 Jan 2015 09:00:29 +0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-json-i-json-05
Reviewer: Meral Shirazipour
Review Date: 2015-01-14
IETF LC End Date:  2015-01-14
IESG Telechat date: NA

Summary:
This draft is ready to be published as Standards Track RFC but I have some comments .

Nits/editorial comments:
-Please spell out acronyms at first use. E.g. JSON, I-JSON

-[Page 3], "treat an integer", it would be good to mention this is still referring to IEEE754 format.

-[Page 3],"(one example would be 64-bit integers)", here not clear if still IEEE7544 is discussed or integer format. If latter, is it signed/unsigned.
"RECOMMENDED to encode them in JSON string values." should this be done in decimal format then?

-[Page 4], Section 3, "in the JSON messages it receives."--->"in the JSON messages they receives."

-[Page 4], "receiving implementation"---->"receiving implementations"

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Jan 2015 12:38:19 +0100

Thanks for your review, Meral.

Have you authors observed the comments and taken all actions that you think are necessary?

FWIW, I have placed the following position on the ballot for tonight’s IESG call:

No Objection - 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.

jari

On 14 Jan 2015, at 10:00, Meral Shirazipour <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Meral Shirazipour <[email-masked]>
Date: Thu, 22 Jan 2015 17:35:22 +0000

Hi,
  I have not heard from the authors. My 2nd and 3rd comments on [page 3] would need more attention.

Best ,
Meral

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, January 22, 2015 3:38 AM
> To: Meral Shirazipour
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-json-i-json-05
> 
> FWIW, I have placed the following position on the ballot for tonight's IESG
> call:
> 
> No Objection - 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.
> 
> jari
> 
> > I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
> >
> > -[Page 3],"(one example would be 64-bit integers)", here not clear if still
> IEEE7544 is discussed or integer format. If latter, is it signed/unsigned.

---

From: Tim Bray <[email-masked]>
Date: Thu, 22 Jan 2015 18:13:12 -0800

<editor-hat>

>  -Please spell out acronyms at first use. E.g. JSON, I-JSON

​I disagree.  People know what JSON stands for, and for those who don’t
spelling it out wouldn’t help.  De facto, the name of the format is JSON.
Also, the mention of JavaScript is a red herring.​

-[Page 3], "treat an integer", it would be good to mention this is still
> referring to IEEE754 format.
>

​I disagree.  It’s talking about the sequence of digits in the I-JSON text,
irrespective of any binary format.​
​

>
>
> -[Page 3],"(one example would be 64-bit integers)", here not clear if
> still IEEE7544 is discussed or integer format. If latter, is it
> signed/unsigned.
>

​I think this has been discussed elsewhere on teh thread.  It’s irritating
that 64-bit integers would be string-encoded even though most computers can
handle them in hardware, but it is a real plus for interoperability.
Anyhow, the place where this advice really applies is for​ huge crypto
integers.

> -[Page 4], Section 3, "in the JSON messages it receives."--->"in the JSON

​er, “er, they receive’. Yup.  ​

​​

> ​​
​Yup.​

​​

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Meral Shirazipour <[email-masked]>
Date: Fri, 23 Jan 2015 10:16:14 -0800

Hi Tim,
   thanks for considering, please see inline.

Best Regards,
Meral

On 01/22/2015 06:13 PM, Tim Bray wrote:
> <editor-hat>
>
> On Wed, Jan 14, 2015 at 1:00 AM, Meral Shirazipour 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Nits/editorial comments:
>
> ​I disagree.  People know what JSON stands for, and for those who 
> don’t spelling it out wouldn’t help.  De facto, the name of the format 
> is JSON.  Also, the mention of JavaScript is a red herring.​
I agree for JSON, but I-JSON I had to look it up.
> ​I disagree.  It’s talking about the sequence of digits in the I-JSON 
> text, irrespective of any binary format.​
was not clear to me, thanks for clarifying.
> ​
>
>     -[Page 3],"(one example would be 64-bit integers)", here not clear
>     if still IEEE7544 is discussed or integer format. If latter, is it
>     signed/unsigned.
>
> ​I think this has been discussed elsewhere on teh thread. It’s 
> irritating that 64-bit integers would be string-encoded even though 
> most computers can handle them in hardware, but it is a real plus for 
> interoperability.  Anyhow, the place where this advice really applies 
> is for​ huge crypto integers.
yes, that part of the text was not clear to me. For a standards track 
RFC it may be worth taking another look at it.
>     www.ericsson.com <http://www.ericsson.com>
>
>
>
>
> --

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Jan 2015 10:24:22 -0800

> I agree for JSON, but I-JSON I had to look it up.

​In http://www.tbray.org/tmp/draft-ietf-json-i-json-05.html#rfc.section.1
it says: This document specifies I-JSON, short for "Internet JSON".   So I
think we’re probably OK here.​

> irritating that 64-bit integers would be string-encoded even though most
> computers can handle them in hardware, but it is a real plus for
> interoperability.  Anyhow, the place where this advice really applies is
> for​ huge crypto integers.
>
> yes, that part of the text was not clear to me. For a standards track RFC
> it may be worth taking another look at it.
>

​Actually, following on this discussion, I agree. The text originally
referred to huge crypto integers and was revised to “64-bit integer” at the
request of the WG.  But now I see that that is sort of counter-intuitive
because it assumes the subtext of ​“yes we know that most computers can do
64-bit ints just fine but don’t do that because stupid JavaScript”.  So I
think the draft needs to either fill in that backdrop, or go back to using
huge crypto ints as an example.   I’m inclined to put in a few words of
backdrop.