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)