Re: New Version Notification for draft-kamp-httpbis-structure-01.txt (fwd)

[Kazuho Oku <[e-mail]>]

2016-11-17 17:34 GMT+09:00 Poul-Henning Kamp <[e-mail]>:
> --------
> In message <[e-mail]>
> , Kazuho Oku writes:
>
>>Yes. Therefore, I believe that the we should discourage people from
>>using fixed point numbers.
>
> That ship has already sailed since q=0.5 does not use integers.
>
> But please note that this is a generic *data model*, and therefore
> it should "deliver tools, not policies".

Hi,

Thank you for the response. I totally support your intention to
deliver tools, not policies.

My point is that the draft should not “enforce a policy” to implement
floating point parsers even in case you need to only handle integers.

For example, consider the case in which I am writing a draft that
passes an integer using Common Structure.

Since Common Structure allows an integral number to be sent with a
dot, a sender is permitted to send 100 as “100.00”, which means that
you would need to decode a floating point number even in the case
where you only need to deal with integers.

My understanding is that most (if not all) headers that will use
Common Structure would need to encode floating point numbers. And
therefore I am looking for a clause that makes decoders without a
floating point parser to be comformant to the specification (until
actually facing a need to decode floating points).

> By this I mean that people may legitimately want to move non-integers,
> deep structures and unicode strings, and it would be counterproductive
> to force them to invent a parallel format to do that.
>
> However, each individual header will have to define which _actual_
> data you are allowed to put in it, and a general antipathy against
> non-integers is probably wise there.
>
> Summary: So if you don't like non-integers, don't use them in the
> HTTP-headers you invent, but don't tell other people what data
> types they are allowed to use.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> [e-mail]         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.



-- 
Kazuho Oku