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

On 10/31/2017 06:58 PM, Kazuho Oku wrote:
> 2017-11-01 1:07 GMT+09:00 Alex Rousskov <rousskov@measurement-factory.com>:
>> The draft already mandates support for (signed) 64-bit integers AFAICT:
>>>    integer = ["-"] 1*19 DIGIT


> I think you that you might be referring to Common Header Structure [1]
> instead of Structured Headers [2].
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/?include_text=1
> [2] https://mnot.github.io/I-D/structured-headers/


Sigh. You are right! My apologies, and please reinterpret my post as a
regression bug report.

IMHO, structured headers ought to support 64-bit integers. I have not
heard about any use cases where such a requirement would make an
interoperable implementation impossible, but perhaps I have missed it.

I do not understand why a temporary lack of native mapping in a popular
programming language is a show stopper. Yes, Javascript programs cannot
support 64-bit integers natively today, but:

* There are many modules that allow for 64-bit integer support.

* There is a Stage 3 proposal for native support in the future version
  of ECMAScript[3]. Lack of 64-bit integers is a known pain point for
  Javascript. If Javascript continues to evolve, it will be addressed.
  I would be surprised if the latest Javascript standard does not
  support 64-bit integers natively in a few years.

  [3] https://github.com/tc39/proposal-bigint

* Sane Javascript programs will parse Structured Headers using a
  specialized module. To a non-expert, adding one more module (for
  64bit integer support) does not seem like such a big deal in this
  context, even outside a node js environment.

A suggestion to use binary blobs instead of 64-bit integers seems flawed
to me because it is restricted to identifiers and because binary blobs
do not have good native support in auto-encoding-prone Javascript.


Cheers,

Alex.

Received on Wednesday, 1 November 2017 03:08:04 UTC