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

"Jim Schaad" <> Sun, 20 July 2014 18:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A19421B27F0 for <>; Sun, 20 Jul 2014 11:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.144
X-Spam-Status: No, score=-0.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sPjxMTDKI-OL for <>; Sun, 20 Jul 2014 11:53:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 439D91B2CAF for <>; Sun, 20 Jul 2014 11:53:42 -0700 (PDT)
Received: from Philemon (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id E7B752CA1A; Sun, 20 Jul 2014 11:53:40 -0700 (PDT)
From: Jim Schaad <>
To: 'Larry Masinter' <>, 'Tim Bray' <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Sun, 20 Jul 2014 14:51:29 -0400
Message-ID: <092b01cfa44b$9eac7b00$dc057100$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_092C_01CFA42A.179E8480"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKov2vhk56OUbYXKcowgYH+SabU7AKM8BuiAOQA3dsCfBTaUgGv4WIyAp27E+MAhce3JJmhBzFA
Content-Language: en-us
Cc: 'Matt Miller' <>, 'IETF JSON WG' <>
Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Jul 2014 18:53:45 -0000

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.





From: json [] 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 [] 
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,


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 <> 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 <> 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 <> wrote:

> > Please review the document and send comments to the Working
> > Group mailing list < json at > or the co-chairs <json-chairs at
> > > 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.


json mailing list



- Tim Bray (If you’d like to send me a private message, see



- Tim Bray (If you’d like to send me a private message, see