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

[Kazuho Oku <[e-mail]>]

2016-11-17 19:21 GMT+09:00 Poul-Henning Kamp <[e-mail]>:
> --------
> In message <[e-mail]>
> , Kazuho Oku writes:
>
>>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'
>
> So this is clearly something the draft needs to explain better.
>
> CS does not decide what values are legal and which are not, it only
> helps you transport values safely across the wire.
>
> When you define your header you define the kind of values it accepts,
> and if you say that "value X is an integer", it should be pretty
> obvious to anybody that sending it as "100.0" is not OK.
>
> If you think people will not get that fine detail right, you can
> add text to your header definition which drives the point home.
>
>>you would need to decode a floating point number even in the case
>>where you only need to deal with integers.
>
> So this brings up an interesting efficiency detail related to the
> HTTP1 serialization:
>
> You cannot tell the difference between an identifier and a number
> by looking at the data on the wire, because RFC7230::token allows
> both DIGIT, "." and "-".
>
> Your parser will therefore initially classify any "number" as
> "identifier", and only once your application code tells it that it
> expects an integer, will that string be interpreted as a number.
>
> That means that no numeric processing needs to happen until it
> is unavoidable.
>
> (Any design I can imagine for a future HPACK/H3 semantic compression
> will have the same property.)
>
> As I hint in 7.2 as "Future work", having the individual headers
> defined in a machine readble format (a "schema") would allow us to
> use programs to generate combined CS parser+validator for such a
> header.

Once we start people using CS to define new headers, I think I'd be
likely writing a parser generator handle them, regardless of whether
if a schema language is defined as a specification.

The generated parser would just deserialize the properties that the
application care of, while skipping unknown parameters.

> However, history is particularly unkind to that concept, so I
> left it in "Future work" and I think we should leave it there
> for now.
>
>>My understanding is that most (if not all) headers that will use
>>Common Structure would need to encode floating point numbers.
>
> I don't think so.
>
> First, just because they look like floating point numbers in the
> H1 serialization, doesn't mean you have to process them as IEEE754
> in your application.
>
> If I recall right, the q= weights can be processed as integer
> "milli-q", and still be compliant.  In reality comparison of q=
> weights is very often done as strings.
>
> Second, apart from q= and possibly future timestamps, I don't see
> much call for fractional numbers anyhow[1].
>
> All that said, it probably does makes good sense to have "integer"
> as a special case of "number", like "ascii_string" is a subset of
> "unicode_string", because it will make it easier for people
> to specify their HTTP headers.

Thank you for considering that. I think that would be a good move.

> Poul-Henning
>
> [1]  Somebody will undoubtedly use them for monetary values, but I
>      have a hard time seeing that make it into a published RFC for
>      many reasons.
>
> --
> 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