Re: [Json] I-D Action: draft-ietf-json-i-json-01.txt

[Tim Bray <[e-mail]>]

Refreshed the -02 pre-drafts per Jacob Davies’s suggestions, see
http://www.tbray.org/tmp/draft-ietf-json-i-json-02.html or
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.tbray.org/tmp/draft-ietf-json-i-json-01.txt&url2=http://www.tbray.org/tmp/draft-ietf-json-i-json-02.txt


On Wed, Jun 18, 2014 at 8:07 AM, Tim Bray <[e-mail]> wrote:

> On Tue, Jun 17, 2014 at 3:48 PM, Jacob Davies <[e-mail]> wrote:
>
>> "For applications such as cryptography, where exact interchange of
>> much larger numbers is required, it is RECOMMENDED to encode them in
>> JSON string values."
>>
>> The phrasing of "it is recommended to encode them" seems awkward to
>> me. Maybe "it is recommended that such values be encoded as"?
>>
>> "encoded" also seems off. Maybe "written", "stored", "represented"?
>>
>
> ​The recommend/encode terminology has been around for a while and ​this is
> the first gripe I’ve heard. Anyone want to pile on?
> ​​​
>
>> ​​
>> I am not sure that cryptography is the right example. The most common
>> ​​
>> surprising case will be people trying to store arbitrary 64-bit
>> ​​
>> integers
>> ​​
>>
> ​
> ​I confess to having cryptography on the brain.  I think he’s right, the
> simplest example is just a 64-bit integer, might as well say that; will
> change unless someone screams.
>
>
>
>
>
>> from commonplace types like Java longs and finding that most
>> of the value range can't be read & correctly represented in
>> Javascript. Those numbers might come from 64-bit hashes or storage
>> systems that assign evenly-distributed 64-bit IDs.
>>
>> Cryptographic applications deal with much larger numbers, and are
>> already accustomed to exchanging them as binary, hex, or base64. I
>> doubt anyone would really even think of trying to send a 2048-bit key
>> as a JSON number.
>>
>> On Tue, Jun 17, 2014 at 12:30 PM, John Cowan <[e-mail]>
>> wrote:
>> > Tim Bray scripsit:
>> >
>> >> > s2.2, "For applications such as cryptography, where exact
>> interchange of
>> >> > much larger numbers is required, it is RECOMMENDED to encode them in
>> JSON
>> >> > string values", I suggest adding some guidance on encoding if we
>> have a
>> >> > quick consensus on decimal|hex|base64url|etc.  Otherwise leaving it
>> as-is
>> >> > works.  Note that JOSE chose base64url for good reason.
>> >>
>> >> Not sure I get this... for big numbers, it’s just digits, right?
>> >
>> > Yes, but digits of what base?  Decimal, ça va sans dire; but it goes
>> > even better when it is said.
>> >
>> > --
>> > John Cowan          http://www.ccil.org/~cowan        [e-mail]
>> > You cannot enter here.  Go back to the abyss prepared for you!  Go back!
>> > Fall into the nothingness that awaits you and your Master.  Go!
>> --Gandalf
>> >
>> > _______________________________________________
>> > json mailing list
>> > [e-mail]
>> > 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)