Code change:
The <del> status code indicates that none of the ranges in the request's header field (field.range) overlap the current extent of the or that the set of ranges requested has been rejected due to invalid ranges or an excessive request of small or overlapping ranges. </del> <ins> status code indicates that the set of ranges in the request's </ins> <del> For byte ranges, failing to overlap the current extent means that the </del> <ins> header field (field.range) has been rejected either because none of the requested ranges are satisfiable or because the client has requested an excessive number of small or overlapping ranges (a potential denial of service attack). </ins> <del> of all of the </del> <ins> Each range unit defines what is required for its own range sets to be satisfiable.  For example, byte.ranges defines what makes a bytes range set satisfiable. </ins> <del> values were greater than or equal to the current length of the selected representation.  When this status code is generated in response to a byte-range request, the sender SHOULD generate a </del> <ins> When this status code is generated in response to a byte-range request, the sender SHOULD generate a </ins> header field specifying the current length of the selected representation (field.content-range).

Related discussion:
text: In 416 status code section, remove duplicate definition of what makes a range satisfiable and refer instead to each range unit's definition. In sections on bytes ranges and Range, clarify that a selected representation of zero length can only be satisfiable as a suffix range and that a server can still ignore Range for that case.
Regarding byte ranges, an empty (zero-length) representation is unsatisfiable according to section 2.1, but not unsatisfiable according to section 4.4 if the first-byte-pos is zero. I would like to see an update to the RFC which explicitly resolve this self-contradiction in whatever way seems appropriate. The following is one suggestion, but there may be others: I would like to suggest explicitly specifying that an empty 200 response should be returned in this case. It is the simplest solution to the current self-contradiction in the RFC, since it is a valid response anyway (if the server chooses to ignore the Range header), clients already handle it properly, it provides all necessary information about the representation to the client, and stating it explicitly can prevent subtle edge-case pitfalls in both the RFC and its implementations (as opposed to more intricate solutions). Perhaps the following can be added at the end of section 3.1: "If all of the preconditions are true and the target representation length is zero, the server SHOULD send a 200 (OK) response." (someone in the discussion preferred this to be a MUST, but the SHOULD might be more in line with the previous sections and backward-compatibility if some implementations resolved this in some other way.) I raised this in the mailing list a while back, and it got some discussion and support but did not get officially resolved. More recently I reported it as errata but it was rejected as not being an erratum and redirected here (I apologize - didn't realize issues moved to github, and still not sure what the distinction is :-) ), so here it is, raised again. All suggestions and feedback are welcome.
So how do we get this fixed? There was a discussion about it in the IETF mailing list, in which others confirmed the issue. I opened an errata, but it was closed saying it's not an errata. I was pointed here to open the issue, but got no response in 9 months so far. What can I do to get a response or to help move this forward?