Code change:
4.1.5. <del> Given a float as input_float, return an ASCII string suitable for use in a HTTP header value. </del> <ins> Given a decimal_number as input_decimal, return an ASCII string suitable for use in a HTTP header value. </ins> Let output be an empty string. <del> If input_float is less than (but not equal to) 0, append "-" to </del> <ins> If input_decimal is less than (but not equal to) 0, append "-" to </ins> output. <del> Append input_float's integer component represented in base 10 </del> <ins> Append input_decimal's integer component represented in base 10 </ins> (using only decimal digits) to output; if it is zero, append "0". <del> Let integer_digits be the number of characters appended in the previous step. If integer_digits is greater than 14, fail serialisation. Let digits_avail be 15 minus integer_digits. Let fractional_digits_avail be the minimum of digits_avail and 6. </del> <ins> If the number of characters appended in the previous step is greater than 12, fail serialisation. </ins> Append "." to output. <del> If input_float's fractional component is 0, append "0" to output. </del> <ins> If input_decimal's fractional component is zero, append "0" to output. </ins> <del> Else if input_float's fractional component has fractional_digits_avail or less digits, append input_float's fractional component represented in base 10 to output. </del> <ins> Else if input_decimal's fractional component has up to three digits, append them represented in base 10 (using only decimal digits) to output. </ins> <del> Else append fractional_digits_avail digits of input_float's fractional component represented in base 10 to output, rounding to the nearest value, or to the even value if it is equidistant. </del> <ins> Otherwise, append the first three digits of input_decimal's fractional component (represented in base 10, using only decimal digits) to output, rounding the final digit to the nearest value, or to the even value if it is equidistant. </ins> Return output.

Related discussion:
text: (modulo some number of 0's at either end) Any real value (regardless of storage implementation) in the range -(1e14-0.05) to (1e14-0.05), exclusive, should serialize to its closest valid sh-float representation. (rounding ties towards an even least-significant-digit) Is that reasonable?
Discussed in Singapore: will discuss on list, but sense in the room is to have a fixed point. Hum in the room prefers fixed point. (Need to still determine number of decimals; q-value uses 3).
Specifically pinging NAME NAME NAME for thoughts re: moving float to fixed-point (straw-man: three digits). This seemed to have strong support in the room, but wanted to make sure you're comfortable with it.
Would fixed point be materially different that what is currently specced? Currently, the spec implies a fixed-point with 6 digits of precision, and a maximum of 15 total digits, which (not at all coincidentally) is the same range that is guaranteed to round trip through an IEEE-754 binary64 representation, which is useful for actual implementations. Edit: I see the three-digit difference now; would the integer portion be restricted to 12 digits in that case?
Yes.
I don't have a strong opinion on switching to 12+3 fixed; I think it would cover all of the use cases that I can currently imagine (and I'm trying hard to discount any sunk costs from implementing the previous draft :stuckouttongue:) If implementation complexity (or perceived complexity) factors in to the decision at all, Chrome's current sh-float serializer, which passes the public test suite, is
If people think it's useful to have a fixed-point number, and can settle on the optimal number of digits for most of their use-cases, then
The (only!) two "real" reason we have float/decimal in the first place is values and subsecond resolution time-{intervals,stamps}, and the one "unreal" reason is that JSON offered that. I think has three decimals, either by norm or convention. Time-intervals such as "process-time for this request" are often sub-millisecond, and that has by and large been the argument for "at least six decimals".