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

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