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

--------
In message <CANatvzx1mASDCBKdFNWWHAK5SFB-wv5F0n+NvD0R7K9cRGMyBA@mail.gmail.com>
, 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.

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.

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
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Thursday, 17 November 2016 10:21:31 UTC