Re: Genart last call review of draft-ietf-httpbis-header-structure-18

[Ian Clelland <[e-mail]>]

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

> On Thu, May 07, 2020 at 06:47:15AM +0000, Poul-Henning Kamp wrote:
> > --------
> > In message <[e-mail]>, 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 ?
>
> 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 <(450)%20300-0000>" 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.
>

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