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

On 3 November 2017 at 15:53, Willy Tarreau <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
>     possibly)
>
>   - SH1 : sends and receives up to 2^32-1
>
>   - SH1+: sends up to 2^32-1, receives up to 2^63-1
>
>   - SH2 : sends and receives up to 2^63-1
>
> This way we know that implementations within a same profile are
> interoperable,
> that SH1 and SH1+ are interoperable, and that SH1+ and SH2 are as well. SH1
> and SH2 are not, and SH0 is "good luck" (giving incentive to at least reach
> SH1).
>
>
​Isn't that the same as Mark's suggestion of carving out "i32" as its own
numeric type?  (Assuming other numeric types are defined as they're found
to be valuable.)  Except that it moves the profile from the implementation
to the header field definition.

My thought process:

If 'Foo' is an integer known/defined to be within [1,3600], say, then its
spec can say: "the value MUST be a <theoretical-unsigned-4digit-type>
between 1 and 3600, respectively".

If 'Bar' can be between negative-a-lot and positive-a-lot, its spec would
say "...MUST be a <theoretical-signed-19digit-type>...".

So, 'Foo' is parsed against `"0" / NONZERO *3(DIGIT)`​ and 'Bar' against `[
"-" ] ( "0" / NONZERO *18(DIGIT) )` or whatever.

Implementations that want to understand messages with 'Foo' header fields
need to be able to parse and operate on, effectively, uint16 data.

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.

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

Received on Friday, 3 November 2017 06:45:09 UTC