On Thu, May 7, 2020 at 3:32 AM Willy Tarreau <w@1wt.eu> wrote: > On Thu, May 07, 2020 at 06:47:15AM +0000, Poul-Henning Kamp wrote: > > -------- > > In message <977F061C-A4BB-413B-B26C-51C7A694FA74@mnot.net>, 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
Received on Monday, 11 May 2020 14:00:51 UTC