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

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:json-bounces@ietf.org] 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

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:tbray@textuality.com] 
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 <masinter@adobe.com> wrote:

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 <tbray@textuality.com> 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 <masinter@adobe.com> wrote:

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

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

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

-- 

- 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)