Original text:
proactive negotiation to indicate what parts of the request information were used in the selection algorithm. <del> The request header fields below can be sent by a user agent to engage in </del>  <del> of the response content, as defined in proactive.negotiation.  The preferences sent in these fields apply to any content in the response, including representations of the target resource, representations of error or processing status, and potentially even the miscellaneous text strings that might appear within the protocol. </del>  <del> 12.1.1. </del>  <del> 12.1.1.1. </del>  <del> For each of these header fields, a request that does not contain the field implies that the user agent has no preference on that axis of negotiation.  If the header field is present in a request and none of the available representations for the response can be considered acceptable according to it, the origin server can either honor the header field by sending a </del>  response or disregard the header field by treating the response as if it is not subject to content negotiation for that request header field.  This does not imply, however, that the client will be able to use the representation. <del> 12.1.1.2. </del>  The content negotiation fields defined by this specification use a common parameter, named "q" (case-insensitive), to assign a relative

Reviewer comments:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Revised text:
proactive negotiation to indicate what parts of the request information were used in the selection algorithm.  <ins> The request header fields </ins>  <ins> , , , and are defined below for a user agent to engage in of the response content.  The preferences sent in these fields apply to any content in the response, including representations of the target resource, representations of error or processing status, and potentially even the miscellaneous text strings that might appear within the protocol. 12.2. With (a.k.a., ), selection of the best response representation (regardless of the status code) is performed by the user agent after receiving an initial response from the origin server that contains a list of resources for alternative representations. If the user agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to obtain a different form of representation for that response. Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated (possibly hypertext) menu. Note that the above refers to representations of the response, in general, not representations of the resource.  The alternative representations are only considered representations of the target resource if the response in which those alternatives are provided has the semantics of being a representation of the target resource (e.g., a response to a GET request) or has the semantics of providing links to alternative representations for the target resource (e.g., a response to a GET request). A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive negotiation by the user agent is preferred.  For example, the alternatives listed in responses with the </ins>  <ins> and status codes include information about the available representations so that the user or user agent can react by making a selection. Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally when public caches are used to distribute server load and reduce network usage. Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation.  Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being developed as an extension. </ins>  <ins> 12.3. When content negotiation preferences are sent in a server's response, the listed preferences are called because they intend to influence selection of an appropriate payload for subsequent requests to that resource.  For example, the (field.accept) and (field.accept-encoding) header fields can be sent in a response to indicate preferred media types and content codings for subsequent requests to that resource. Similarly, RFC5789 defines the "Accept-Patch" response header field which allows discovery of which content types are accepted in PATCH requests. </ins>  <ins> 12.4. 12.4.1. For each of the content negotiation fields, a request that does not contain the field implies that the sender has no preference on that axis of negotiation. If a content negotiation header field is present in a request and none of the available representations for the response can be considered acceptable according to it, the origin server can either honor the header field by sending a </ins> response or disregard the header field by treating the response as if it is not subject to content negotiation for that request header field.  This does not imply, however, that the client will be able to use the representation.  <ins> 12.4.2. </ins> The content negotiation fields defined by this specification use a common parameter, named "q" (case-insensitive), to assign a relative