Re: [Json] Working Group Last Call on draft-ietf-i-json-02
Larry Masinter <masinter@adobe.com> Thu, 17 July 2014 22:11 UTC
Return-Path: <masinter@adobe.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EDD1A0334 for <json@ietfa.amsl.com>; Thu, 17 Jul 2014 15:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.554
X-Spam-Level:
X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvD3hn3Q11VU for <json@ietfa.amsl.com>; Thu, 17 Jul 2014 15:11:22 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9295D1B2807 for <json@ietf.org>; Thu, 17 Jul 2014 15:11:21 -0700 (PDT)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 17 Jul 2014 22:11:20 +0000
Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0990.007; Thu, 17 Jul 2014 22:11:20 +0000
From: Larry Masinter <masinter@adobe.com>
To: Matt Miller <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>
Thread-Topic: [Json] Working Group Last Call on draft-ietf-i-json-02
Thread-Index: AQHPlNXlZXjIN4zZsUWNV5uEVDZbg5ubhyYAgAAR0ACAABhQgIAHdhhQgAADpYCAAaFlgIAAB7+AgAAVpqA=
Date: Thu, 17 Jul 2014 22:11:19 +0000
Message-ID: <8a315f85c2704f2a828bdbd5f4ca09b7@BL2PR02MB307.namprd02.prod.outlook.com>
References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> <c8391b02d1f045ce85747420d7f9e756@BL2PR02MB307.namprd02.prod.outlook.com> <CAHBU6itqj-Fg05=ybKCEs9NTYjTM=gtS7=e8mCVTP1GwfjcNxQ@mail.gmail.com> <3b1rk4x0d2dwsnvbr0w1wjya.1405535654838@email.android.com> <CAHBU6iuHp+YgGJPFkmW56PqOi1g5ctTv4Z4Re=DKO2Hjmvf_0w@mail.gmail.com> <f44a34b22e4c42dc8f6164d8ece5a934@BL2PR02MB307.namprd02.prod.outlook.com> <53C83403.6030809@cisco.com>
In-Reply-To: <53C83403.6030809@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [97.94.246.70]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 027578BB13
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(52044002)(189002)(199002)(13464003)(24454002)(377454003)(479174003)(106116001)(20776003)(77982001)(79102001)(106356001)(21056001)(95666004)(92566001)(66066001)(80022001)(105586002)(4396001)(76482001)(19580395003)(33646002)(76576001)(46102001)(86362001)(64706001)(99286002)(99396002)(101416001)(19580405001)(575784001)(15202345003)(15975445006)(50986999)(76176999)(107046002)(54356999)(74662001)(74316001)(81342001)(85306003)(83072002)(93886003)(85852003)(74502001)(81542001)(87936001)(2656002)(16601075003)(31966008)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/json/f2kQmWaWmIQ12h_b-XFRbHOg2Y4
Cc: IETF JSON WG <json@ietf.org>
Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jul 2014 22:11:30 -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:mamille2@cisco.com] 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 /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 < mamille2@cisco.com > 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: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 > <mailto: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 <mailto: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 > <mailto:masinter@adobe.com>> wrote: > >>> Please review the document and send comments to the Working 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 >>> 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 <mailto: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) > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTyDQDAAoJEDWi+S0W7cO1VtAH/3a/g4wCIX1RIcc3d9kyArAU +BueHk2g9M2yiOkdjsPOpZQhZ5N5KS4Egxt6i7R2/WhBisdwxmJ9HS8rzKLUDNCi FCDc2CXjF701qAj5fkBhQGOHCvRR58tnEW19xM4gYtG5WG27qus+8dF8FSJWYhOY UKc1k7wTrWlZRbjyzfPNuHWQbIMPEg9mhfMF7PtSqqkINv3Vao9gWTdYiwKM8NgP MagyMcuOg/vgC1wQpwwWhNSjMIRwGZkqUVLcG4du6OKFkxqy6EZFtPU+TdcAzgF2 QSuwtS29TzK1BUw04cqjKl+G2vIjrqwgxLPUY6dYpaiWpSMFbxjz6ESBUKznsZ8= =YTK7 -----END PGP SIGNATURE-----
- [Json] Working Group Last Call on draft-ietf-i-js… Matt Miller
- Re: [Json] Working Group Last Call on draft-ietf-… Mark Nottingham
- Re: [Json] Working Group Last Call on draft-ietf-… R S
- Re: [Json] Working Group Last Call on draft-ietf-… Tim Bray
- Re: [Json] Working Group Last Call on draft-ietf-… Mark Nottingham
- Re: [Json] Working Group Last Call on draft-ietf-… Larry Masinter
- Re: [Json] Working Group Last Call on draft-ietf-… Matt Miller
- Re: [Json] Working Group Last Call on draft-ietf-… Tim Bray
- Re: [Json] Working Group Last Call on draft-ietf-… John Cowan
- Re: [Json] Working Group Last Call on draft-ietf-… Markus Lanthaler
- Re: [Json] Working Group Last Call on draft-ietf-… Erik Wilde
- Re: [Json] Working Group Last Call on draft-ietf-… Matthew Morley
- Re: [Json] Working Group Last Call on draft-ietf-… Tim Bray
- Re: [Json] Working Group Last Call on draft-ietf-… Markus Lanthaler
- Re: [Json] Working Group Last Call on draft-ietf-… Tim Bray
- Re: [Json] Working Group Last Call on draft-ietf-… Larry Masinter
- Re: [Json] Working Group Last Call on draft-ietf-… Tim Bray
- Re: [Json] Working Group Last Call on draft-ietf-… Larry Masinter
- Re: [Json] Working Group Last Call on draft-ietf-… Matt Miller
- Re: [Json] Working Group Last Call on draft-ietf-… Larry Masinter
- Re: [Json] Working Group Last Call on draft-ietf-… Jim Schaad