Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02

From: Matt Miller <[email-masked]>
Date: Fri, 11 Jul 2014 16:35:26 -0600

On 6/30/14, 8:39 PM, Matt Miller wrote:
> This message begins the  Working Group Last Call (WGLC) on "The
> I-JSON Message Format" < draft-ietf-json-i-json-02 >. WGLC will end
> in two weeks, on July 14.
> 
> Please review the document and send comments to the Working Group 
> mailing list < json at ietf.org > or the co-chairs <json-chairs at 
> tools.ietf.org > before the end of the WGLC.  Any and all comments
> on the document are sought in order to asses the strength of
> consensus. Even if you have read and commented on this or earlier
> versions of the draft, please feel free to comment again.
> 
> As a reminder, comments can be anything from "this looks fine" to 
> "this is a horrible idea"; they can include suggestions for minor 
> editorial corrections to significant editorial changes.
> 
> 

Note that Working Group Last Call ends on Monday (07/14).  What has
been brought to the list to date is:

* correction on the reference to RFC 7149 (should be RFC 7159)
* some discussion about a profile URL

We want to hear from as many as possible, even if the comment is
"looks good to me".

If you've been waiting until the last minute to say something, you can
stop waiting! (-:

- -- Paul Hoffman and Matt Miller

---

From: Larry Masinter <[email-masked]>
Date: Fri, 11 Jul 2014 23:51:58 +0000

> > Please review the document and send comments to the Working
> > Group mailing list < json at ietf.org > or the co-chairs <json-chairs at

I think I originally supported the development of I-JSON as
useful named profile of JSON. However, based on recent discussions
and further examination, my opinion now is that the particular
collection of constraints isn't special, and the document should
instead be recast as a "Best Practices for Internet Use of JSON".
To facilitate using the document as a normative reference, each
constraint/best practice could be named "no-dup-names",
"ieee-numbers", "utf8". If you then want to name the union
of all constraints in the document as "i-json" that would be OK.

Most of the document (including the normative language
associated with each constraint) would remain, but the emphasis
on "i-json" as a unique and complete profile wouldn't, and 
would make it easier for referencing applications to choose
those constraints that are meaningful for them.

Larry
--
http://larry.masinter.net

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Jul 2014 18:06:13 -0700

Well, I think this discussion sort of already happened, but here’s the
existence proof: If I-JSON had existed at the time JOSE was getting going,
they could have simplified their specs, and implementers’ lives, with the
following statement: Use I-JSON.

Also, the collection of constraints IS special: It covers everything that
7159 calls out as an interoperability problem, and says “don’t do that’.

On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter <[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: John Cowan <[email-masked]>
Date: Fri, 11 Jul 2014 22:19:08 -0400

> instead be recast as a "Best Practices for Internet Use of JSON".

-1

> "ieee-numbers", "utf8". 

This, however, would be a Good Thing.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
I don't know half of you half as well as I should like, and I like less
than half of you half as well as you deserve.  --Bilbo

---

From: "Markus Lanthaler" <[email-masked]>
Date: Mon, 14 Jul 2014 22:58:58 +0200

> We want to hear from as many as possible, even if the comment is

As already said, I think it would be a good idea to mint and register a
profile URI.

--
Markus Lanthaler
@markuslanthaler

---

From: Erik Wilde <[email-masked]>
Date: Tue, 15 Jul 2014 06:38:40 +0200

> On 14 Jul 2014, at 22:58, "Markus Lanthaler" <[email-masked]> wrote:
> 

+1

cheers,

dret.

---

From: Matthew Morley <[email-masked]>
Date: Tue, 15 Jul 2014 09:59:11 -0400

> We want to hear from as many as possible, even if the comment is

I'm a little late to reply, but looks good to me.

-- 
Matthew P. C. Morley

---

From: Tim Bray <[email-masked]>
Date: Tue, 15 Jul 2014 07:39:30 -0700

Is there an example of such a profile proving useful to application
builders?  Haven’t encountered one myself but I assume there must be some
out there.

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 16 Jul 2014 16:45:08 +0200

On Tuesday, July 15, 2014 4:40 PM, Tim Bray wrote:
> builders?  Haven’t encountered one myself but I assume there must be
> some out there.

We defined some profiles for JSON-LD [1] which make it possible for app developers to request the data to be serialized in a specific way (there are typically multiple ways to serialize the same graph).

> On Mon, Jul 14, 2014 at 1:58 PM, Markus Lanthaler <[email-masked]> wrote:

[1] http://www.w3.org/TR/json-ld/#iana-considerations

--
Markus Lanthaler
@markuslanthaler

---

From: Tim Bray <[email-masked]>
Date: Wed, 16 Jul 2014 07:54:09 -0700

On Wed, Jul 16, 2014 at 7:45 AM, Markus Lanthaler <[email-masked]>
wrote:

> > builders?
> We defined some profiles for JSON-LD [1] which make it possible for app
> developers to request the data to be serialized in a specific way (there
> are typically multiple ways to serialize the same graph).
>

​That’s nice in theory; are there any actual real applications that actual
real people actually really use that derive any benefit from this?​

---

From: Larry Masinter <[email-masked]>
Date: Wed, 16 Jul 2014 19:02:41 +0000

I think at least one motivating use case is called for, if not more.

But scanning the JOSE documents, I didn't find where you would use I-JSON instead. Could you point it out?

Tim Bray <[email-masked]> wrote:

Well, I think this discussion sort of already happened, but here's the existence proof: If I-JSON had existed at the time JOSE was getting going, they could have simplified their specs, and implementers' lives, with the following statement: Use I-JSON.

Also, the collection of constraints IS special: It covers everything that 7159 calls out as an interoperability problem, and says "don't do that'.

On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter <[email-masked]<mailto:[email-masked]>> wrote:
> > Group mailing list < json at ietf.org<http://ietf.org> > or the co-chairs <json-chairs at
> > tools.ietf.org<http://tools.ietf.org> > before the end of the WGLC.  Any and all comments

Larry

_______________________________________________
json mailing list
[email-masked]<mailto:[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: Tim Bray <[email-masked]>
Date: Wed, 16 Jul 2014 12:15:45 -0700

For example,
http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#section-4

If I-JSON were published, they’d switch to it in the blink of an eye, based
on previous conversations.

On Wed, Jul 16, 2014 at 12:02 PM, Larry Masinter <[email-masked]> wrote:

>  Also, the collection of constraints IS special: It covers everything
> that 7159 calls out as an interoperability problem, and says “don’t do
> that’.
>
>

---

From: Larry Masinter <[email-masked]>
Date: Thu, 17 Jul 2014 20:18:29 +0000

There’s nothing in that section about IEEE floating point (or anywhere else in JOSE that I can find. And i-json doesn’t say anything about canonicalization, which would likely be what JOSE needs.

“they’d switch to it in the blink of an eye” seems like an underestimate by several orders of magnitude.

My point is that there is no obvious way that JOSE could make normative reference to the i-json document as it stands, even if everyone agreed to it (but agreement would depend on the details of what the reference said).

From: Tim Bray [mailto:[email-masked]]
sSent: Wednesday, July 16, 2014 12:16 PM
To: Larry Masinter
Cc: Matt Miller; IETF JSON WG
Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02

For example, http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#section-4

If I-JSON were published, they’d switch to it in the blink of an eye, based on previous conversations.

On Wed, Jul 16, 2014 at 12:02 PM, Larry Masinter <[email-masked]<mailto:[email-masked]>> wrote:
I think at least one motivating use case is called for, if not more.

Tim Bray <[email-masked]<mailto:[email-masked]>> wrote:
Well, I think this discussion sort of already happened, but here’s the existence proof: If I-JSON had existed at the time JOSE was getting going, they could have simplified their specs, and implementers’ lives, with the following statement: Use I-JSON.

Also, the collection of constraints IS special: It covers everything that 7159 calls out as an interoperability problem, and says “don’t do that’.

Larry

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

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

---

From: Matt Miller <[email-masked]>
Date: Thu, 17 Jul 2014 14:37:23 -0600

/me doffs hat.

Speaking as an active participant of the JOSE WG since its charter:

As far as I can tell, I-JSON contains everything that the JOSE WG has
reached consensus on but is lacking from RFC 7159.

- -- 
- - m&m

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

On 7/17/14, 2:18 PM, Larry Masinter wrote:
> There’s nothing in that section about IEEE floating point (or
> anywhere else in JOSE that I can find. And i-json doesn’t say
> anything about canonicalization, which would likely be what JOSE
> needs.
> 
> 
> 
> “they’d switch to it in the blink of an eye” seems like an
> underestimate by several orders of magnitude.
> 
> 
> 
> My point is that there is no obvious way that JOSE could make
> normative reference to the i-json document as it stands, even if
> everyone agreed to it (but agreement would depend on the details of
> what the reference said).
> 
> 
> 
> *From:*Tim Bray [mailto:[email-masked]] *sSent:* Wednesday,
> July 16, 2014 12:16 PM *To:* Larry Masinter *Cc:* Matt Miller; IETF
> JSON WG *Subject:* Re: [Json] Working Group Last Call on
> draft-ietf-i-json-02
> 
> 
> 
> For example,
> On Wed, Jul 16, 2014 at 12:02 PM, Larry Masinter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Tim Bray <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> Well, I think this discussion sort of already happened, but here’s 
> the existence proof: If I-JSON had existed at the time JOSE was 
> getting going, they could have simplified their specs, and 
> implementers’ lives, with the following statement: Use I-JSON.
> 
> 
> 
> Also, the collection of constraints IS special: It covers
> everything that 7159 calls out as an interoperability problem, and
> says “don’t do that’.
> 
> 
> 
> On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> Group mailing list < json at ietf.org <http://ietf.org> > or
> the co-chairs <json-chairs at
>>> tools.ietf.org <http://tools.ietf.org> > before the end of
> the WGLC.  Any and all comments
> I think I originally supported the development of I-JSON as useful
> named profile of JSON. However, based on recent discussions and
> further examination, my opinion now is that the particular 
> "ieee-numbers", "utf8". If you then want to name the union of all
> constraints in the document as "i-json" that would be OK.
> 
> Most of the document (including the normative language associated
> with each constraint) would remain, but the emphasis on "i-json" as
> a unique and complete profile wouldn't, and would make it easier
> for referencing applications to choose those constraints that are
> meaningful for them.
> 
> Larry -- http://larry.masinter.net
> 
> 
> 
> _______________________________________________ json mailing list 
> [email-masked] <mailto:[email-masked]>

---

From: Larry Masinter <[email-masked]>
Date: Thu, 17 Jul 2014 22:11:19 +0000

I think you're saying the JOSE working group hasn't added any such
constraints in 31 versions but has rough consensus, and are only 
lacking i-json to be documented to simplify specifying the constraints?

 I still can't tell what the normative reference to i-json from JOSE documents would look like.
Would you normalize to i-json before signing (like XML digital signatures normalizes XML before signing), and what would that mean? For duplicate attributes, numbers with precision higher or numbers out of range of IEEE?

Or would you define JSON signatures to only work on i-json? Or is it a constraint on the signature object itself? 

For example, i-json says 
"I-JSON
   messages SHOULD NOT include numbers which express greater magnitude
   or precision than an IEEE 754 double precision number provides, for
   example 1E400 or 3.141592653589793238462643383279."

So.. what does this SHOULD NOT mean for JOSE. You SHOULD NOT sign such messages?
SHOULD NOT rely on the results?

I hope I'm making my point... I'm just asking for a concrete use case where the current i-json document is actually useful. Just one. But actually useful, not maybe-kindof-sorta close in spirit. 

Maybe JOSE is too complicated?

Larry

-----Original Message-----
From: Matt Miller [mailto:[email-masked]] 
Sent: Thursday, July 17, 2014 1:37 PM
To: Larry Masinter; Tim Bray
Cc: IETF JSON WG
Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02

/me doffs hat.

As far as I can tell, I-JSON contains everything that the JOSE WG has reached consensus on but is lacking from RFC 7159.

- --
- - m&m

On 7/17/14, 2:18 PM, Larry Masinter wrote:
> There’s nothing in that section about IEEE floating point (or anywhere 
> else in JOSE that I can find. And i-json doesn’t say anything about 
> canonicalization, which would likely be what JOSE needs.
> 
> 
> 
> *From:*Tim Bray [mailto:[email-masked]] *sSent:* Wednesday, July 
> 16, 2014 12:16 PM *To:* Larry Masinter *Cc:* Matt Miller; IETF JSON WG 
> *Subject:* Re: [Json] Working Group Last Call on
> draft-ietf-i-json-02
> 
> 
> 
> For example,
> existence proof: If I-JSON had existed at the time JOSE was getting 
> going, they could have simplified their specs, and implementers’ 
> lives, with the following statement: Use I-JSON.
> 
> 
> 
>>> mailing list < json at ietf.org <http://ietf.org> > or
> further examination, my opinion now is that the particular collection 
> of constraints isn't special, and the document should instead be 
> recast as a "Best Practices for Internet Use of JSON".
> Most of the document (including the normative language associated with 
> each constraint) would remain, but the emphasis on "i-json" as a 
> unique and complete profile wouldn't, and would make it easier for 
> referencing applications to choose those constraints that are 
> meaningful for them.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 20 Jul 2014 14:51:29 -0400

Currently there are no issues for JOSE dealing with numbers, however there is a big issue dealing with the fact that there needs to only be one named item at any given lexical scope.   This was one of the things that I was pushing for on the JSON update but was roundly defeated on.

Jim

From: json [mailto:[email-masked]] On Behalf Of Larry Masinter
Sent: Thursday, July 17, 2014 4:18 PM
To: Tim Bray
Cc: IETF JSON WG; Matt Miller
Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02

Larry

 

-- 

 

--