Re: Precision of numbers using JSON Header Field Values

Hello,

Thank you for the response.

2016-07-15 16:10 GMT+09:00 Julian Reschke <julian.reschke@gmx.de>:
> On 2016-07-15 06:13, Kazuho Oku wrote:
>>
>> Hello,
>>
>> I have a question about how numbers are going to be handled using JSON
>> Header Field Values.
>>
>> In section 6.1, the draft uses Content-Length header as an example,
>> and states that in case the header is to be represented using JSON,
>> the definition should "restrict all numbers to be non-negative
>> integers without fractions."
>>
>> Does this mean that numbers should not be expressed using the
>> exponential notation (which would mean that we would be adding a
>> restriction to JSON encoder / parser), or does it mean that we should
>> validate the number _after_ parsing it using method defined in RFC
>> 7159?
>> ...
>
>
> That's a good point, and (as the uniqueness issue) a general weakness of
> JSON.
>
> We could:
>
> 1) Mandate that all numeric values need to be transferred as strings
> (loosing some of the benefits), or

I'm afraid that would not be a practical option.

In order to prevent security issues, we would need to specify that
decoders MUST reject JSON numbers.

However, I assume it would be difficult to implement such a
requirement in certain programming languages that do not provide a
well-defined way to distinguish between a numeric type and a string
type (e.g. Perl, PHP).

> 2) Require use of I-JSON (https://tools.ietf.org/html/rfc7493)
> generators/parsers (loosing lots of potential implementations).
>
> Best regards, Julian



-- 
Kazuho Oku

Received on Friday, 15 July 2016 07:48:27 UTC