Re: New Version Notification for draft-nottingham-structured-headers-00.txt

On 11/03/2017 03:40 PM, Matthew Kerwin wrote:
> 
> 
> On 3 November 2017 at 17:13, Andy Green <andy@warmcat.com 
> <mailto:andy@warmcat.com>> wrote:
> 
> 
> 
>     On 11/03/2017 02:44 PM, Matthew Kerwin wrote:
> 
> 
> 
>         On 3 November 2017 at 15:53, Willy Tarreau <w@1wt.eu
>         <mailto:w@1wt.eu> <mailto:w@1wt.eu <mailto:w@1wt.eu>>> wrote:
> 
> 
>              A possible solution derivating from the suggestions above could
>              simply be
>              to define a few profiles for Structured Headers :
>                 - SH0 : the lowest level, implementations do not support
>         receiving as
>                   large values as specified in next level (eg: my alarm
>         clock's
>              ESP8266
> 
> 
>         Implementations that want to speak 'Bar' but don't have native
>         int64 support deal with edge-cases either by using an
>         integer-extending library, or by being non-compliant.  But if
>         'Bar' can definitely, reasonably, contain values beyond what the
>         implementation can deal with, then that implementation was never
>         going to be interoperable anyway.
> 
> 
>     I hesitate to bring it up but what about MPINT / BIGINT?  They're
>     integers too.
> 
> 
> ​That's exactly what I meant by "integer-extending library".  I picked 
> 19-digit-number and int64 because they're convenient for discussion, not 
> because I care about the particular numbers.​

...

>        If you don't want a limit, then a way to escape to a
>     representation with a length + MSB payload will also be able to
>     carry keys.
> 
> 
> ​Sorry, I can't parse that.  If you don't want a limit for your 
> particular header, don't use the common structure to define it.​

... Willy is proposing some kind of capability profiles with fixed 
limits at 32-bit etc: that's what you had replied to.  I don't think 
that's going to give a nice result.

There seems to be a basic choice to have some strict integer limit, or 
to avoid it by having a "stretchy" way to have arbitrary-sized ints.  If 
people are OK with a strict limit, 64-bit is very widely supported at C 
level even down on "ESP8266" Willy mentioned.  I think a 32-bit limit is 
a non-starter.

>     If a limit is ok, that the supported values doesn't fit conveniently
>     in the natural type for the platform is unrelated IMHO.
> 
> 
> ​Indeed.​
> 
>        After all ESP8266 / 32 can do RSA via BIGINT / MPINT.  And the
>     compiler for ESP8266 / ESP32 supports a 64-bit long long, there's no
>     barrier to using it.  As already mentioned filesizes long ago made a
>     32-bit limit not very useful.  So doesn't it make sense to just
>     require 64-bit if there's to be a simple limit?
> 
> ​
> If your implementation has trouble dealing with certain values (having 
> to rely on more-complicated data structures, algorithms, memory 
> allocations, etc), and you want to optimise for 
> throughput/simplicity/etc., and the header is clearly defined to have a 
> limit within what you can handle natively, why not be able to take 
> advantage of that?  I'm thinking of JavaScript (including Node.js) here, 
> by the way, which stores all its numbers in IEEE 754 floats.

No, floats are not ints and cannot reliably be converted into them. 
They are a lossy approximation format.  For example you cannot put key 
BIGINTs into floats.

If there's demand for floats of course they can also be handled, but 
they can't be conflated with integers just 'cos node.

Also eg, ESP8266 Willy mentioned has compiler support for 64-bit long 
long.  It has no hw float or double.

-Andy

> Cheers
> -- 
>    Matthew Kerwin
> http://matthew.kerwin.net.au/

Received on Friday, 3 November 2017 07:54:52 UTC