Original text:
9.3.2. The HEAD method is identical to GET except that the server MUST NOT <del> send payload data in the response (i.e., the response terminates at the end of the header section).  The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that header fields that describe message body encoding or transmission (e.g., </del>  <del> ) MAY be omitted. HEAD is used to obtain metadata about the </del>  <del> without transferring the representation data.  It is often used to test hypertext links for validity, accessibility, and recent modification. </del>  A payload within a HEAD request message has no defined semantics; sending payload data in a HEAD request might cause some existing

Reviewer comments:
Note that I also cleaned up the surrounding paragraph and removed parentheses from around the statement that the response always terminates after the header section.
currently links to "Message Payload", but that is not that helpful in order to find out what fields actually are "payload header fields".
Note. We currently say: "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 6.4) MAY be omitted." URL would change this to: "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that header fields that describe message body encoding or transmission (e.g., Transfer-Encoding) MAY be omitted." (me confused by that)
I should probably just list them all. Content-Length and Transfer-Encoding are the obvious ones, but I would have to go through the spec to be sure there are not more. The reason for this is that servers do not generate the body on HEAD responses, so the fields that are defined while buffering the first 8K of body (when they can still be sent as headers) are not sent on HEAD responses. Maybe we should just say that.

Revised text:
9.3.2. The HEAD method is identical to GET except that the server MUST NOT  <ins> send payload data in the response and the response always terminates at the end of the header section.  HEAD is used to obtain metadata about the without transferring its representation data, often for the sake of testing hypertext links or finding recent modifications. The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request method had been GET. However, a server MAY omit header fields for which a value is determined only while generating the payload data.  For example, some servers buffer a dynamic response to GET until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to GET might contain </ins>  <ins> and </ins>  <ins> fields, for example, that are not generated within a HEAD response. These minor inconsistencies are considered preferable to generating and discarding the payload data for a HEAD request, since HEAD is usually requested for the sake of efficiency. </ins> A payload within a HEAD request message has no defined semantics; sending payload data in a HEAD request might cause some existing