On Thu, May 7, 2020 at 3:32 AM Willy Tarreau <w@xxxxxx> wrote:
On Thu, May 07, 2020 at 06:47:15AM +0000, Poul-Henning Kamp wrote:
> --------
> In message <977F061C-A4BB-413B-B26C-51C7A694FA74@xxxxxxxx>, 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" 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
