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: It's also weird to only require roundtripping for floats that can be represented in binary64. The simplest might solution here might be to just accept that floats are lossy. If an implementer needs precision, use a string. This trade-off seems to work well enough for JSON parsers.
The spec already restricts floats to those which can theoretically be round-tripped into a binary64 and back; this is just about ensuring that that actually happens, if a binary64 is used as the backing store (which is natural for at least C++ and JS implementations)
nearest-or-even SGTM. Stripping trailing zeros as well as leading ones in the integer component sounds good as well. I'll do a PR...
PTAL at the commit. I've added a test for this ("tricky precision float") -- NAME are you using the tests?
/me reads above - yes you are, sorry for the noise.
I do not think we should make stripping trailing zeros decimal digits a strict requirement, the number of decimals presented can be out-of-band metadata about the actual precision involved. For instace a timeinterval serialized as 3.0 vs 3.000 vs. 3.000000 might be used to communicate the precision of the measurements as tenths of seconds / milliseconds / microseconds respectively. But we should probably recommend stripping trailing zero decimal digits for bandwidth reasons, if there is no communicative reason to retain them.
If someone wants to use the precision of measurement that way, it'd need to be available in all implementations to be interoperable -- i.e., we'd have to require implementations to preserve that precision. I'm pretty dubious on that being possible and correctly implemented across the board. E.g., requiring every implementation to parse "0.42000" and make the trailing zeros correctly available.
If we're going to round, we probably need to do it before serializing the integer part, since the rounded fractional part may round up to 1.0, as well.
For floats, I think there are two things that we want from this spec (and please let me know if that's not right): Any string which parses as an float can have that float's value stored in a binary64, and serializing that value should reproduce the original string.