Original text:
server support. The request MUST use the "DELETE" method.  The request MUST NOT <del> include the "Upload-Offset" header or the "Upload-Complete" header. The server MUST reject the request with the "Upload-Offset" header or the "Upload-Complete" header by sending a "400 (Bad Request)" response. </del>  If the server successfully deactivates the upload resource, it MUST <del> send back a "204 (No Content)" response. </del>  The server MAY terminate any in-flight requests to the upload resource before sending the response by abruptly terminating their HTTP connection(s) or stream(s). If the server does not consider the upload resource to be active, it <del> MUST respond with "404 (Not Found)" status code. </del>  <del> If the server does not support cancellation, it MUST respond with </del>  "405 (Method Not Allowed)" status code. 8. 8.1. <del> The "Upload-Offset" request and response header field is an Item Structured Header indicating the resumption offset of corresponding upload, counted in bytes.  Its value MUST be an integer.  Its ABNF is </del>  8.2. <del> The "Upload-Complete" request and response header field is an Item Structured Header indicating whether the corresponding upload is considered complete.  Its value MUST be a boolean.  Its ABNF is </del>  The "Upload-Complete" header field MUST only by used if support by the resource is known to the client (feature-detection). 9. <del> The "301 (Moved Permanently)" status code and the "302 (Found)" status code MUST NOT be used in offset retrieval (offset-retrieving) and upload cancellation (upload-cancellation) responses.  For other responses, the upload resource MAY send a "308 (Permanent Redirect)" response which clients SHOULD use for subsequent requests to it.  If client receives a "307 (Temporary Redirect)" response to an offset retrieval (offset-retrieving) request, it MAY apply the redirection directly in an immediate subsequent upload append (upload-appending). </del>  10.

Reviewer comments:
See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.

Revised text:
server support. The request MUST use the "DELETE" method.  The request MUST NOT  <ins> include an "Upload-Offset" or "Upload-Complete" header field.  The server MUST reject the request with a "Upload-Offset" or "Upload- Complete" header field with a "400 (Bad Request)" status code. </ins> If the server successfully deactivates the upload resource, it MUST  <ins> respond with a "204 (No Content)" status code. </ins> The server MAY terminate any in-flight requests to the upload resource before sending the response by abruptly terminating their HTTP connection(s) or stream(s). If the server does not consider the upload resource to be active, it  <ins> MUST respond with a "404 (Not Found)" status code. </ins>  <ins> If the server does not support cancellation, it MUST respond with a </ins> "405 (Method Not Allowed)" status code. 8. 8.1.  <ins> The "Upload-Offset" request and response header field indicates the resumption offset of corresponding upload, counted in bytes.  The "Upload-Offset" field value is an Integer. </ins> 8.2.  <ins> The "Upload-Complete" request and response header field indicates whether the corresponding upload is considered complete.  The "Upload-Complete" field value is a Boolean. </ins> The "Upload-Complete" header field MUST only by used if support by the resource is known to the client (feature-detection). 9.  <ins> The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT be used in offset retrieval (offset-retrieving) and upload cancellation (upload-cancellation) responses.  For other responses, the upload resource MAY return a "308 (Permanent Redirect)" status code and clients SHOULD use new permanent URI for subsequent requests.  If the client receives a "307 (Temporary Redirect)" response to an offset retrieval (offset-retrieving) request, it MAY apply the redirection directly in an immediate subsequent upload append (upload-appending). </ins> 10.