- From: Andy Green <andy@warmcat.com>
- Date: Fri, 3 Nov 2017 15:13:23 +0800
- To: Matthew Kerwin <matthew@kerwin.net.au>, Willy Tarreau <w@1wt.eu>
- Cc: Mark Nottingham <mnot@mnot.net>, Kazuho Oku <kazuhooku@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
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>> > 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. 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. If a limit is ok, that the supported values doesn't fit conveniently in the natural type for the platform is unrelated IMHO. 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? -Andy
Received on Friday, 3 November 2017 07:14:37 UTC