Re: Precision of numbers using JSON Header Field Values

On Fri, Jul 15, 2016 at 09:28:30AM +0200, Julian Reschke wrote:
> On 2016-07-15 09:22, Poul-Henning Kamp wrote:
> > --------
> > In message <a456ceb8-4b6e-a49f-02a0-6ebf3384ad8a@gmx.de>, Julian Reschke writes
> > :
> > 
> > > 1) Mandate that all numeric values need to be transferred as strings
> > > (loosing some of the benefits), or
> > > 
> > > 2) Require use of I-JSON (https://tools.ietf.org/html/rfc7493)
> > > generators/parsers (loosing lots of potential implementations).
> > 
> > I-JSON is probably the better of those two alternatives, despite
> > the fact that the restrictions it mandates can be very hard to
> > implement correctly and efficiently (in particular the unicode
> > restrictions).
> > 
> > The 3. alternative which you didn't list gets my vote:
> > 
> > 3) Don't use JSON.
> 
> I do not disagree with that. That's certainly an option. In that case we'd
> be discussing a textual format that can be shared across header fields, so
> that people at least can use a single parser.

While I'm not fond of JSON I think that *if it satisfies our needs* it
provides an overall rich set of possibilities and is widely supported. But
if we're seeing corner cases which require parsers to perform some difficult
verifications maybe we'll cause less trouble by proposing a very specific
and strict language for which parsers will eventually be implemented anyway.

I must say that right now I'm worried with the lack of distinction between
an integer and a float. Some fields like a content-length or a byte-range
definitely require a strict integer.

Regards,
Willy

Received on Saturday, 16 July 2016 09:05:28 UTC