Subject: [Last-Call] Genart last call review of draft-ietf-httpbis-header-structure-18

From: David Schinazi via Datatracker <[email-masked]>
Date: Mon, 04 May 2020 18:18:08 -0700

Reviewer: David Schinazi
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-httpbis-header-structure-18
Reviewer: David Schinazi
Review Date: 2020-05-04
IETF LC End Date: 2020-05-04
IESG Telechat date: Not scheduled for a telechat

Summary: This document was clear and well-written. I found no issues and noted
some number of small nits below.

Major issues: None

Minor issues: None

Nits/editorial comments:

In s1.2 (Notational Conventions), I didn't understand what greedy meant in:
   In some places, the algorithms are "greedy" with
   whitespace, but this should not affect conformance.

In s2 (Defining New Structured Fields), perhaps "Reference this specification."
  should instead be "Normatively reference this specification." ?

In s2, the definition of Foo-Example Header seems to be enclosed in
  "--8<--" and "-->8--" in the TXT version, could be a bug in the tools?

In s3.1.2 and s3.2, in the example, I was confused by "a=?0" and "b=?0" until I
s3.3.6.
    Perhaps reordering sections or adding a reference would help?

Should there be some guidance for defining new integer fields that don't fit in
10^15?
    Is a String the recommended approach?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 5 May 2020 15:02:07 +1000

Hi David,

Thanks for the comments. Responses below; I've committed in <https://github.com/httpwg/http-extensions/commit/001023>.

> On 5 May 2020, at 11:18 am, David Schinazi via Datatracker <[email-masked]> wrote:
> 
> Nits/editorial comments:
> 

Hmm, I think we can remove that sentence.

>  should instead be "Normatively reference this specification." ?

Sounds good.

>  "--8<--" and "-->8--" in the TXT version, could be a bug in the tools?

Our AD commented that it was difficult to distinguish the example spec text from the surrounding spec text in the text/plain rendering. These "scissor" marks were intended to serve that purpose; I suppose they're not as common as they used to be. My assumption is that the RFC Editor is going to propose a more suitable way to do this.

>    Perhaps reordering sections or adding a reference would help?

I think a reference.

>    Is a String the recommended approach?

I'm a little wary of giving a single recommendation here; it depends on the use case. It might be that it would be better to use two integers, for example, and add, multiply or otherwise combine them. Or it might make sense to implicitly multiple (e.g., *100) the value. Or it might make sense to yes, use a string -- or binary.

Cheers and thanks again,

--
Mark Nottingham   https://www.mnot.net/

---

From: David Schinazi <[email-masked]>
Date: Tue, 5 May 2020 12:42:09 -0700

On Mon, May 4, 2020 at 10:02 PM Mark Nottingham <[email-masked]> wrote:

> Hi David,
>
> Thanks for the comments. Responses below; I've committed in <
> https://github.com/httpwg/http-extensions/commit/001023>.
>

Thanks for making the changes! That commit looks good to me.

> Our AD commented that it was difficult to distinguish the example spec
> text from the surrounding spec text in the text/plain rendering. These
> "scissor" marks were intended to serve that purpose; I suppose they're not
> as common as they used to be. My assumption is that the RFC Editor is going
> to propose a more suitable way to do this.
>

Ah! Now I see it :) Happy to let the RFC editor decide what's best here.

> I'm a little wary of giving a single recommendation here; it depends on
> the use case. It might be that it would be better to use two integers, for
> example, and add, multiply or otherwise combine them. Or it might make
> sense to implicitly multiple (e.g., *100) the value. Or it might make sense
> to yes, use a string -- or binary.
>

Sounds good. I was mainly curious because I defined a sh-integer in one of
my drafts for a value that can in theory go up to 2^62-1, and I wonder if
it's worth the added complexity to support values between 10^15 and 2^62...
https://tools.ietf.org/html/draft-schinazi-masque-connect-udp-00#section-5
But we can figure that out in the context of that draft, no need to answer
that question in draft-ietf-httpbis-header-structure if there's no easy
solution that fits all.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 05 May 2020 20:29:13 +0000

--------

>it's worth the added complexity to support values between 10^15 and 2^62...

Let me chime in here, as the 10^15 thing is largely my "fault".

Without resorting to "there are N kinds of people" jokes, there are
essentially four classes of numbers:

A) Normal numbers.

B) Scaled numbers

C) Identifying numbers

D) Cryptographic numbers

The 10^15 has historically been more than fine for class A, people
generally hate when there are more than 10 digits in a number, this
we know this because AT&T did a LOT of research on this, back when
people did a lot more with numbers by hand than we do today.

In class B people deal with huge numbers by downscaling:  Millions,
Trillions, GigaBytes and PetaBytes.  Nobody really cares if the
stimulus was 1.000.000.000.000 or 1.000.000.000.010 dollars, so
sawing of the right hand side is a good way to make numbers manageable,
at the cost of suffixing multiplier: $125M

In class C we have numbers which are used to enumerate things,
customer numbers, passport numbers and so on.  By their nature these
numbers are not subject to arithmetic, but mainly because of the
punched cards and the numeric keypad, using digits for encoding
them is traditional.  I would recommend that these be encoded either
as byte sequences, or if they are important for manual debugging
as strings.

Class D is strictly speaking not only cryptographic numbers, but
again, these are not usually subject of arithmetic, but in difference
from class C they have a fundamental numeric nature, and there
may be some mathematical operators which apply to them, for instance
ordering.  For these, I would recommend using fixed size
byte sequences with a defined endianess.  But again:  If they are
important to human debugging, for instance being able to tell
which is larger/smaller, it may make more sense to put them
in a string with a suitable radix.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: David Schinazi <[email-masked]>
Date: Tue, 5 May 2020 13:45:40 -0700

Thanks for going into detail on this Poul-Henning!

In my use-case the numbers are identifiers with some arithmetic properties
(ordering, and whether they're even or odd) so I think they fit into the
class D
you described. I think a byte sequence with defined endianness and size
restriction should do the trick. That or just saying "if you reach 10^15
then
just restart your HTTP/3 connection"... I've filed an issue on my own draft
to keep
track of this <https://github.com/DavidSchinazi/masque-drafts/issues/26>.

Thanks again,
David

On Tue, May 5, 2020 at 1:29 PM Poul-Henning Kamp <[email-masked]> wrote:

> --------
> In message <CAPDSy+4y9ZZ-f=
> [email-masked]>, David Schinazi
> writes:
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 May 2020 10:14:31 +1000

> at the cost of suffixing multiplier: $125M

This makes me wonder whether we should add an example to stimulate readers' imagination in this direction; e.g.,

Example-ScaledInt: 4503;suffix=M

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 06 May 2020 07:00:33 +0000

--------
In message <[email-masked]>, Mark Nottingham writes:
>>=20
>> sawing of the right hand side is a good way to make numbers =
>manageable,
>This makes me wonder whether we should add an example to stimulate =
>readers' imagination in this direction; e.g.,
>
>Example-ScaledInt: 4503;suffix=3DM

Would that work without an explanation ?

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 7 May 2020 10:14:25 +1000

> On 6 May 2020, at 5:00 pm, Poul-Henning Kamp <[email-masked]> wrote:
> 

Perhaps in full context:

~~~
For example:

  Example-ScaledInt: 4503; suffix=M

Could be used to indicate a scaled value; in this case, 4,503,000,000, if the `M` suffix parameter is specified to denote multiplying the integer by 1,000,000.
~~~

Thoughts?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 07 May 2020 06:47:15 +0000

--------
In message <[email-masked]>, Mark Nottingham writes:

>Perhaps in full context:
>
>~~~
>For example:
>
>  Example-ScaledInt: 4503; suffix=3DM
>
>Could be used to indicate a scaled value; in this case, 4,503,000,000, =
>if the `M` suffix parameter is specified to denote multiplying the =
>integer by 1,000,000.
>~~~
>
>Thoughts?

Would people connect that to the 15 digit limitation ?

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 7 May 2020 09:28:20 +0200

> Would people connect that to the 15 digit limitation ?

I really don't see what we're trying to save above. I mean, it
requires more code to encode the numbers, more bytes on the wire
in every single case, and more code on the decoding side, plus
all the absurd or difficult error cases that have to be carefully
dealt with.

Sending "4503000000" is enough to always represent the same thing
and being trivial to check in length and to parse.

Amusingly the proposed representation with this "suffix=3DM" could
even possibly trigger some artefacts becoming "suffix=M" when
accidentely fed through a MIME-aware decoder seeing "=3D" and turning
it to "=", but that's just a side detail which still indicates that
making things difficult to decode can only result in more mistakes.

Just my two cents,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 10 May 2020 11:47:53 +1000

Perhaps not, but a larger int would do the trick.

That said, I'm not sure this is worth the late change.

Cheers,

> On 7 May 2020, at 4:47 pm, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

---

From: Ian Clelland <[email-masked]>
Date: Mon, 11 May 2020 10:00:23 -0400

On Thu, May 7, 2020 at 3:32 AM Willy Tarreau <[email-masked]> wrote:

> Sending "4503000000 <(450)%20300-0000>" is enough to always represent the
> same thing

I think that's exactly what happened here, in reverse -- mnot's original
suggestion was just a parameter "suffix=M", and in phk's reply, I see the
corrupted "suffix=3DM", so likely somebody's MUA got confused along the way.

I don't think that's an argument for abandoning "=" as the param/value
separator, though :)

Ian

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 18 May 2020 14:19:43 -0400

David, thanks for your review and thanks to everyone for the discussion. As I noted in my No Objection ballot, it seems like at a minimum the options available for integers larger than 10^15 should be noted somewhere so that readers are alert to it, even if no particular option is recommended.

Alissa

> On May 4, 2020, at 9:18 PM, David Schinazi via Datatracker <[email-masked]> wrote:
> 
> Reviewer: David Schinazi
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art