Subject: [Json] I-D Action: draft-ietf-json-i-json-01.txt

From: [email-masked]
Date: Fri, 13 Jun 2014 12:58:05 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the JavaScript Object Notation Working Group of the IETF.

        Title           : The I-JSON Message Format
        Author          : Tim Bray
	Filename        : draft-ietf-json-i-json-01.txt
	Pages           : 6
	Date            : 2014-06-13

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-json-i-json/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-json-i-json-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-json-i-json-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tim Bray <[email-masked]>
Date: Fri, 13 Jun 2014 13:01:30 -0700

Real HTML is at http://www.tbray.org/tmp/draft-ietf-json-i-json-01.html

On Fri, Jun 13, 2014 at 12:58 PM, <[email-masked]> wrote:

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

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

---

From: Stefan Drees <[email-masked]>
Date: Sat, 14 Jun 2014 13:35:03 +0200

Thanks for providing this, Tim.
On 2014-06-13 22:01 +02:00, Tim Bray wrote:
> On Fri, Jun 13, 2014 at 12:58 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> ...

I read over it and section 4.3 "Time and Date Handling" might profit 
from one or two small changes:

OLD:
4.3.  Time and Date Handling

    Protocols often contain data items which are designed to contain
    timestamps or time durations.  It is RECOMMENDED that in all such
    data items be expressed in in ISO 8601 format, as specified in
    [RFC3339].

NEW (suggested):
4.3.  Time and Date Handling

    Protocols often contain data items which are designed to contain
    timestamps or time durations.  It is RECOMMENDED that in all such
    data temporal items be expressed in ISO 8601 format, as specified
    in [RFC3339].

{"end_of_changes": true}

Removing the doubled "in" is a sure thing for me, but if others would 
also subsume "the targeted items" as "temporal items" I do really not 
know and thus happily delegate to the native english speakers on this list.

The motivating sentence reminds me a bit of the significance of sister 
phrases like "Life often is ..." but as it is true (in my experience) 
and if no one else is irritated by quantifiers like "often" I see no 
need to discuss.

All the best,
Stefan.

---

From: Tim Bray <[email-masked]>
Date: Sat, 14 Jun 2014 17:05:38 -0700

Superfluous “in” nuked, thanks.

Also, could any date/time scholars here have a look at section 3.3 of
RFC4287 - http://tools.ietf.org/html/rfc4287#section-3.3 - and see if they
think some of that language should be adopted here.

On Sat, Jun 14, 2014 at 4:35 AM, Stefan Drees <[email-masked]> wrote:

> I read over it and section 4.3 "Time and Date Handling" might profit from
> one or two small changes:
>
> OLD:
> Removing the doubled "in" is a sure thing for me, but if others would also
> subsume "the targeted items" as "temporal items" I do really not know and
> thus happily delegate to the native english speakers on this list.
>
> phrases like "Life often is ..." but as it is true (in my experience) and
> if no one else is irritated by quantifiers like "often" I see no need to
> discuss.
>
> All the best,
> Stefan.
>
>

---

From: John Cowan <[email-masked]>
Date: Sat, 14 Jun 2014 21:38:12 -0400

> think some of that language should be adopted here.

That basically says to use T and Z rather than t and z, which I agree
is good.  So here's my proposal:

   Protocols often contain data items which are designed to contain
   timestamps or time durations.  It is RECOMMENDED that all data
   items containing timestamps conform to the "date-time" production
   in [RFC3339], with the additional restriction that uppercase rather
   than lowercase letters be used.  It is also RECOMMENDED that all data
   items containing time durations conform to the "duration" production
   in Appendix A of [RFC3339], with the same additional restriction.

I would further urge that the recommendation be changed to requirements.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
A few times, I did some exuberant stomping about, like a hippo auditioning
for Riverdance, though I stopped when I thought I heard something at
the far side of the room falling over in rhythm with my feet.  --Joseph Zitt

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 16 Jun 2014 00:44:11 +0000

Writing this on a plane, so I'm sorry if this crosses someone else's
review that makes the same points.

s2.1, s/always illegal/illegal/

s2.2, "For applications such as cryptography, where exact interchange of
much larger numbers is required, it is RECOMMENDED to encode them in JSON
string values", I suggest adding some guidance on encoding if we have a
quick consensus on decimal|hex|base64url|etc.  Otherwise leaving it as-is
works.  Note that JOSE chose base64url for good reason.

s2.3, I don't think we ever specified what "duplicate" means.  For
example, is this legal?

{ "a": 1, "\u0061": 2 }

what about this?

{ "a\u0301": 1, "\u00e1": 2}

or this:

{ "iv": 1, "\u2163": 2}

My opinion: the first one is illegal.  The second and third are legal, so
we don't bring in NFC or (shudder) NFKC.

s4, I think there ought to be another sentence in there about why you
might want to specify I-JSON.  Namely, that you're expressing that as a
sender, if there's a bug in your code you would rather have the receiver
fail on processing than try to recover.  Alternately, that could go in the
introduction.

s4.3, explicitly call out that the date will be in a string, please.
s4.4, explicitly call out that the base64url will be in a string, please.

for both s4.3 and s4.4, they may work better in s2.

s6, does Jim Schaad have anything else to add, perhaps attacks with
multiple object keys and the like?  Are there any other things he was
worried about from JOSE that didn't make it into this draft?

On 6/13/14, 2:01 PM, "Tim Bray" <[email-masked]> wrote:

>until the htmlized version and diff are available at
>tools.ietf.org <http://tools.ietf.org>.
>
>https://keybase.io/timbray <https://keybase.io/timbray>)
>
>
>

-- 
Joe Hildebrand

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 16 Jun 2014 16:14:15 +0900

> s2.1, s/always illegal/illegal/

s/illegal/invalid/

There may be jurisdictions where unpaired surrogates are outlawed, but I 
wouldn't know any :-).

Regards,   Martin.

---

From: Tim Bray <[email-masked]>
Date: Tue, 17 Jun 2014 10:53:40 -0700

OK, I just made an -02 pre-draft, anyone want to sanity check before I
submit?   Get it at
http://www.tbray.org/tmp/draft-ietf-json-i-json-02.html
http://www.tbray.org/tmp/draft-ietf-json-i-json-02.txt

diff at http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.tbray.org/tmp/draft-ietf-json-i-json-01.txt&url2=http://www.tbray.org/tmp/draft-ietf-json-i-json-02.txt

I took almost all the suggestions from reviewers except as follows:

> works.  Note that JOSE chose base64url for good reason.

Not sure I get this... for big numbers, it’s just digits, right?

> fail on processing than try to recover.  Alternately, that could go in the

I eventually decided that the last sentence of section 1 probably
meets our needs, but if someone wants to propose language, go for it.

---

From: John Cowan <[email-masked]>
Date: Tue, 17 Jun 2014 15:30:13 -0400

> Not sure I get this... for big numbers, it’s just digits, right?

Yes, but digits of what base?  Decimal, ça va sans dire; but it goes
even better when it is said.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
You cannot enter here.  Go back to the abyss prepared for you!  Go back!
Fall into the nothingness that awaits you and your Master.  Go! --Gandalf

---

From: Jacob Davies <[email-masked]>
Date: Tue, 17 Jun 2014 15:48:45 -0700

"For applications such as cryptography, where exact interchange of
much larger numbers is required, it is RECOMMENDED to encode them in
JSON string values."

The phrasing of "it is recommended to encode them" seems awkward to
me. Maybe "it is recommended that such values be encoded as"?

"encoded" also seems off. Maybe "written", "stored", "represented"?

I am not sure that cryptography is the right example. The most common
surprising case will be people trying to store arbitrary 64-bit
integers from commonplace types like Java longs and finding that most
of the value range can't be read & correctly represented in
Javascript. Those numbers might come from 64-bit hashes or storage
systems that assign evenly-distributed 64-bit IDs.

Cryptographic applications deal with much larger numbers, and are
already accustomed to exchanging them as binary, hex, or base64. I
doubt anyone would really even think of trying to send a 2048-bit key
as a JSON number.

---

From: Tim Bray <[email-masked]>
Date: Wed, 18 Jun 2014 08:07:07 -0700

> "encoded" also seems off. Maybe "written", "stored", "represented"?

​The recommend/encode terminology has been around for a while and ​this is
the first gripe I’ve heard. Anyone want to pile on?

> ​​
> ​​
> ​​
> integers
> ​​
​
​I confess to having cryptography on the brain.  I think he’s right, the
simplest example is just a 64-bit integer, might as well say that; will
change unless someone screams.

> from commonplace types like Java longs and finding that most
> JSON

---

From: Tim Bray <[email-masked]>
Date: Wed, 18 Jun 2014 08:12:48 -0700

Refreshed the -02 pre-drafts per Jacob Davies’s suggestions, see
http://www.tbray.org/tmp/draft-ietf-json-i-json-02.html or
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.tbray.org/tmp/draft-ietf-json-i-json-01.txt&url2=http://www.tbray.org/tmp/draft-ietf-json-i-json-02.txt

---

From: Matt Miller <[email-masked]>
Date: Wed, 18 Jun 2014 09:13:13 -0600

On 6/18/14, 9:07 AM, Tim Bray wrote:
> On Tue, Jun 17, 2014 at 3:48 PM, Jacob Davies <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> much larger numbers is required, it is RECOMMENDED to encode them
> in JSON string values."
> 
> The phrasing of "it is recommended to encode them" seems awkward
> to me. Maybe "it is recommended that such values be encoded as"?
> 
> ?The recommend/encode terminology has been around for a while and ?
> this is the first gripe I?ve heard. Anyone want to pile on? ???
> 
> ?? I am not sure that cryptography is the right example. The most
> common ?? surprising case will be people trying to store arbitrary
> 64-bit ?? integers ??
> 
> ? ?I confess to having cryptography on the brain.  I think he?s
> right, the simplest example is just a 64-bit integer, might as well
> say that; will change unless someone screams.
> 
> 

/me doffs hat

I think that makes sense.  It's a far more common issue for people to
run into than how to encode a key/ciphertext/signature.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.